②ローカル計算主義の脱却

旧来のMayaは、高速に動作するリグを作るために「ローカル計算」を多用することが多くありました。
例えば「腕から手まで」という範囲内にひねりやカーブリグ等複雑なギミックを入れ込んでいく際、ワールド計算（コンストレイン等）をしてしまうと他の部位（例えば背骨）が動いた際も、このギミックの計算が走ってしまいます。

ローカル計算例。赤の部位に複雑なギミックを入れる場合、その範囲内で計算を完結させることができれば、背骨や腰などを動かした時に腕のギミック分計算が省かれて高速になる・・・はずだった。

そのため、腕から手までで必要になるギミックは、その範囲内で計算を完結させてあげる事で高速なfpsを実現しようという考え方です。
しかし、近年のMayaはキャッシュや計算スケジューリングのおかげで、ワールド計算の処理が非常に高速になりました。
その結果手の込んだローカル計算をしてしまうと、帳尻を合わせるために入れ込んだ複雑なノード・コネクションが負荷となり逆に重くなってしまう。という反転現象が見られ始めました。
ローカル計算をすることで複雑なギミックを実装しやすくなる・・・といった機能的に必要な部分は残しつつ、不要なローカル計算を割り切ってワールドで計算するようにし、その分ノード数を減らそうというのがこのリグのテーマでもあります。

① Pre Process

ジオメトリやスケルトン等、必要なデータをインポートするパート。
基本的にバッチ処理で行います。

② Build Process

FKやIK等、コントローラやギミックを構築していくパート。
GUIとスクリプト両方からの構築が可能ですが、いずれもメタデータが履歴として残り、正確な再構築が可能となります。
もちろん、アニメータがカット内でアタッチしたリグも履歴が残りますので、それを使って他のカットで再流用する事も可能です。

③ Setup Process

デフォーマやドリブンキー等、手作業が多く発生するパート。
各要素は.jsonで書き出しておき、それを元に正確な再構築が可能となります。

④ Post Process

出荷前のファイナライズ処理を行う。
基本的にバッチ処理で行います。

・メタデータ

リグ機能そのものの作成履歴は「メタデータ」として残ります。

引数と値をセットとして扱うため、辞書形式と相性がいい

ARSにおけるメタデータとは、本体の動作やギミックには関係のない「付加情報のみを持たせたノード」を指します。
ARSのリグコンポーネントはpythonの辞書形式で統一しています。そのため「attrとvalue」を、そのまま辞書の「keyとvalue」に置き換えたシンプルな物となっています。
こちらは本来プラグインで開発した方が秩序立った運用が可能ですが、今回はプラグインレスでの運用を目指すため「トランスフォームノードにuserDefindAttributeを足す」という最もシンプルなやり方で運用しています。

・json

セットアップデータの書き出しには.json形式を採用しています。

ドリブンキーの情報を書き出した.jsonファイル

例えば・・・
・スキンウエイトの書き出し
・ドリブンキー情報の書き出し
・カーブのシェイプ情報
・コントローラタグの設定情報
等、人が手作業で行った部分の情報を一度外部ファイルとして書き出しておく事で、再構築時によりクリーンな状態で再現できるようにしています。

.json形式 (JavaScript Object Notation)は、元々JavaScript用のフォーマットです。
人間から見ても読み書きが簡単で、コンピュータからのパースも行えることからpython等多言語でも広く使われている形式です。
pythonの「辞書形式」と記述が非常に似ている事からも使い勝手が非常に良く、ARSではセットアップデータの書き出しだけでなくリグシステムの環境情報等も.jsonで扱っています。

・バッチ処理について

例えばデータの読み込みについては、所定のディレクトリから要件を満たしたファイルを全てインポートする。といった簡単なもの。
他、アニメータがキーを打ってはいけないノードのロック。初期値の記憶など「条件付けをして一括処理ができるもの」をバッチ処理として扱っています。
主に、プリプロセスとポストプロセスはバッチ処理で運用しています。

バッチ処理を行うGUI。コマンドからも実行可能。