＜リグシステムの方針＞

• 衣装や装備などの着せ替えが多い案件では、全てのバリエーションに修正や要望を適用するのがとても面倒なので、派生モデルに対するリグの管理のしやすさを重視してツールを開発している。
• 既定の作業については可能な限り自動化し、極力、手動での調整を組み込まない設計にしている。
• セットアップデータの再構築（ビルド）においても、手動での調整をせず、全て自動で再現できる設計にしている。
• 担当者変更の際の引継ぎの手間軽減やボタンの押し間違えなどのヒューマンエラーを防ぎたいので、ボタンも出来るだけ減らしてシンプルな仕組みを考えた。
• ビルドは1ボタンで行う。
  
  

＜概要＞

• ヒューマンエラーが起きないような構造にしている。
• 「モデルデータ」、「ジョイントデータ」、「手動で調節したデータ」を用意してシステムに流す。
  
  

＜ビルド実演＞

今回は、「人型のキャラクターモデルにリグを設定する」といった例で実演する。
※予め用意された骨、ウェイト、ケージなどの各種データを使用して実演。

1. ツールを使用し、テンプレートとして用意しているジョイントデータを読み込む。

• ツイスト骨も含め、バインドに必要なジョイントを全て用意する。
  
• ジョイントは、最終的なデフォルトのポーズで用意している。
  
• ジョイントの自動作成は対応していないので、必要に応じでジョイントを作成する。
• 過去案件で作成したデータの流用や、ベースとして作成したテンプレートのジョイントデータを使用することが多い。
• IKを入れることを想定して、腕や足には少し角度を付けている。
• ジョイントの階層の他に別の階層があり、メタ情報を登録している。例えば腕の場合、IKのStartJointとEndJointの名前や作成されるコントローラについての情報、右側にも同様の設定を適用するかどうかといった情報を記載している。
  
• 左側作成後は、ネーミングとトリガーにして右側を自動で作成することが可能。
  

2. モジュールを追加する。

• 部位ごとに用意されているモジュールがある。
• 各モジュールは、部位ごとにグループ化している。
• moduleTypeには、カテゴリとして、ctrl、deformer、layer、setup、switchなどがある。
• ctrlには、コントローラに関するモジュールを用意している。
• deformerには、デフォームに関するモジュールを用意している。
• layerには、ローカルセットアップに関するモジュールを用意している。
• setupには、補助骨やドリブンキーなどの内部的なギミックに関するモジュールを用意している。
• switchには、visibilityなどのアトリビュートに関するモジュールを用意している。
• モジュールに必要な機能を選択してメタデータに格納する。
  
• メタノードの情報をノードエディタで接続する。
  
  

3. GUI上にモデルデータ、ケージデータ（必要であれば）、ジョイントデータを読み込みビルドを行う。

• GUIで各種読み込みの設定を行う。
  
• ペアレントの変更やコンストレインの追加は、GUIのsetupFilesの項目から各pythonを開き編集を行う。
  
  
• 元々書き出していたスキンウェイトの情報もビルド時に読み込んでバインドされる。
• ビルド用のボタンは2種類用意している。
  フラスコアイコンのボタン：テスト用のボタンでエラーを無視し最後まで実行を行う。エラーはスクリプトエディタで確認可能。
  カートアイコンのボタン：最終的な出荷用としてビルドを行う。アニメーション時に使用してほしくないアトリビュートはロックされる。また、データが自動的に保存される。エラーがあれば途中で処理が止まる。
  

4. データに問題が無ければ、FileBrowser assetというツールで出荷する。

• ビルドが通ったものしか出荷しない。
• パイプラインにも紐づいている。
  
  

1. GUI上で流用元のリグデータを読み込み、任意のモデルデータを指定してビルドを行う。

• 特にモデルに差異が無ければコントローラまで問題なく再現される。
  
• ビルド後に流用元のデータで更新があった場合、更新情報を検知する仕組みにしている。
• 更新された箇所は赤文字で表示される。
  
• 最新リグへの更新は、GUIのボタン操作にて行える。
  

2. 流用元のモデルデータと異なる箇所があれば、差分として追加する。

• 流用時は、GUI上で各モジュールが紫色にハイライトされる。
  
  
• 各キャラクター毎に不要な設定がある場合は、その項目だけOFFにすることもできる。
  
  

＜ピッカー＞

• 自前のピッカーを使用している。
• ピッカーはPysideで開発している。
• アイコンはフリーのアイコン作成ツールを使用している。
• ピッカーは、各モジュールごとにライブラリー化しているものがある。
• カスタマイズやオリジナルで作成する際は、ツールから該当するモジュールのライブラリーを選択し、必要なボタンを追加していく。
  
  
• 追加後はセーブを行い完成。
  
  
• ピッカーのボタンには、ワールドとローカルの切り替えや、FKIKの切り替え機能などを実装している。
  

• 〘 GUIからジョイントを作成時に、ツイスト用のジョイント等も自動で作成されますか？ 〙
  プライマリジョイントもそうだが、ジョイントを自動生成しているわけでは無い。1体目となるキャラクターで作成したジョイントを流用元のジョイントデータとして保存し、読み込んでいる。プロポーションが異なるキャラクターへの調節が必要な場合は、リガーが直接調整している。

• 〘 カートアイコンのボタンで出荷用のビルドを行うとのことですが、パイプラインに紐づいているというこですか？ 〙
  正確にはファイルの保存までを行う。GUI上でアセットの切り替えを行えるため、紐づいている機能はある。

• 〘 開発にどのくらいかかりましたか？ 〙
  開発人数は1人。このツールは全部1から作成して1ヵ月くらい。ただ、過去に似たようなシステムやコントローラを開発したことがあり、これまでの知識を元に作成しているため、10年以上アップデートし続けている感じ。他の細かいツールを含めても、半年かからないくらいで開発した。ちょっとずつアップデートはしている。

今回は、自社制作のリグシステムについてご紹介いただき、質疑応答を交えたディスカッション形式で進行しました。セッション後のフリートークでは、Bifrostやリグシステム導入時のスタッフ教育、フェイシャルリグに関する話題などで大いに盛り上がりました。

ご登壇いただいた小森さん、中谷さん、白砂さん、久保さん、誠にありがとうございました！

次回も引き続き、『リグシステム座談会３』をテーマに開催を予定しています。開催日や応募方法などの詳細は、弊社ブログにて順次告知いたしますので、ぜひ定期的にチェックしていただけますと幸いです。それでは、また次回お会いしましょう！