チュートリアル / Mayaの標準機能だけでリグを作るテクニック
第1回:モジュラーリギングシステム「ARS」概要

2021.01.06

  • Maya
  • アニメ
  • キャラクター・リグ
  • ゲーム
  • コラム
  • 中級者
  • 映画・TV

ご挨拶

皆様はじめまして。今回リグのコラムを書かせて頂くことになりました、ABCアニメーションスタジオの宮本と申します。
弊社で運用予定のリグシステムは現時点ではプラグインレスで開発をしており、異なるパイプライン、会社間でも再現性が非常に優れたものとなっております。
「Mayaってプラグインをたくさん開発しないといけないんでしょ?」と思っている方も多く、今回の記事で少しでもMayaが身近なものとなれば幸いです。

ARS

ARSとは?

言葉で説明する前に、ARSでどんなことができるの?という機能部分をデモリールにまとめました。

「ARS」とは「attach rig structure」の略称です。
つまり、基礎の骨組みに対してリグ機能を後付けで「取り付ける」事が非常にやりやすい構造になっています。
「取り付ける」を強調している理由はこの後説明していきます。

ARSの特徴は、主に以下の部分が挙げられます。
・プラグインレスで動作する (2020/12月現在)
・Maya 2020以降に最適化されており、高速なfpsで動作する
・大半のコントローラが移動、回転、スケールを開放してある
・ギミックの取り付けに対する試行錯誤がしやすい
・リファレンスシーンに対してギミックをアタッチできる

Mayaのバージョンが2020になり、offsetParentMatrixの搭載やUVpinなどの機能だけでなく、実はリグに便利なノードが色々と追加されています。
加えてマルチコア対応やキャッシュプレイバックの搭載など、ここ数年のバージョンアップで「複雑なギミック」を、ある程度現実的な速度で実装できるようになってきました。
そんな背景もあり「プロダクションレベルのリグを、プラグインレスで作る」という悲願が現実味を帯びてきました。
ちょうど私が新しいスタジオを立ち上げるタイミングというのもあり、Maya2020以降の機能をフル活用したリグシステムを0から作りたいと考えたのがARS開発のきっかけでした。

開発のテーマ

ARSを開発開始するにあたって、以下の2つのポイントをテーマとしました。
①機能全盛りリグからの脱却
②ローカル計算主義の脱却

①機能全盛りリグからの脱却

Mayaでリギングをしていると、多数のアニメータからの要望や、あれもこれも想定して準備しておかなければ・・・という考えからたくさんの機能を全盛りしたリグを作りがちです。
例えば逆背骨について。

機能全盛りリグからの脱却

逆背骨はロープにぶら下がったようなアニメーションを作る際にあると非常に便利な機能ですが、使う頻度は長編映画の中でせいぜい数カットというレベル。
そのためにfpsを犠牲にして逆背骨を常に入れ続けるというのはおかしな話です。
さらに、頭をつかまれてぶら下がるようなカットの場合は胸でなく頭まで遡って逆背骨のルートを構築する必要があります。

頭をつかまれた時、逆背骨のルートは頭
頭をつかまれた時、逆背骨のルートは頭
ロープにぶら下がる時、逆背骨のルートは胸
ロープにぶら下がる時、逆背骨のルートは胸

ケースによって必要なギミックはそれぞれです。
他にも、指のIKやコントローラのオフセットなど、「標準には不要だけどカット要件によって時々欲しくなる機能」は、できるだけ省いておきたいものです。
そのため、ARSは「リファレンスされたアニメータの作業用シーンで、アニメータが好きなギミックを後付けする」ことに比重を置いて開発しています。
これによってリガーの思考もシンプルになり、リグをパブリッシュするまでの時間を稼ぐことができます。

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

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

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

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

プロダクションでのリグ運用について

プロダクションでのリグ運用において、非常に大切なのが「再構築性」です。
特にMayaのプロダクションは分業の会社が多く、モデラーの無数アップデートに対して都度リグをアップデートし、かつアニメーションを可能な限り再現性の高い物として維持する必要があります。
例えば・・・

・レイアウト用にプロポーションのみのラフモデルが上がってくる

・ディティールがつき、キャラクタデザイナーのチェックOKとしてモデルが上がってくる(トポロジーはレイアウトモデルからほぼ使いまわせない場合が多い)

・その後運用に対して何度もアップデートがかかる
(エラー対応やバリエーション増加等)

など、何十回(多い時には何百回)とリグのアップデートに対応する必要があります。
そういった場で都度リグを組みなおすのは現実的ではありません。
そのため対応策として、モデリングデータをリファレンスしてセットアップする。作業履歴を全てスクリプトで管理する。など各社あの手この手で工夫をし運用しています。

ARSの場合

ARSでは、主にワークフローを4つのプロセスで区切ります。

① Pre Process

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

② Build Process

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

③ Setup Process

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

④ Post Process

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

扱うデータについて

・メタデータ

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

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

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

・json

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

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

例えば・・・
・スキンウエイトの書き出し
・ドリブンキー情報の書き出し
・カーブのシェイプ情報
・コントローラタグの設定情報

等、人が手作業で行った部分の情報を一度外部ファイルとして書き出しておく事で、再構築時によりクリーンな状態で再現できるようにしています。

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

・バッチ処理について

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

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

GUIについて

ARSは「スクリプトからのアクセス」と「GUIからのアクセス」両方をサポートする事で、テクニカル寄りの人間とアーティスト寄りの人間双方が使えるシステムを目指しています。
そのため、ここまでご紹介したプロセスを実行するために様々なGUIを開発しています。
第1回の最後では、その一部をご紹介したいと思います。

・build

リグを作成するときに使うGUI
リグを作成するときに使うGUI

メニューバーからはアタッチ出来るリグコンポーネントにアクセスできます。
メニューからコンポーネントを選ぶと、別途詳細のウインドウが開きリグを作成する流れとなります。

スプラインIKのリグを組むための別GUI
スプラインIKのリグを組むための別GUI

その下にあるツールは、セットアップデータを.jsonで書き出すためのツール群です。
所定のルールに従ったディレクトリ構成で作業している場合は書き出しを一括で行うことができるようにしており、そのルートパスを指定する事もできるようになっています。

・process

再構築時のプロセスを管理するためのGUIです。

メタデータを元にビルドするための設定をまとめたGUI
メタデータを元にビルドするための設定をまとめたGUI

上記buildで書き出した各要素を、このGUI上から再構成しリグを構築できるようになっています。
各プロセスがタブで分かれており、プロセスごとに実行が可能となっています。


ここまでで、ARSでリグを構築する際にどのような考え・手続きで運用していくかを解説しました。
第一回は少々開発者向けの内容になってしまったため、第二回はリグ初心者の方に向けて具体的な部位をいくつか挙げ、実際にリグを作るテクニックやノウハウをお伝えできればと考えています。

最後まで読んでいただき、ありがとうございました。

製品購入に関するお問い合わせ
オートデスク メディア&エンターテインメント 製品のご購入に関してご連絡を希望される場合は、こちらからお問い合わせください。