＜概要＞

• 複数キャラクターでも高いフレームレートを維持できる軽量な構造。
• ゲーム側の仕様に合わせて作られた既存骨へリグを追加できる。
• 回転のみ、または特定の移動軸のみなど、必要最低限のアニメーションデータを骨へ出力する。
• データ圧縮による誤差の蓄積を避けるため、過度に深い骨階層を前提としない。
• 腕、脚、背骨などを組み合わせるモジュラー式を採用。

＜開発経緯＞

• UZURIG1の開発で得られた知見
  ・約4年間、UZURIG1をベータ版として実案件で検証したが、構造が複雑で正式リリースが難しかった。
  ・モジュール内部の機能まで細かく部品化し、別モジュールでの再利用や差し替えを可能にしていた。
  ・機能の細分化で拡張性は高くなった一方、システムの保守や新規モジュールの開発難易度が高くなった。
  ・個別に機能をONOFFしても大きな高速化につながらず、細かく分割する設計の利点が少なかった。

• UZURIG2の設計方針
  ・上記の理由により、UZURIG2では構造を簡略化。
  ・Two Bone IKやCurve IKなどの共通計算をプラグインノードへ。
  ・各モジュールの構築と接続をPython側で行う設計へ変更。

＜主な特徴＞

• リグ生成後でもコントローラの軸方向や左右の対称・非対称動作の変更が可能。
• 骨の階層とリグの階層を分離。
• 骨のアニメーションをコントローラへベイクできる。
• メタノードとメタネットワークを利用し、生成設定の保存やリグ要素へのアクセスを行う。
• 計算は基本的にmatrixベースで、Offset Parent Matrixと専用プラグインノードを活用。
• コントローラはViewport 2.0専用として実装。

＜実演＞

• UZURIGのサンプルでも使用されている『TA式 鷺宮カノ』を使って実演していただきました。
  +

• UI上で使用する骨とモジュールを指定し、腕、脚、背骨などのリグを構築します。
  基本的な操作は、UZU Rig Setup Toolで行います。
  

• 同列右側のボタンより、設定可能なモジュールの一覧が表示されます。
  一覧から任意のモジュールを選択します。
  

• ビルドに必要な骨をJointListに登録して、Start Buildボタンでビルドを実行します。
  ※下図は足のコントローラをビルドした様子。
  

• 下部にあるSpaceSwitchから、親空間の切り替えが設定できます。
  

• CommonのSideを指定することで、モジュールのミラーリングを行えます。
  ミラーしたコントローラの軸は、Extra AttributeのAxisで設定できます。
  ※下図は右手のコントローラのAxis Rotateを調整している様子。
  

• コントローラの軸調整用のツールも用意されています。
  これらの処理は階層構造を変更することなく、プラグインおよびコントローラに接続された専用ノード内で行われます。
  

• UZU FBXImporterツールで、アニメーションデータを骨からコントローラへ移す事ができます。
  
  骨とコントローラの接続を分離して、骨にアニメーションデータを入力した状態。
  
  ベイクすることでコントローラにアニメーションデータが移る。
  

• その他、いくつかの機能についてご紹介いただきました。
  ・IK／FK切り替えツール
  
  ・スペース切り替えツール
  
  ・アニメーションベイクツール
  

＜UZURIG2では対象としない機能＞

• ピッカー
  既存の使いやすいピッカーツールが複数あるため、UZURIG独自では用意しない。
• リターゲット
  HumanIKなどで骨へアニメーションを流し、その後コントローラへベイクできるため。
• デフォーマーの構築
  骨とスキニング済みメッシュに操作用リグを追加することが目的であり、変形設定は対象外。
• フェイシャルリグ
  ゲーム案件ごとにブレンドシェイプ、独自システム、MetaHumanなど方式が異なる。
  そのため汎用機能としては扱わないが、別途作成したフェイシャルリグとの併用は可能。
• 補助骨の自動制御
  独自システムを持つ会社が多く、UZURIG側で用意すると機能が重複するため。

• 〘 Offset Parent Matrixを使用した場合、親のスケールの影響や移動と回転を別々に制御する処理はどのように行っていますか？〙
  用途ごとの専用プラグインノードを用意し、その内部でmatrixを計算している。移動と回転を分離する場合も、別の専用ノードを使用しています。

• 〘Matrix計算にはMaya標準のmultMatrixなどを使用していますか？〙
  一部で標準ノードを使用する場合もあるが、主要な計算には独自のプラグインノードを使用している。Mayaのバージョンによる標準ノードの名称変更や仕様変更を避ける目的もある。

• 〘 コントローラの軸を生成後に変更する際、階層構造も変更しているんでしょうか？ 〙
  アウトライナ上での階層は変更せず、コントローラのOffset Parent Matrixへ接続された専用ノード内で座標変換を行っています。

• 〘人型キャラクター以外にも対応できますか？〙
  四足用のドッグレッグモジュールが用意されており、人型以外にも対応可能です。翼など専用モジュールがない部位については、既存モジュールを組み合わせるか、新規モジュールを追加する必要があります。

• 〘プロジェクト独自のモジュールを追加することは可能ですか？〙
  追加可能です。Pythonで実装でき、既存モジュールをベースに増やすことができます。ただし、UZRIG2のモジュール作法には沿う必要があります。mGearなどで同様の拡張経験がある方であれば、それほど難しくないと思います。

• 〘UZURIG2はゲーム向けに設計されていますが、映像制作でも使用できますか？ 〙
  主にゲーム開発を想定しているますが、UZURIG1は映像案件でも使用された実績があり、映像制作での利用も可能です。

次回に続く。