セットアップについて少し。

様々な会社様からのデータを受け取って仕事をしていると、気になることが出てきます。
その一つが、キャラクターの仕様の違い。
リグしかり、命名規則しかり、階層構造しかり…
いろいろ見ていると似ている箇所もあるのでスタンダード「的な」ものも見えてきますが、
それでもなにか標準が厳然と君臨しているわけではなく、
スタンダード…っぽいけど違うかったり、こっちはあのタイプ・そっちはこのタイプね…という感じだったり。
けだし奥が深すぎます。

そんな広くて深いセットアップについて、こういうのもあるという例や自分のおすすめなど交えながら書いてみたいと思います。


まずは階層構造から。

モデルをリファレンスしてアニメーション作業などをすることを考えると、
モデルのすべての要素は最終的にはひとつのノード以下にまとめておくべきだと言えます。
そしてジオメトリ、ジョイント、コントローラなど種類・役割の違うオブジェクトは、それぞれにグループを作って整理しておくというのもスタンダードだと言えるでしょう。
こうしておくことで、リギング作業を整理した状態で進めることができ、うっかりダブルトランスレートしちゃったりを避ける事にもつながりますし、一旦リグを組んだあとの仕様変更とかにも比較的対応しやすくなります。

たとえばこういう感じ…

階層構造といえば、キャラクターではなくシーンを作るときも大事になると思います。
だいたいは、「キャラクター（＋演技に絡む道具）」「背景」「それ以外（カメラなど）」を分けるグループを用意して、それを仕切り代わりにするというものです。
こういう感じ↓

これを、アニメーションを付けるシーンでは徹底すると、いろいろすっきりします。
構造が明解になると作業もしやすく、人に渡してもわかりやすいなどメリットがあります。
ただ、第一階層から動かせない（グループ化不可な）オブジェクトがあると、統一感が崩れてしまうという気分上の脆さもありますが(^^;
また、このようなたかだか3つ程度の分け方でも、どういったものがどこに入れられるのかという仕分けルールをちゃんとしておかないと、グレイな物体は作業者によって居場所がまちまちになる可能性があります。
たとえば、
ライトは背景なのか、その他なのか…キャラに絡む家具は…など。


それからシーンの運用に際しての取り決め的な部分として
ディスプレイレイヤーを使うのか、使わないのか、という問題もあります。
問題というかどうかは度合いによりますが(^^;

シーン構造が整理されていれば、Outlinerだけの管理で事足りてしまうことも多く、
むしろ表示非表示の管理がディスプレイレイヤーとの二系統になってしまうため人によっては馴染まない（もっというと混乱する）ことがあります。
他方、ディスプレイレイヤーの表示非表示と違って、visibilityというアトリビュートを変更して切り替えることになるためなにか気持ちが悪い。だからディスプレイレイヤーを使うのがいい、という向きもあるようです。階層内の深いところを非表示にしたりすると、一元的に管理できないので表示非表示ミスに繋がる、という懸念もあるようですね。

もし、ちょっと込み入ったシーンなりキャラクタなりで見た目の整理にディスプレイレイヤーを用いている場合、ひととやり取りするときは、ディスプレイレイヤーからはどういう整理をしています、くらいは仕様などでお知らせしたらよいと思います。


つぎは命名です。
階層構造の整理は作業上の利点があるのですが、命名に関しては、実際のトコロどうなっていてもほぼ明確な実害として現れないこともあり、かなりいろいろなタイプを見かけます。
命名による実害は無いといっても、大手制作会社でセットアップシステムが敷設されている場合は厳密に決まっているでしょうし、命名がわからなすぎていっぱい確認しないといけないとかになると、実作業に支障が出ちゃいますからそれは実害というほかないでしょう。
とはいえ、「システムの一部としての命名」はそのシステム（と、それを作る人）次第ですし、そうでなければ「分かる命名」であれば大丈夫といえば大丈夫なことに変わりありません。

つまり命名は、命名する人の流派次第。
…かくて、いろいろなスタイルでの命名が行われます。

まず先程も上げた例ですが

二度目の登場の図

ルート以下に、種類そのままの名前のついたグループがぶらさがっています。
geometryやjointは英単語そのままで、cntはコントローラですね。
ルートノードがrootとなっていてキャラ名などでないのは、リファレンスしたときにネームスペースとしてファイル名(≒キャラ名)が入るのを前提としているからです。ここをキャラ名にしていると、実際運用時には「キャラ名：キャラ名」みたいになっちゃいますので、問題は無いとはいえなんか変な感じになります。
あとそういえば、コントローラって「cnt」だったり「ctl」だったり「ctrl」だったりいろいろな略され方をします。
（なぜ略すか邪推すると…コントローラというスペリングが日本人の苦手要素を含んでいるからじゃないかと思います(笑)　何も考えずにタイプすると controlerだかcontlorerだか混乱する気がしないでもありません。geometryやjointと比べると、自信を持って打てない度は高いでしょう…！　正しくは「controller」。Lが重なってるのも日本人英語的には苦手度に拍車をかけてる要素かと(笑)）
ちなみにctrlという略はおそらくwindowsのキーボード上の表記からだと思いますが、略して四文字というのはほかと揃えづらいのでどうなのかな……？とか…。

↑こちらはなにか名前のあとに「_geo」のように種類を示す文字列をつけるタイプ。拡張子みたいなイメージですね。
ちなみに本気で拡張子のように「.geo」と打つと、ドットは勝手に「_」に変換されます。これは、エクスプレッションなどでドットが重要な意味を持っており(←ドットシンタックス)、オブジェクト固有の名前にドットを含むと困ったことになるためです。

その変形版↓

プログラミング界隈で見かける「小文字で始めてあとは大文字」な規則を、上記の拡張子風な部分にも徹底したパターンです。
ある意味徹底しているところに美学を感じますが、プログラムする側からは人気がなさそうな気がします。ﾋｬﾊｰ
また隙間があまりないので、__で区切った時と違い数字をとっさに読みづらいというのはありますね(^^;


こうした命名規則を意識するともうひとつ利点があって、
名前を気にするようになるということです。
これは人に渡すデータ＝人に見せられるデータを作る際には「マナー」のような感じで大事なことですし、mayaは同じ名前のオブジェクトが2つ以上あると自動的に末尾に数字を付けますので、それをチェックし除去することにもつながります。
命名規則が守られている状態に慣れてくると、末尾に数字がついているだけで手抜きの匂いを嗅ぎ取れる嗅覚を養えます(?)


ちょっと思ったより長くなってしまったので、
残りはできるだけコンパクトにまとめたいと思います。

モデルを完成させたら、セットアップ前にいろいろしないといけませんね。
フリーズかけたり軸を揃えたりヒストリー消したり。これらを怠るとあとでトラブルのもとになります。
そんなわけでセットアップ中は試行錯誤も含めて手数も多く、なんとか楽をしたいものです。


例えばフリーズをかけてpivotを原点にもっていくスクリプト↓

string $objs[]=`ls -sl`;
for ($obj in $objs){
    move 0 0 0 ($obj+".scalePivot") ($obj+".rotatePivot") ;
    FreezeTransformations;
    }

グループ化するときグループ名を「選択しているオブジェクト＋_grp」にするスクリプト↓

$target=`ls -sl`;
$grpName =($target[0] + "_grp");
group -n $grpName; xform -os -piv 0 0 0;

選択したものの位置と回転を別のものに揃えるスクリプト↓

if (size(`ls -sl`) == 2){
    doCreateParentConstraintArgList 1 { "0","0","0","0","0","0","0","1","","0" };
    $pConsts = `parentConstraint -weight 1`;
    delete $pConsts[0];
    }

※ペアレントコンストレインで位置と回転をあわせたあと、ペアレントコンストレインノードを削除、というお手軽な手法です。対象が2つじゃないとあまり意味が無いので冒頭で分岐をかけてます。


…のような、小粒なのがあると何かと便利です。
手数の多さに不満を感じる箇所があったら、できるだけ早い段階でスクリプトづくりの時間を取ってみましょう。早ければ早いほど効果的だと思います。
やり直しも気楽になるので、余裕を持った試行錯誤につながります。

最後に、
セットアップの、コントローラに関わる階層構造でよく見かける仕組み。

単純に考えると、リグをつけるとき、必要なトコロまで（例えば操りたいジョイント）コントローラを移動し、必要ならフリーズをかけて、コントローラからジョイントへコンストレインなどかけるところです。

一方、図の構造はどうなっているかというと、
コントローラの上位にグループノードを置き、そいつで必要な位置まで移動。
それから、コントローラがジョイントを制御するようにしています。グループノードでコントローラをくるんでいるのがミソで、コントローラはその上のグループノードのローカル空間にいますから、位置などのチャンネルは値的にはゼロのまま。
これによって、なにか操作を加えたあとでもチャンネルの値をゼロにすることで初期ポーズに気軽に戻れます。まぁこれだけならフリーズをかければいいのですが、もう一点。
グループ側で、どこかからの操作をコンストレインなどで受け取る事で、なにかの動作の影響を受けたまま自分で操作できるコントローラを作りやすくなります。
たとえば建物間を飛び移る時などに力を発揮しますが、そういったシチュエーションにかかわらず、すべてのコントローラはこの基本構造を持っているべきではないかと個人的には思います（思いますし、またよく見かけるので、定番の構造なのだと思います。)

コンストレインをコントローラにかけても同様の結果を求めることはできますが、やれコンスレイン間のウェイトだ、ブレンドだ、となにげに煩雑になってしまいがちです。
グループ側でコンストレインを受けて、コントローラはオフセット的に動かせる方が、アニメーション作業はスマートにすすめられると思います。
もちろんモデルとジョイントとコントローラはジャンルごとにグループに分け、それぞれは必要に応じてコンストレインやコネクトで結ぶ、といった形になると思います。
この図でも、選択されている hogehoge_ctl_grp 以下以外に other_ctl_grp も同様の構造にしています。見えないですが(笑



後半やや駆け足でしたが、ひとまずセットアップについて書いてみました。
このあたりについては様々な思惑が飛び交っているところかと思いますので、
また話題が溜まったら書いてみたいと思います。
前回はそういえばコードを書きたいとか言ってたんですが実際コードを書いてるんですが流れ的にそういうことじゃねぇっていうのはご容赦ください (ノ∀｀;)　思わずmelになっちゃいました
 

■関連リンク

キャラクタセットアップ　＠Maya2012オンラインヘルプ
http://download.autodesk.com/global/docs/maya2012/ja_jp/files/GUID-072516A2-5D56-4D12-AE95-8C82288FC77-1985.htm