この記事はMaya Advent Calendar 2023の21日目の記事です
お疲れ様です。COYOTE TAチームのMです。
はい！リファレンス記事なんやかんや2年続き執筆止まってしまって申し訳ございませんでした！！！！（色々ね、色々あったの。
前回（https://3d.crdg.jp/tech/archives/1846）はリファレンス機能がどう便利なのか？何故大規模開発で使われるのか※の話をしました。
（※すべての案件で必ずしも使われている！というわけではないですが、基本的にバージョン管理ツール＋全作業者が同期された同一リポジトリで構成された階層構造＋多人数開発＋Mayaのリファレンス機能のシナジーは非常に強力なんです！！！）
中編の今回はリファレンス機能の根幹となっている部分について解説します。ここを理解できて、maデータ内を読めるようになると非常にトラブル対応に強くなれます。
筆者は弊社TAチームの中で一番データ解析に特化しているのでここらが出来る人がもっと増えてほしいなぁという目論見もあってこの記事を書いてるので、この記事をとっかかりにみんな是非強くなってください！そうすればデータトラブル時の僕への問い合わせも減るんで！！！！！
前編ではリファレンス機能は仮想インポート機能という説明をしました。
簡単に例を見てみましょう。
まずSphereを呼び出してテキトーに分割数を増やしてシーンを保存します。とりあえずMOD_ball.maとでもしておきますか。
次に新規シーンを開きファイル＞リファレンスエディタ（リファレンスの作成でもいいですがこのあとの様々な解説のためにウィンドウをここで呼び出します。）
リファレンスエディタの左上にあるエヴァのラミエルにプラスマークのついたようなアイコンを押下し、MOD_ball.maを読み込みます。
（このラミエルみたいなアイコンはMayaのリファレンス機能でやたらでてきます。筆者の脳内ではヤシマ作戦のBGMが流れ始めました。新劇場版の方の。）
読み込んだらリファレンスウィンドウはこの様になっていると思います。
ネームスペースは既定値では何も設定されていませんが、長くても3文字程度※の識別子を入れておきます。
ネームスペースは自動的な処理を作る際に非常に重要な要素なため識別子をつけるクセは普段からつけておいたほうが良いです。（通常案件ではモデルのシーンはXX、スキニングシーンはYYのようにルールが敷かれているのでそれに従ってください。）
今回の例は多重ではないですが多重リファレンス構造になってくるとネームスペースも入れ子構造になっていくので短い識別子を強く推奨します。っていうかマジで長いネームスペースやめてください。（幸い長いネームスペースになってる案件にぶち当たったことは筆者は無いですが・・・）
（※長いネームスペースを入れるとノード名のフルパスを取ったときに非常に視認性が悪くなるんです。視認性の低下はミスの増加に直結します。どんなに自動化スクリプトを書いてもイレギュラー対応は人力です。）
リファレンスウィンドウは一旦閉じ、リファレンスで読み込んだSphereにテキトーにアニメーションキーを打って、何かアトリビュートの値もついでに変更してシーンを保存してください。(とりあえずシーン名をANM_ball_m01.maとでもしておきましょうか
では今作った２つのファイルを詳しく見ていきましょう。
まずMOD_ball.maに入っているのはSphereのメッシュファイルが入っています。
ANM_ball_m01.maにはアニメーションキーの情報とリファレンス情報が入っています。
ここでファイル容量に注目すると、前編でもすこし触れましたがあくまで仮想的なインポートをしてその参照とリファレンスに元に含まれるノードに対しての編集情報と自身のシーン内の情報を持っているだけなので、メッシュの実態はリファレンスとして読み込んでいるANM_ball_m01.maには存在しないため※下流ファイルであるANM_ball_m01.maはとてもファイルサイズが軽いです。
（※正確にはJointによるスキニング含め、デフォーマー系を組み込んだ場合等の状況下ではモデルの実態が全くないという状態ではなくなるためすべての状況において実態が存在しないというわけではありません。ただし例えばモデル＞スキニング＞リギング＞アニメーションという入れ子構造の場合リギングとアニメーションシーンでは基本的にメッシュの実態はそれぞれのシーンには存在せずモデルシーンとスキニングシーン以外のシーンが相対的にシーンデータが軽めになります。）
ANM_ball_m01.maシーン自体をテキストエディタで開いてみましょう。VSCodeがオススメです。
中身を見てみるとざっくりと
createNodeでanimCurve系ノードが作られ
connectAttrでSphereと接続がされております。（正確にはプレースホルダーに接続されます。プレースホルダーに関しては一旦 リファレンスとの橋渡ししている仮想のジャンクションという理解でOKです。）
次にANM_ball_m01.maシーンを開き直し、リファレンスエディタを開いてください。
読み込まれているMOD_ball.maシーンを右クリックし、ファイル＞リファレンスの編集のリストを開くと
このようになにやら文字が列挙されています。
細かく見ていきましょう。
まず
——– setAttr ——–
と装飾された欄を見ると、MELのsetAttrコマンドでアトリビュートのセットが行われています。
——– connectAttr ——–
の欄ではconnectAttrコマンドでanimCurveノードからsphereオブジェクトのキーを打ったアトリビュートにそれぞれ接続がされています。
setAttrやconnectAttr以外にもまだいくつかこのウィンドウに列挙される要素はありますが、今回はわかりやすく値をセットするsetAttr、ノード同士をつなげるconnectAttrに絞ります。
さて、これではシーンデータ内を直接開いて見てるのと大して変わらないのでリファレンスエディタを少し使ってみましょう。
connectAttrから、何かしら選択し、右下の選択した編集済みの除去 を押下してください。
そうするとコネクションが外され、該当の操作が無かったことになります。（正確にはコネクションを外しているだけなのでanimCurveノードの生成とsetKeyframeはシーン内に存在しているが・・・）
一見 なーんだアニメーションキーを外してるだけじゃん。と思われるかもしれませんが、そうですこの操作に関してはbreakConnectionしてるのと大差ありません。
もちろんそんなリファレンスじゃなくても出来ることをするためだけに使うものではありません。
重要なのが、リファレンスとして読み込んでいるファイル内のオブジェクト等への”操作内容だけが”参照している側のシーンに保存されるという点です。
Undo履歴とは全く別の部分でその履歴を１操作（オペレーション的操作ではなく、setAttrやConnectAttr単位）単位で無かったことに出来るという部分にリファレンス機能を使う大きなメリットがあります。Undo履歴と違い順番に遡って戻る必要も無く、シーンに保存されているため、Mayaを再起動して読み込み直してもリファレンスの編集情報を参照することができます。
アスキーデータとしてmaデータを解析できることと、リファレンス機能が優秀なため、データのトラブル解析と解決に非常に優れている点がMayaをパイプラインとして
使う最大のメリット※だと筆者は考えます。というかここを生かさないのはMaya使いとしてもったいない。非常にもったいない！
（※筆者が知る限りシーンデータをアスキー保存できて、Mayaと同等かそれ以上のリファレンス機能を持つDCCツールは有りません。）
さて、中編ではリファレンス機能の中身自体を解説しましたが、最後（となる予定の）後編では、今回出てきたリファレンス編集のテクニックと
前編でお話したこの記事を書こうと思った根本的な理由である「リファレンス機能ってファイルが壊れやすい」という大いなる誤解について
実際にファイルを壊して（正確には適切に運用できてない事によって壊れたように見えてるだけ）その理由や直し方について解説します。
おそらく夏くらいまでには投稿する予定です！気長に待っててください！（流石に２４年中には出します。
明日は kuboさんの「接地を取りたい」です
