2018年2月24日（土曜）に開催された「Rigging help me !」セミナームービーが誰でも視聴可能になったそうです。Maya界隈でよく使われるローカルセットアップについての映像です。
https://support.borndigital.co.jp/hc/ja/articles/360002870994
アバター 2 で使用された新しいフェイシャル パイプラインの記事が公開されています。
Wētā FXは、まったく新しいフェイス・パイプラインを開発しました。この画期的な新アプローチを最初に開発したのは2019年だが、同社は『Avatar: The Way of Water』の公開に合わせて、韓国で開催されたSIGGRAPH ASIAで新しいアプローチを公開したばかりです。この徹底討論ではWētā FX Snr.に直接話を聞いている。VFXスーパーバイザーのJoe Letteri氏と、テクニカルペーパーの他の著者の一人であるKaran Singh氏に、新しいアプローチを開発する決断をした理由について、直接話を聞きました。
フェイシャルアニメーションの新しいシステムは、FACSパペットから解剖学的ベースとしての筋繊維曲線に移行することに基づいています。この新しいアプローチは、Anatomically Plausible Facial SystemまたはAPFSと呼ばれ、アニメーター中心で、解剖学的な発想から生まれた、顔のモデリング、アニメーション、再ターゲッティング転送のためのシステムです。
新システムは、Wētā FXが『ゴラム』以来一貫して使用してきた、受賞歴のあるFACSパイプラインに代わるものです。映画『アリータ：バトル・エンジェル』（2019年）のためにR&D FACSアプローチを極めて強く押し出したLetteri氏は、FACSベースのパペットシステムには、顔の筋肉の分離、カバー、線形組み合わせ使用、広域冗長性などの大きな問題が多すぎるだけだと判断しました。
例えばFACSは筋肉主導の表情を表す顔のポーズのセットをマッピングしますが、適切なフェイシャルアニメーションを得るために、FACSパペットリグは、アニメーターが信じられるパフォーマンスを達成できるように、900ものFACS形状をリグに追加することになってしまうかもしれません。FACSが「間違っている」のではなく、タイムベースのフェイシャルアニメーションのために設計されたシステムではないのです。FACSは音声を中心に構築されたものではなく、むしろ孤立した感情表現を中心に構築されたものです。
「私たちは、アーティストが顔の動きを直接コントロールできるシステムが必要だったのです」とLetteri氏は語る。「FACSはあくまで感情ベースのシステムであり、表情をコード化するものです。FACSには対話はありませんし、私たちがやっていることはほとんど対話です。FACSは正確な孤立した表情を表すかもしれませんが、ポーズ間の移行方法に関する情報はありません。結局、一種の推測をしなければなりません。移行を直感するようなもので、それは素晴らしいことですが、維持するのは困難です」とLetteri氏は説明しています。FACSシステムは、状態から状態へ移行するときに、基本的に顔全体に直線的に状態変化が起こるので、非常に "rubbery "なのです。
Letteri氏と彼のチームは、フェイスパイプライン全体をゼロからやり直すことにしました。「私はこの問題を見て、こう思いました。これはもうやりたくない。これは難しすぎる。もっといい方法があるはずだと。顔の筋肉がどのように配置され、どのようにつながっているのか、もう一度見直してみました。そして、その結合をマップ化すれば、顔を表現する高次元空間の基礎ができることに気づいたのです」。
チームは、表情が作られ、筋肉が活性化すると、他の筋肉が連動して活性化したり、筋肉が受動的に引っ張られたりすることに着目しました。"筋肉が神経ネットワークによく似た一種のネットワークで相互接続しているため "と、Letteri氏は推論しています。
「そこで私は、筋肉を直接ベースとする神経回路網を作ればいいのではないかと考えたのです。つまり、多くのディープラーニングは、問題に数字を投げかけて、たくさんのデータを与えれば、相関関係を割り出してくれようとするものなのです。でも、私たちはすでに相関関係を知っているのだから、それを基礎としてコード化すればいいのでは？数学の世界に入り込めば、それは大きな微分積分の連鎖になります。基本的な微積分です」。
そしてチームは、アニメーターが顎、目、筋肉のどのような組み合わせでも表現できるようなシステムを構築することを目指しました。「ベースとして、例えばシガニー・ウィーバーの顔を見て、"筋肉 "が何をしているかを解くようにシステムを訓練し、それを別のネットワークでキャラクターに転送できるのは素晴らしいことです」。
さらに、筋肉カーブにより、アニメーターは顔の筋肉ごとに直接コントロールできるようになりました。ただし、筋肉曲線は、皮膚の下にある実際の筋肉と1対1で一致するように設計されているわけではないことを指摘する必要があります。筋肉曲線は、アニメーターがコントロールできる方法で、かつ、非常に高い忠実度でキャプチャされたパフォーマンスである顔の動きと一致するように、顔を解決するように設計されています。
新しいAPFSは、178本の筋繊維の曲線、つまり「歪み」の曲線に基づいています。これらの筋繊維曲線が収縮・弛緩することで、きめ細かく忠実な人間の顔の表情が得られます。エンドツーエンドのシステムは、インワードアウト（顔が筋繊維曲線によって駆動される）とアウトサイドイン（アニメーターが顔の表面から顔を「正しく」ドラッグして動かすことができる）の両方が可能です。
このシステムは、人間の筋肉を1対1でマッピングしているわけではありません。上唇の湾曲など、顔のいくつかの側面は、実際には顎や下顔面の筋肉によって駆動されている結果だからです。むしろ、このシステムは178の曲線からなる配列であり、解剖学的なインスピレーションに基づく一連の制御を可能にしますが、肉／筋肉の直接的なエミュレーションやシミュレーションではありません。
さらに、FACSの人形はFACSの表情の直線的な組み合わせで作られており、回転は含まれていません。眼球を中心とした回転成分を自然に含む正しいまぶたのアニメーションを得るには、一連の中間的なFACS形状を追加する必要があります。
各筋肉または歪み曲線には、関連する歪み値があります。筋肉のカーブは実際にはねじれませんが、ひずみ値はカーブに沿って、その局所空間における収縮または拡張を提供します。ある意味これは長さの変化率です。実際の曲線のひずみ数値は単位がなく、これは異なる文字に転送する際に役立ちます。ひずみ値は単独で機能するというより、セットの一部として機能します。
例えば、まぶたの瞬きには、まつ毛のラインに沿った筋カーブ（水平方向）と、直交方向（目の周りの上下方向）の両方が存在する。この場合、水平方向の曲線は眼球の上を回転しているため、実際のひずみ値はあまり変化しませんが、垂直方向の曲線はひずみ値が劇的に変化しています。
しかし、最も重要なのは、垂直カーブが筋肉のカーブ形状に沿ってスケールすることで、これは眼球のカーブと一致します。開いているブレンドシェイプと閉じているブレンドシェイプの間の同様の遷移は、（眼球の周りで曲がることなく）閉じてから開くまで直線的に移動するだけです。
Mayaでは、ブレンドシェイプをチェーンして、眼球の周りでカーブするまぶたをシミュレートすることができますが、これもブレンドシェイプの数を増やしてしまうことになります。
FACSソリューションは、フェイシャルリグの標準化を可能にしましたが、FACSは顔の表情の自発的で区別できるスナップショットをキャプチャするために心理学の観点から設計されており、コンピュータアニメーションに適用すると明らかに限界があります。
FACSのアクションユニット（AU）は、複数の表情筋の動作を組み合わせるAUや表情筋が全く関与しないAUのように、望ましい表情を得るために引き算で組み合わせる必要がある）、定位とアニメーション制御（冗長、動作が反対、強く関連、または相互に排他的なAUがあり得る）、AUはヒンジでつながれた顎と人間の唇の複雑な形状変形にしか近似しないなどです。
新システムの構築には、機械学習が用いられました。80の動的モーションクリップから6000〜8000のスキャン（フレーム）を使用しました。約60%がFACSの形状ポーズ、40%がスピーチモーションです。各俳優の演技は、検証されたグランドトゥルース表現から340のマーカーを基に解かれました。APFSパイプラインは時間情報をエンコードせず、これはパフォーマンスキャプチャの解答そのものから得られるものである。アニメーションは俳優の動きと表情を本質的に追跡します。
新しいシステムでは顎と唇が特に注目されています。「システムを構築しているときに気づいたことのひとつに、顔の状態をコントロールする主要な手段が顎であるということがあります」とLetteri氏は語ります。
「特に対話の場合、顎は常に動いています。 さらに、人の顎は盾の軌跡の形でしか動かないので、顎が状態を動かす主役です」とLetteri氏は説明します。下顎骨は顎関節を介して頭蓋骨に固定され、靭帯と筋肉で支えられている。そのため、顎の可動域は、顎の想定される点の集合をトレースすることでマッピングすることができます。このような点の集合を人物のあらゆる台詞や表情に対応させると、盾のような形状になります。これを「ポッセルトの運動包絡線」または「ポッセルトシールド」と呼びます。
「このシールドは、ドライバー自身の制約システムに組み込まれています。"筋肉はその上で解かれます" というのも、チームがどの俳優を解析するときでも、デジタル頭蓋骨を俳優に適合させるフォレンジックフィットを行うからです。次に、顎の可動域を把握し、HMCのステレオカメラを使って深度情報を抽出します。そして、PCAを実行して、コヒーレントなメッシュが得られるように、最適なフィッティングを試みます。そして、そのメッシュに顎と頭蓋骨をフィットさせるのです」。
パフォーマンス・キャプチャーの場合、人間の動作にはすでに動きや可動域が含まれています。しかし、手作業でアニメーションを作成する場合は、Jawコントローラにシールドの制約が組み込まれます。アニメーションの検証は、その俳優の各カメラから取り込んだ画像に対して、歯並びを観察することで行いました。
同様に、俳優の目も非常に慎重に扱われています。システムの目のモデルは、アクターの強膜、角膜、虹彩にマッチしています。虹彩モデルが、各カメラから取り込まれた画像に見える辺縁リングと瞳孔に一致するように、眼球を回転させることによって、各フレームで視線方向を調整するのです。眼球はレンズ効果や屈折を示すため、追跡するのが非常に難しいのです。複数のカメラアングルを使用して、アライメントを確認し、角膜によって屈折する光を考慮します。 正面からの小さな目の膨らみも、それぞれの目の回転に適用して、キャラクターの目のリアリズムを高めています。
曲線筋は単なる線であるため、歪んだ筋肉とデジタルキャラクターの皮膚との間にリンクが必要です。曲線は筋肉の動作の線を捉えているのですが、実際の顔の中にも埋め込まれているのです。
ここでは、キャラクタの静止ポーズにおける顔の軟組織を離散化した四面体ボリュームを使用したボリューム表現によって、顔をシミュレートしています。テトのボリュームソリューションは、皮膚と、頭蓋骨と顎の骨の間に位置します。テトは概念的または数学的な「ゼリー」を形成しています。このテトボリュームに対して、皮膚の頂点と頭蓋骨を位置拘束として、スキャンシーケンス全体に対してパッシブな準静的シミュレーションを実行します。有限要素解析（FEA）を用いて，135,000 個のテト（複数の位置拘束，スライド拘束，衝突拘束を持つ）の「パッシブシミュレーション」をフレーム単位で行い，解剖学的にもっともらしい肉の挙動を生成しています。ここで生成される「肉付けマスク」は、学習段階での役割しか持ちません。
顔の筋肉はリボン状の筋肉であることが多いのですが、APFSのカーブには幅がありません。そのため、必要な部分にカーブを追加しています。筋肉カーブはアクティブマッスルシムではありません。「実際、アニメーターはそれを望んでいません。彼らはフレーム間の制御を望んでいます。彼らは運動学的な変形制御を望んでいるのです。シミュレーションの設定をした後、再生を押して、実際のアクティブなシミュレーションが引き継がれるのを見たくはないのです」そのため、チームは曲線表現を選択し、「曲線にこだわることにしたのです」と彼は付け加えます。「私たちは、できる限り最小限の、絶対的なパラメトリック表現を採用したのです」。
Karan Singh氏はCOVIDの直前、2020年にVictoria Universityに客員研究員として滞在していたため、チームに参加しました。彼は、自分が主席研究員ではないことを最初に言いますが、SIGGRAPH ASIA Submissionにプロセスを書き上げる上で大きな役割を果たし、ライブプレゼンテーションを行ったByungkuk Choi Haekwang EomとBenjamin Mouscadetと共に韓国でプレゼンテーションに参加したのです。
各エンジニアは、大規模なエンドツーエンドのソリューションの一部として、特定の焦点とモジュールを持っていました。この論文には、Joe LetteriとKaran Singhを含む12人の著者がいます。
Singh氏は、以前AutodeskのMayaでオリジナルのブレンドシェイプコードを書いた経験があり、FACSパペットで使用される詳細なコードに精通しています。Singh氏は新しいパイプラインの内部で機械学習（ML）オートエンコーダ（AE）を巧みに利用し、表現をオンモデルに保っていることを指摘します。
MLはWētāのようなパイプラインを変革しているが、多くの人がまだ十分に理解していない方法です。 VAEとそのディープフェイク・フェイススワップツールとしての使用については多く書かれていますが、APFSチームはここで、AEなどのMLツールが、最終的なピクセルに明示的に使用されない一方で、重要なタスクを支援するために複雑なパイプラインの内部で使用されていることを紹介しています。
このシステムは従来のFACSブレンドシェイプを使用して簡単にモデルから外れることができますが、ソリューション空間はAEによって制限されています。「初期テストや個々のキャラクターのトレーニングデータを定義するとき、そのキャラクターの範囲を設定しているのです」とSingh氏は説明します。「オートエンコーダーはそれを一種のエンコードとして扱うので、エンコードするのは一般的な設定だけではありません。つまり、一般的な設定をエンコードしているのではなく、非常に特殊なパフォーマンスをエンコードしているのです」。パイプラインの構築方法におけるAEは、ターゲットとモデル通りの顔を維持します。
アニメーターは当然ながらポーズライブラリを持つことに慣れています。しかし、ポーズは動きを強制したり、符号化したりするものではないので、組み合わせによって簡単にモデルから外れてしまうことがあります。そこで、アニメーターが使いやすいように、ひずみベースのモーションライブラリが作られました。
このアウトサイドインのアプローチは、カーブへのインバースマッピングを提供します。しかし、システムの構築方法とオートエンコーダの使用により、アニメーターが誤ってモデルから外れることはありません。筋肉の伸縮は直感的に理解できても、歪みベクトルで顔の表情を動かすのは一筋縄ではいきません。そこで、AE（オートエンコーダ）を導入し、ひずみベクトルが顔アニメーションの妥当な範囲に収まるように制約をかけることで、アーティストを支援します。
このモデル上の解空間を表情多様体と呼びます。ここで何が妥当かを定義するのはアニメーターであり，アニメーターは意図的にモデルから外れることを選択できますが，表情多様体は，複数の表情とそれに対応するひずみベクトルまたは設定の範囲から厳選されたサンプリングを用いて，アニメーターのために推定されます。
アバター：ザ・ウェイ・オブ・ウォーターでは、多くの俳優が水中でパフォーマンスをキャプチャしていましたが、顔のアニメーションのほとんどは、乾いた土地での二次キャプチャに基づいており、それをメインのパフォーマンスキャプチャにブレンドしていました。顔のパフォーマンスキャプチャを行う際、アクターはステレオヘッドリグ（HMC）を装着しましたが、新しい技術のおかげで、アバター1のオリジナルHMCよりも重くありませんでした。
HMCカメラの固定ステレオ配置のおかげで、WētāのチームはDeep Shapeという強力な新しいビジュアライゼーションツールを開発しました。このステレオ画像を使って、俳優の実際の演技を3D点群風に再現し、どの角度からも見ることができるようにしました。画像はモノクロでポリゴン化されていませんが、実際の演技を高度に再現しています。
この新しいビジュアライゼーションにより、アニメーターは、実際のキャプチャーカメラの生の出力のような広角の歪みや奇妙な視野角なしに、顔からわずか数フィートの距離で撮影されたかのように、仮想の目撃者カメラを持つことができるようになるのです。
このような3D深度再構築ビューにより、唇や顎の伸展を観察し、後で完全に制御可能で再構築されたアニメーションが生ビューに忠実であるかどうかを判断する、より強力な方法を提供します。このように著しく便利な表示装置であるため、これまで誰も実装していなかったことが不思議なくらいですが、私たちの知る限り、Wētā FXはDeep Shape可視化オプションを正確に実現した最初のチームです。このツールは、APFSエミュレーションを比較・判断するための顔のグランドトゥルースの重要な参考ツールになります。 これは、新しいエンド・トゥ・エンドのAPFSベースのソリューションのもう一つの革新です。
現在では一般的な手法として、俳優の顔の表情に合わせたデジタルダブルを非常に忠実にアニメーション化し、そのアニメーションをキャラクターモデルに転送しています。Wētāは、アニメーション転送時に俳優とキャラクターの顔の一致を最大化するために、対応する俳優の基本的な筋肉の挙動を共有するように、戦略的にキャラクターのトレーニングプロセスを設計しています。
3Dキャラクターの顔モデルは、最終的にそれぞれの俳優と同じ、共有された歪みオートエンコーダーを持つことになります。皮膚は正確にマッピングされ、目と顎の領域はユーザー定義のウェイトマップを使って別々に処理され、顔の重要なパーツをより正確に表現できるようになります。当然ながらナヴィのユニークな形状を考慮し、チームはアクターの顎のリグをキャラクターに慎重に適合させ、歯のトポグラフィーと頭蓋骨の解剖学の偏差を補償するためにそれを使用する必要があります。
カーブマッスルシステムは、首の部分までカーブが伸びており、ボディパフォーマンスキャプチャとの統合をより良くしています。耳については、まったく別のコントロールが用意されています。
「今回、わざわざキャプチャーしようとしなかったのは、耳は一種の二次的効果だからです」とLetteri氏は言います。「ナヴィの耳は表情豊かですが、人間には全くありません。ですから、あれはあくまで別のアニメーション制御システムなのです」
この映画では、当然ナヴィへの再ターゲットが多数ありますが、重要なのは、2つの重要な脱老化の再ターゲットがあることです。俳優のシガニー・ウィーバーとスティーブン・ラングは、ともに若いキャラクターに再ターゲットされています。キリと若いクオリッチです。
顔の筋肉の緩みや老化をシミュレートするために歪みの値を変えることを検討する人もいるかもしれませんが、Letteri氏は、リターゲティングがそれを完全に補うので、歪みの値を「緩和」したり伸ばしたりする必要がなかったと指摘しています。 「そうすることも考えましたが、それでは不確実性が増してしまいます」とLetteri氏。「そこで、まずはリターゲティングで試してみようと考えました。そして、それを実行したのです。そして、うまくいくようになりました。
CLIP STUDIO PAINTの漫画パースが特許取得してると話題なってたのでメモ。ボーン単位で変形してるっぽい？
https://astamuse.com/ja/published/JP/No/2014149748
https://prtimes.jp/main/html/rd/p/000000046.000005223.html
マンガ的なパース表現（目前に迫るパンチの拳だけが極端に大きく描写される等）は、マンガやイラストで迫力や臨場感を表すためによく用いられる表現技法のひとつです。このマンガ的なパース表現の作画を支援するために「マンガパース」機能は開発されました。
「マンガパース」機能は、マルチパースペクティブと呼ばれる考え方に基づいて、複数のカメラパラメータを一毎の絵に合成する方法により、3Dモデル側の変形を一切伴わずに、マンガ的なパースが適用された3D空間の表示を実現するものです。ポーズやアングルが変更されても、リアルタイムにマンガ的なパースが表示されます。
既に過去、同様の表示結果をもたらす技術はありましたが、それらは固定のポーズやアングルにおいて、3Dモデル側を変形させることでマンガ的なパースを実現しており、少しカメラを動かしたり、モデルを移動・回転させると、見た目の大きさや形状のバランスが崩れてしまうため、3Dモデル側を都度変形させる必要がありました。
3Dモデルを活用したマンガ制作の過程では、ポーズやアングルの試行錯誤が必要で、それに耐えられる技術の登場が待ち望まれていました。
この「マンガパース」機能は、独立行政法人情報通信研究機構(NICT)の委託研究「革新的な三次元映像技術による超臨場感コミュニケーション技術の研究開発」において東京大学苗村研究室と（株）日立製作所が案出した技術に基づき、（株）日立製作所の協力のもと開発したものです。
modoのキャラクターアニメーションのパフォーマンスについて書いてみます。
modoはキャラクターアニメーションのパフォーマンスが遅いという問題があります。この問題を改善するためmodoは段階的にパフォーマンス改善しています。
modo 15.1になってMaya、3dsMax、LightWaveなど、他の3Dソフトで見かけるアニメーションパフォーマンスを改善する機能が一通り搭載されたように思います。
ハイポリのサブディビジョンメッシュを滑らかにアニメーションできるような改善には至っていませんが、現時点でアニメーションを作成する場合に、どのような所に注意した方がよいのかまとめてみたいと思います。
modoのアニメーション再生が遅い原因でよく言われるのが「デフォーマの計算が遅い」です。
リグ単体では早いのに、スケルトンにバインドした場合や、デフォーマを追加した場合にパフォーマンスが遅くなるので「デフォーマの計算が遅い」と言われていました。
しかし、開発者の方の発言によるとmodoのデフォーマはマルチスレッドで計算しており、実際の原因はグラフィックボードに送信するためのデータ生成(メッシュの細分割、三角形のインデックスの生成、法線計算、位置の計算)がボトルネックになってるとのことです。
この計算はデフォーマを使用していると毎フレーム発生するので、デフォーマ計算が遅いと思われていました。
modo 13.1ではボトルネックを解消するためサーフェス計算が新しく書き直されましたが、サブディビジョンサーフェースやカーブなど、一部のポリゴンタイプはまだ作業中です。(この書き換えによってデフォーマキャッシュが使用できなくなったのが残念です)
グラフィックボードに送信するためのデータ生成がボトルネックということは、強力なグラフィックボード(GPU)にすればアニメーションのパフォーマンスがよくなるのでしょうか？
残念ながら劇的に速くなくことはありません。昔からmodoのビューポートパフォーマンスは、GPUよりCPUの速度の方が重要だと言われています。Windows10のタスクマネージャーを使用するとGPUの使用率を見ることができますが、modoはGPU使用率が低いことがわかります。
もちろんGPUレンダラーのmPathや、NVIDIA OptiXデノイザなどGPUを使用する機能を使う場合はGPUの性能が重要になりますが、modoのアニメーション再生やビューポートパフォーマンスには大きな影響はありません。
ゲームエンジン的なアプローチのアドバンストビューポートを使用するとGPU使用率が上がりますが、デフォルト表示に比べてアドバンストは描画速度が遅いのでアニメーション作成に使用するのはお勧めしません。
恐らくボトルネックになるサーフェス計算がCPUでおこなわれているため、modoではGPUよりもCPUのクロック数が高い方がパフォーマンスへの影響が大きいのかなと思います。以上のことから、modoでアニメーションを速くするには以下の2つが重要になります。
modoに限らず3DCG全般で同じ事が言えますね。
前置きが長くなりましたが、modoでキャラクターアニメーションの再生パフォーマンスを速くした場合は以下の点に注意するといいです。
以降ではキャラクターアニメーションのパフォーマンステストについて書いてみます。
キャラクターアニメーションを速くする方法をまとめるにあたり、「ポリゴン数」「リグの速度」「ビューポートの表示」の設定を切り替えて、アニメーション再生のパフォーマンスをテストしました。
自分のPC環境でファイルをダウンロードして検証できるように、modoで代表的なリグであるCharacterBoxとACSのサンプルシーンを使用しました。
modo 15.1v1
アニメーション再生のパフォーマンスはGLメーターで表示されるフレームレートを参考にします。
「リアルタイムで再生」はOFFにします。
「リアルタイムで再生」はシーンのフレームレートを維持するように再生するオプションで、ONの場合はアニメーションの再生速度が低下した場合にフレームをスキップすることで、シーンのフレームレートを維持しようとします。
OFFにするとシーンのフレームレートに関係なく、再生可能な最高のパフォーマンスでアニメーション再生します。アニメーションの再生速度が低下した場合でも毎フレーム描画するので、パフォーマンスを調べる場合は「リアルタイムで再生」をOFFにする必要があります。
一口にキャラクターアニメーションと言っても「ポリゴン数」「リグの速度」「ビューポートの表示」など様々な要素で構成されています。
個々の要素ごとに分解して何がどのくらいアニメーションに影響を与えているかテストしたので、キャラクターアニメーションの参考にしてください。
まずはmodoデフォルト状態のパフォーマンスです。
モデルのポリゴン数を近くするため「Human.lxo」はサブディビジョンレベルを3から2に変更、「Bolo_Walk.lxo」は1から2に変更しました。
ポリゴン数は「Human.lxo」が59,296トライアングル、「Bolo_Walk.lxo」が33,600トラインアングルです。
画面キャプチャーしてるので、少しフレームレートが遅くなってます。また、記載してるフレームレートはおよその値です。
85FPS。
34FPS。
ポリゴン数の違いによるパフォーマンスをテストしました。
ポリゴン数が多ければ当然遅くなるのは予想できますが、サブディビジョンサーフェースを使用した場合と使用しない場合、サブディビジョンの種類でどのような変化があるかテストしました。
アニメーション用途ではSub-D、OpenSubdivが適していそうです。
ゲームのようなリアルタイム向けモデル以外は、サブディビジョンサーフェースを使用する場合が多いのではないでしょうか。
modoには3種類のサブディビジョンが搭載されていますが、各サブディビジョンでのアニメーション速度をテストしました。
サブディビジョンサーフェースはポリゴンを細分割して、曲線的なモデルを作成する機能です。Sub-DとCatmull-Clarkでは分割アルゴリズムが異なるので、サブディビジョンレベルによってポリゴンの増加量が違います。
79FPS。レベル 0よりレベル1の方がフレームレート出るので、レベル 0は最適化されていない等の問題がありそうです。
33FPS。レベル 0からレベル5までフレームレートに大きく変化がないので、このような単純なモデルの場合サブディビジョンよりACSのリグ計算がフレームレートのボトルネックになっていると思われます。
98FPS。
33FPS。
88FPS。
32FPS。
74FPS。
31FPS。
59FPS。
29FPS。
49FPS。
28FPS。
69FPS。
33FPS。
74FPS。
32FPS。
39FPS。
25FPS。
18FPS。
18FPS。
7.4FPS。
9.7FPS。
2.3FPS。
3.7FPS。
演算には「マルチスレッド」を使用しています。「CPU」より「マルチスレッド」の方がわずかにパフォーマンスがよかったのですが、1CPUしか使用しないようです。
本来はGPUが最もパフォーマンスがいいはずなのですが、PC環境のせいでGPUを設定するとmodoがクラッシュするため、GPUを使用してテストできませんでした。
80FPS。
35FPS。
104FPS。
36FPS。
83FPS。
34FPS。
46FPS。
29FPS。
17FPS。
18FPS。
4.8FPS。
7FPS。
サブディビジョン OFFの状態で、Catmull-Clarkを使用して細分割したモデルをアニメーションしました。
110FPS。
34FPS。
69FPS。
32FPS。
26FPS。
19FPS。
7.3FPS。
7.3FPS。
1.7FPS。
1.9FPS。
サブディビジョンレベル 5は重すぎるので省略です。フレームレートのテストを表にすると以下のようになります。
サブディビジョンをONにすると、元のポリゴン数がサブディビジョンレベルに応じて細分割されます。サブディビジョンレベルを3以上にした場合、Sub-DよりCatmull-Clarkのほうがポリゴン数が多くなる。
|
Sub-D
|
Catmull-Clark
|
|
| サブディビジョンレベル 1 |
4 倍
|
4 倍
|
| サブディビジョンレベル 2 |
16 倍
|
16 倍
|
| サブディビジョンレベル 3 |
36 倍
|
64倍
|
| サブディビジョンレベル 4 |
64 倍
|
246倍
|
| サブディビジョンレベル 5 |
100 倍
|
1024倍
|
|
サブディビなし
|
Sub-D
|
Catmull-Clark
|
OpenSubdiv
|
|
| サブディビジョンレベル 0 |
110 FPS
|
79 FPS
|
69 FPS
|
80 FPS
|
| サブディビジョンレベル 1 |
69 FPS
|
98 FPS
|
74 FPS
|
104 FPS
|
| サブディビジョンレベル 2 |
26 FPS
|
88 FPS
|
39 FPS
|
83 FPS
|
| サブディビジョンレベル 3 |
7.3 FPS
|
74 FPS
|
18 FPS
|
46 FPS
|
| サブディビジョンレベル 4 |
1.7 FPS
|
59 FPS
|
7.4 FPS
|
17 FPS
|
| サブディビジョンレベル 5 |
49 FPS
|
2.3 FPS
|
4.8 FPS
|
|
サブディビなし
|
Sub-D
|
Catmull-Clark
|
OpenSubdiv
|
|
| サブディビジョンレベル 0 |
34 FPS
|
33 FPS
|
33 FPS
|
35 FPS
|
| サブディビジョンレベル 1 |
32 FPS
|
33 FPS
|
32 FPS
|
36 FPS
|
| サブディビジョンレベル 2 |
19 FPS
|
32 FPS
|
25 FPS
|
34 FPS
|
| サブディビジョンレベル 3 |
7.3 FPS
|
31 FPS
|
18 FPS
|
29 FPS
|
| サブディビジョンレベル 4 |
1.9 FPS
|
29 FPS
|
9.7 FPS
|
18 FPS
|
| サブディビジョンレベル 5 |
28 FPS
|
3.7 FPS
|
7 FPS
|
サブディビジョンレベルを上げれば当然パフォーマンスが低下する結果になりましたが、いくつか興味深いことがわかりました。
今回テストしたモデルではOpenSubdivとSub-Dのパフォーマンスがよいようです。
modoにはOpenSubdivがオープンソースとして公開される前に、ピクサーから直接ライセンスしたCatmull-Clarkを独自に実装していました。このCatmull-ClarkはOpenSubdivよりトポロジー編集が速い物だとのことですが、やはりアニメーションの再生では、OpenSubdivの方が高速なようです。
Sub-Dも決して遅くないので、アニメーションではOpenSubdivかSub-Dを使用するのがよさそうです。ただしOpenSubdivは少し動作が不安定でクラッシュしやすいように感じました。
modo 15.1でサブディビジョンレベルを0に設定すると「ケージ」が有効になる機能が追加されましたが、サブディビジョンレベル 0より、レベル1の方がフレームレートが高いです。
バグなのか最適化が進んでないためか原因はわかりませんが、パフォーマンスを重視する場合はレベル 0を使用せずに、TabでサブディビジョンをOFFにした方がよいです。
modoはTabで非破壊的にサブディビジョンを適用することができますが、サブディビジョンをフリーズするよりも、Tabで非破壊サブディビジョンを使用した状態の方がパフォーマンスがよいようです。
modo 13.1でサーフェス計算コードの書き直しがおこなわれ、場合によっては3倍高速化しているとのことです。サブディビジョンよりもサブディビジョンをフリーズした方がパフォーマンスがよくなる場合があるかと思いましたが、非破壊サブディビジョンを使用した方がいいようです。
サブディビジョンレベルを上げるとポリゴン数は指数関数的に増えますが、FPSは思ったより落ちないようです。
キャラクターアニメーションでは、使用するリグの計算速度も重要です。
アニメーション作成では何度も再生しながらタイミングを調整します。どんなに便利な自動制御が組み込まれたとしても、リアルタイムで再生できないリグには価値がありません。静止画の場合でも動作が速いほうがトライアンドエラーがしやすくなるので、リグの速度は重要です。
ここではCharacterBoxとACSを使用してリグの速度を測る方法を紹介したいと思います。リグの速度は全てのアイテムを非表示にするとわかります。
まずはリグをベイクした状態の速度を見てみます。CharacterBoxもACSもリグをmodo標準のスケルトンにベイクすることができます。
ここではフレームレートの変化がわかりやすいように、サブディビジョンレベル2でフリーズしたメッシュを使用しました。
Human.lxo
Bolo_Walk.lxo
2つのシーンでフレームレートに差が出てるのは、データの違いによる物です。
Human.lxoはポリゴン数が多いのでメッシュを表示してると遅い。Bolo_Walk.lxoは指にスケルトンが仕込まれてるので、スケルトン表示のとき遅い。ということだと思います。
リグが動いてる状態でメッシュやリグ、コントローラーを全て非表示にするとリグの速度がわかります。
Human.lxo に指を追加
CharacterBoxは指を追加すると114FPS。ACSはおよそ49FPSがリグ速度の上限だとわかります。
リグ機能が異なるのでリグその物の速度を比べることは難しいですが、CharacterBoxやACS3は必用に応じてリグを追加できるので、リグのパフォーマンスを制御しやすいかもしれません。
メッシュを非表示にしただけだと恐らくデフォーマの計算が走った状態ですが、メッシュを非表示にした場合と大きな違いはありませんでした。もしかしたらメッシュを非表示にするとデフォーマ計算を省くなど、最適化されてるのかもしれません。
またメッシュを参照するコンストレイントを使用していると、メッシュを非表示にしてもパフォーマンスが変わらない場合があります。
例えば下の画像はLocatorをポリゴンコンストレイントと、位置コンストレイントを使用したものです。ポリゴンコンストレイントを使用していると、メッシュを非表示にしてもフレームレートが遅いままです。Locatorを非表示にするとフレームレートが上がります。
リグとメッシュに依存関係がある場合は、フレームレートがメッシュの表示速度の影響を受けるようです。
ちなみに、CharacterBoxに自動制御を組み込んでカスタムした自作リグの場合、補助スケルトンを表示した状態だと14.5FPSでした。
このリグはアニメーション用途ではなくて、どこまで自動制御組み込めるのか色々テストしていた物なのです。IK計算後の角度を使用してスケルトンを自動制御してるのですが、IKのようにワールド座標で計算された角度に連動してスケルトンを制御しようとすると、徐々にパフォーマンスが低下するようです。1関節につき5～6アイテム動いてるので、数が多いというのもあります。
シーンに複数のリグがある場合の速度をテストしました。
modoはデフォーマなどマルチスレッドに対応してる機能がありますが、チャンネルモディファイヤは並列処理に対応していません。シーンに複数のリグがある場合、どのようになるのかテストしました。
やはりリグの並列処理に対応していないため、数に応じて速度が低下しました。
Human.lxoは指を追加して実際に使用するリグ構造に近い状態にしました。
|
メッシュとリグ
|
リグ
|
全非表示
|
|
| リグ1体 |
59 FPS
|
86 FPS
|
114 FPS
|
| リグ2体 |
31 FPS
|
46 FPS
|
65 FPS
|
| リグ3体 |
20 FPS
|
31 FPS
|
43 FPS
|
| リグ4体 |
15 FPS
|
23 FPS
|
32 FPS
|
| リグ5体 |
12 FPS
|
18 FPS
|
26 FPS
|
|
メッシュとリグ
|
リグ
|
全非表示
|
|
| リグ1体 |
35 FPS
|
45 FPS
|
49 FPS
|
| リグ2体 |
17 FPS
|
22 FPS
|
24 FPS
|
| リグ3体 |
11 FPS
|
14 FPS
|
15 FPS
|
| リグ4体 |
8 FPS
|
10 FPS
|
11 FPS
|
| リグ5体 |
6.8 FPS
|
9 FPS
|
9.6 FPS
|
チャンネルモディファイヤは並列処理に対応していないので、リグの数に応じてフレームレートが下がることがわかりました。
CharacterBoxはリグのみ表示した場合と、全て非表示にした場合のフレームレートに差があります。CharacterBoxはスケルトンにプロシージャルメッシュを使用してるせいなのか、リグのみ表示してる場合に描画コストが発生してるようです。
逆にACSはフレームレートに差がないため、ロケータのカスタムシェイプ表示はそれほど描画速度に影響がないことがわかります。
CharacterBoxはシーンに3体リグを配置しても30FPSを維持できそうですが、ACSはシーンに2体配置するとリアルタイムでのアニメーション再生が難しくなりそうです。ACS3ならもっと軽くなってるかも知れません。リグは好みによる部分が大きいので、自作リグなどを含めて速度は気にしたいところです。
リグをベイクした状態だと5体でも30FPS出ます。modoでも工夫次第ではアイドルアニメのダンスシーンを処理できるかもしれませんが、普通に別々のシーンでアニメーションを作成した後に、シーンを合成するのがスマートだと思います。
ビューポートのスタイルやオプションを変更してアニメーションの再生パフォーマンスをテストしました。フレームレートが高い方がパフォーマンスの変化がわかりやすいのでHuman.lxoを使用しています。
ビューポートプロパティの表示属性タブには「パフォーマンス」というパフォーマンスに影響する表示をOFFにするオプションがまとまってます。
データによりますが、これらのオプションをOFFにするとビューポートのパフォーマンスをよくすることができます。
ファー マテリアルのガイドをOFFにすることができます。
ディスプレースメントマップをOFFにすることができます。複数のテクスチャを一時的にOFFにしたい場合に有効なオプションです。
実はこの「ディスプレースメント」や、初期設定の「GLでのディスプレースメント有効」をOFFにしてもあまり速くなりません。ビューポートでディスプレースメントを表示しなくていい場合は。テクスチャーレイヤーの「GL 表示」をOFFにする方がパフォーマンスが上がります。
ポリゴンのスムージング計算を無効にしてフラットシェーディングにします。ポリゴン数の多いモデルで効果があります。
サブディビジョンを適用したメッシュには効果がありません。modoのサブディビジョンは細分割時に自動的にスムージングを適用するので、サブディビジョンを使用した段階でスムージング計算が走ります。
画像はサブディビジョンレベル 3でフリーズしたモデルです。
以前、自作のモデルでメッシュスムージングのオプションが凄く効果的だった記憶があるのですが、どんな条件だったか出てこないので、思い出したら追記します。
シェーダーツリーの計算を省略します。テクスチャの多い複雑なモデルで効果があります。
マテリアル数が少なく、テクスチャが使用されてないモデルでは効果が薄いです。
modoのシェーダーツリーはとても便利です。複数のマテリアルに同じテクスチャを一度に適用できたりマテリアルのオーバーライドが簡単で、階層構造で管理するマテリアルシステムの完成形というくらい素晴らしい機能なのですが、modoのパフォーマンスが悪い原因として上げられることが多いです。
今回調べてみたら大きな速度低下はありませんでしたが、いくつか気になる点をまとめてみました。
あたり前ですがテクスチャを使うと少しフレームレートが低下します。ディスプレースメントを使用すると特に速度が低下しますが、バンプもそれなりに速度低下します。
ディスプレースメントとバンプ以外は、どのレイヤーエフェクトを使用しても低下率はだいたい同じです。「ディゾルブ」のようにビューポートで効果が確認できないものや、「ポーリュームサンプル密度」のようにレンダリングでも効果のないエフェクトでも、一律フレームレートが低下します。
テクスチャを一度でもビューポートに表示するとそれ以降は若干パフォーマンスが低下し、シーンを読み直すと改善します。
ディスプレースメントとバンプを表示すると、それ以降ディスプレースメントやバンプ以外のテクスチャに切り替えてもフレームレートが落ちたままになります。
初期設定にはビューポートの「テクスチャ解像度」の設定があります。テクスチャ解像度を変更しても速度は低下しませんでした。テクスチャを多く使用してるシーンでは違いが出るかもしれません。
複数のテクスチャを適用しても速度は低下しませんでした。
シェーダーツリーでテクスチャを選択するとわずかに速度が低下します。ドラッグアンドドロップのような操作は更に速度低下します。ディゾルブなど一部のエフェクトは選択したテクスチャをビューポートに表示するので何か処理が走ってるのかも。
特に必要のない場合は、シェーダーツリーでは選択を解除した方が少しパフォーマンスがよくなるかもしれません。
今回テストした範囲では大きなパフォーマンス低下は確認できませんでした。テクスチャ表示やディスプレイスやバンプの速度が妥当なのかわかりませんが、表示する要素が増えると相応に処理が発生するのは理解できます。
シェーダーツリーは機能の特性上、少しの変更でもツリー全体を更新する必用があるらしく、特にマテリアルの数が多い場合にパフォーマンスを低下させることが多い言われています。
Vrayのようにビューポートを更新しないマテリアルはパフォーマンスがいいようなので、アニメーションで使用する場合は「GL 表示」をOFFにして必用なレイヤーだけビューポートに表示する使い方が適してそうです。
ビューポートの表示スタイルを変更して、速度に変化があるかテストしました。表示スタイルの違いがパフォーマンスに影響することはないようです。
アドバンスト表示は遅いですが、他の表示スタイルの速度は大きく変わりませんでした。メッシュがビュー全体を覆うようにズームした場合は、ワイヤーフレームの表示がわずかに速いようです。
modoはメッシュにワイヤーフレームがうっすらと表示されています。他にもビューポートで表示する様々な表示を切り替えたらパフォーマンスに影響するかテストしました。
昔使ってたソフトではワイヤーフレーム表示を使うと遅くなることがあったのですが、modoでは特に問題になることはないようです。
サブディビジョン2でフリーズしたメッシュ。
ここまではmodoの機能を使用したパフォーマンス改善をテストしました。テスト結果からよりアニメーションを速くするための工夫を紹介します。
メッシュを関節ごとに個別のアイテムに分割して、スケルトンにダイナミックペアレントする方法です。
サブディビジョンレベル 4でフリーズしたメッシュ(948,736ポリゴン)だとフレームレートが1.6FPSしかでません。同じポリゴン数でも関節ごと個別のアイテムに分割して、スケルトンにペアレントすることで高速にアニメーション再生することができます。
プロキシメッシュを使用する方法はPCスペックの低かった時代からある定番ですが効果が高いです。この方法の弱点は以下の通り。
逆にキャラクターアニメーションではなく、メカニカルな物ならパフォーマンスを気にすることなくアニメーション生成できそうです。
プロキシメッシュを簡単に作成する機能があれば便利なんですけどね。ACS3にはプロキシメッシュを作る機能が搭載されてるようです。
modo 15.1で追加された保留される評価の「代理メッシュ」機能を使用する方法です。この機能はメッシュを複製してサブディビジョンをOFFにするだけで、簡単に代理メッシュを設定できるのでお勧めです。
画像では速度差がわかるようにサブディビジョンレベル1でフリーズしたメッシュにサブディビジョンを適用したモデルを使用しました。
そのままアニメーションすると32FPSくらいですが、アイテムを複製してサブディビジョンをOFFにしたアイテムを「代理メッシュ」に指定すると65FPSくらいの速度になります。
代理メッシュがわかりやすいように色を変えてみました。タイムラインスクラブやアイテム編集中だけ軽いメッシュに置き換わります。切り替わるタイミングで若干ラグが発生しますすが、ユニークな機能で再生パフォーマンスを改善する効果が高いと思います。
逆に編集中の操作を軽くしたい場合は、15.1で追加されたメッシュオペレーターの「評価の保留」の効果が高いです。
デフォーマを適用したメッシュを使用するとパフォーマンスが落ちてしまうという根本的な問題は解決することはできませんが、サブディビジョンを使用しない描画の速い代理メッシュを使用することで快適にアニメーションを作成することができるようになます。
プロキシメッシュ並みの早さすることはできませんが、モーフやデフォーマの影響も確認する事ができるので便利です。
Human.lxoは1オブジェクト1メッシュのモデルです。メッシュを複数のアイテムに分けてパフォーマンスを確認しました。
サブディビジョンレベル3でフリーズしたメッシュで、マッスルやモーフデフォーマを削除した状態のモデルです。
デフォルトは10FPS。
メッシュを頭、胸、腕、腰、脚の5アイテムに分割した場合。正規化フォルダは1つで、12.3FPS。
メッシュを5アイテムに分割し、更に正規化フォルダをアイテムごとに5つに分けた場合、11.9FPS。
1アイテムに全てのメッシュをまとめるより、適度にアイテムを分けた方がわずかにパフォーマンスがいいようです。デフォーマが並列処理されるぶんだけ、速度が上がるのかもしれません。
アイテムごとに正規化フォルダをわけてインフルエンスを入れた場合は、わずかにパフォーマンスが落ちました。正規化処理が複数発生するからでしょうか。
アイテムを分けた方がパフォーマンスがいいのはmodoに限らず、どの3Dソフトで同じですね。
正規化フォルダには1頂点に影響するウェイト数を制限するソース制限機能があります。この機能を使用した場合のパフォーマンスをテストしました。
ソース制限OFF、11.4FPS。
ソース制限3、10.3FPS。
ソース制限1、10.2FPS。
ソース制限はゲームエンジンの仕様に合わせるための機能なので、計算が速くなるイメージでしたが、実際にはわずかにパフォーマンスが下がるようです。
画像では複数の正規化フォルダを使用してテストしていますが、1メッシュ1正規化フォルダの場合でもわずかに遅くなります。しきい値を大きく設定しても速度に大きな変化がないので、ソース制限の計算コストぶんだけパフォーマンスに影響があるのかもしれません。
modoでキャラクターアニメーションを作る場合は、プロキシメッシュか代理メッシュを使うのが最も効果があることがわかりました。
今回いろいろテストしたことで、これまで漠然と使ってたオプションが、どのようにパフォーマンスに影響しているのかわかりました。
modoのアニメーション機能はわりと使いやすくて高機能です。デフォーマを使用したメッシュのアニメーションパフォーマンスが低い問題は、ぜひ対処して欲しいですね。そういった意味では「代理メッシュ」はmodoの問題点をフォローするいい機能追加だったように思います。
本当は自作のモデルで代理メッシュをテストしたかったのですが、15.1でリレーションシップにバグが発生していてファイルを開くことができないので試せませんでした。バグが修正されたらテストしてみたいと思います。
もっと複雑なモデルだとパフォーマンスを下げる要因がより複雑になると思います。もしパフォーマンスの問題に遭遇したら、この記事で書いたことが何らかのヒントになったなら嬉しいです。
modoのメッシュオペレーターをアセンブリとして保存する方法について書いてみます。
modoはスケマティックで作成した処理をアセンブリとして保存して、他のシーンで簡単に使い回すことができる仕組みがあります。
プロシージャルモデリングに使用するメッシュオペレーターもアセンブリとして保存して使い回すことができます。しかし、メッシュオペレーターをアセンブリとして保存すると、メッシュオペレーターの順番が変わってしまう問題があります。
例えばメッシュをマージして、Polygon Bevel、Edge Bevel、Transform Deformerの順番でメッシュを編集するアセンブリを作ったとします。
上の画像のような状態で「アセンブリプリセットを保存」し、保存したアセンブリを読み込むと、メッシュオペレーターリストの順番が変わってしまいます。
また、「アセンブリプリセットを保存」する場合はメッシュの接続を切った状態で保存しないと、中身が空になることがあるので注意が必要です。
メッシュオペレーターの順番を維持した状態でアセンブリを保存するには、デフォームフォルダを作成して、アセンブリにデフォームフォルダを入れた状態でアセンブリ保存する必用があります。
デフォームフォルダを含んだアセンブリでは、メッシュオペレーターの順番が維持されているのが確認できます。
Modo15.1ではメッシュオペレータースタックノードが追加されたので、スタックノードを使用してメッシュオペレーターの順番を維持することができるようになりました。
あまりメッシュオペレーターのアセンブリを作ることがないのですが、先日この問題にははまりました。こういう初見殺しの問題は早く修正して欲しいですね。
3ds Max用のキャラクターリグ「MultiMax」がリリースされてます。価格は$25。
https://lopa.artstation.com/store/9bgA/multimax-rig
Multimaxは、調整可能な3dsMaxキャラクターリグで、基本的なスキニング以外のリギングスキルがなくても、すぐに設定できます。
キャラクターをインポートし、チューナーを適切な位置に移動させるだけで、リグがリアルタイムに調整されます。
以下のような業界標準の機能を備えた二足歩行のキャラクターリグを手に入れることができます。
あなたが手にするのは
将来的には、適切なドキュメントとチュートリアルを追加し、より多くの機能を追加し、ゲームエンジンへのエクスポート用に軽量化したバージョンを作る予定です。
Unityのエンジニアの方がハックウイーク 2021で作った、機械学習したリグから高速変形変形近似FDDAを使用したカスタムデフォーマのビデオを公開してます。
ビデオでは前腕にツイスト用ボーンが入ってないにもかかわらず、ツイスト変形してるのが興味深いですね。
UnityのBarracudaパッケージ（ML推論ライブラリ）を使用してFDDAベースのアルゴリズムをプロトタイピングし、訓練されたNNを変形のためにランタイムで評価しました。
このカスタムデフォーマは基本的に、リジッドスキニングパスに続いて、ボーンの回転に基づいて頂点を変位させるML補正パスを行います。
modo 15.0でRemap Weightのターゲットに「パーティクル サイズマップ」と「パーティクル ディゾルブマップ」が追加されました。パーティクル サイズマップを使ってReplicatorで複製したアイテムをアニメーションする方法について書いてみます。
スケマティックはこんな感じです。
Set Weightを使ってウェイトマップを作成し、Grow Weightのステップを使用してウェイトマップをアニメーションしています。
modo 15.0で追加されたSmooth Weightでウェイトを滑らかにした後、Remap Weightでウェイトをパーティクルサイズマップに変換してます。
Spikeを使用しているのはポリゴンの中心にアイテムを配置するためです。Replicatorのソースモードには「ポリゴンを使用」という設定がありポリゴンの中心にアイテムを複製することができるのですが、残念ながらパーティクルサイズマップの読み取りに対応していません。
このためSpikeを使用してポリゴンの中心に頂点を作成して、Remap WeightにSelect by Previous Operationを使ってSpikeで作った頂点にだけパーティクルサイズを設定しています。ちょっと回りくどいですね。
Surface Particle Generatorにはウェイトマップをパーティクルサイズマップとして使用する機能があります。ランダムにアイテムを複製したい場合は、Surface Particle Generatorを使用した方がノードが単純です。
modo 14から15にかけて頂点マップ系のノードが増えて便利になってます。この調子でマップ制御系のノードを充実して欲しいですね。
Mayaを使用した手のセットアップ（リギング）の記事が公開されています。
https://area.autodesk.jp/column/tutorial/maya-rigging-technique/02-hand/
「モデリングはリラックスポーズ」で「出荷時はまっすぐポーズ」
具体的なワークフローとしては
間違った認識で骨打ちをすると、とたんに汚い曲がり方になってしまいます。
手のセットアップをする際は色々な手法があるかと思いますが、ＡＢＣアニメーションは基本的にブレンドシェイプを使ったＰＳＤ（ポーズ・スペース・デフォーメーション）は使用せず、スケルトンとそれに付随する補助骨を使ったスキンクラスターのみで表現するようにしてあります。デフォーマを絞ってある理由は「移植のしやすさ」が最大の理由です。
指の各関節や肘、肩など、大きく曲がる関節の場合、そのまま２本の骨でスキニングをしてしまうと間が痩せてしまう事があります。それを防ぐため、中間の角度を取った「中間関節」を配置し、そこにウエイトを割り振ることで痩せにくくするテクニックがあります。
modo用のアイコン集が発売されました。400以上のアイコンが含まれているようです。価格は£4。
modoのアイテムアイコンは一部のビューポートで表示されなかったり、アイコンが設定されていなかったりします。こういうのは標準で対応して欲しいですね。
https://gumroad.com/l/modoitemicons
Modoの内蔵アイテム用の400以上のアイコンです。
アイコンには、プリセットブラウザのサムネイル、アイテムリストとスケマティックビューポートのアイコンが含まれています。
アイテムのカテゴリーには、アイテム、ロケータ、ライト、デフォーマ、フォールオフ、ダイナミクス、フォース、パーティクルモディファイア、プロシージャルアイテム、ボリューム、メッシュ操作、チャンネルモディファイア、アレイ、グラデーション、コマンドリージョンなどが含まれます。
15.0用に作られています。10.2までテストしてます。
modoのアイテム配置に便利なツールの紹介です。
3Dソフトを使用していると、シーンにアイテムを配置するという作業が多いです。そこでmodoの便利なアイテムの操作方法として、アクションセンター、スナップ、トランスフォーム配列ツールを紹介したいと思います。
アクションセンターはツールの基点を指定する機能です。アクションセンターはmodoの強力なモデリング機能の1つとして紹介したことがありますが、アイテムを配置する場合にも便利に使用することができます。
アクションセンター「ローカル」を使用すると、アイテムのローカルの角度ごとに移動することができます。
これは他の3Dソフトでもよく見る定番の動作です。
アクションセンター「自動」を使用すると、選択中のアイテムをまとめて回転することができます。
ツールプロパティの「位置のみ」をONにすると、アイテムの角度を維持した状態で位置座標を回転することができます。
アクションセンター「自動」を使用すると、選択中のアイテム+アイテムの座標をスケールすることができます。
ツールプロパティの「位置のみ」をONにすると、アイテムのスケールを維持した状態で位置座標をスケールすることができます。
モデリングで便利なスナップ機能はアイテム配置にも使えます。グリッド、頂点、エッジ中心、ポリゴン中心、バウンディングボックス、など様々な条件でスナップすることができます。
モデルツールタブの「複製」にはアイテム配置に使えるトランスフォームツールがあります。トランスフォームツールを使用するとアイテムの配置で便利に使えます。
アイテムをカーブ上に配置することができます。
アイテムをランダムに移動、回転、スケールすることができます。ジッターツールも同じようなことができます。
アイテムを等間隔に配置することができます。
アイテムを放射状に配置することができます。らせん状にオフセットすることもできます。
modoは他にも「ソフト移動」「シアー」「ツイスト」「ベンド」など変形ツールを使用してアイテムの位置を編集することができます。
今回紹介したトランスフォームツールや変形ツールを使用したアイテム操作は、静止画用途だけでなくアニメーション作成にも使用することができるので知ってると便利だと思います。
Houdiniで作成したリグだそうです。珍しい。
Houdiniで作成したリグテンプレート。ボディはオブジェクトベースのボーンを使用しており、フェイスはワイヤーデフォーマー+シェイプです。
modo用の人型リグ作成スクリプト「Auto Character Setup」の無料版が公開されました。ACSは現在バージョン3を開発中ですが、この無料版はACS1が基になってるようです。無料で使えるのはいいですね。
https://www.autocharactersetup.com/free
modoの機能を使用してキャラクターリグを作ってみたので紹介したいと思います。
modoにはコマンド範囲などリグ作成やアニメーションに便利な機能が色々搭載されていますが、あまりキャラクターリグ関連のデモを見かけないように思います。modoの機能をフル活用してキャラクターリグを作るとどうなるかチャレンジしてみました。
このビデオではmodoのキャラクターアニメーション機能紹介を簡単に紹介してます。
アクションは1つのシーンで複数のアニメーションを管理する機能です。今回はリグ紹介用のアニメーションを管理するのに使用しています。
アクションはFBXファイルにマルチテイクとして出力することができるため、Unityに複数のAnimationが作成された状態でインポートできるので便利です。
アクションはいわゆるアニメーションレイヤーのような機能ですが、まだ開発途上の機能のためmodo 14.2 ではアニメーションのブレンドはできません。アニメーションの管理に使用するのが実用的です。
Rig Clayはクレイアニメのようにモデルをダイレクトに操作する感覚で制御するリグです。コマンド範囲を使用して非表示状態の制御用ロケータを選択しています。
コマンド範囲はmodoのコマンドをメッシュをクリックして実行できる自由度の高いリグ機能です。複数のアイテムを選択するしたり、アイテムの表示を切り替えたり、ポップアップメニューを表示したり、スクリプトを実行するなど、modoの多くのコマンドを実行することができます。
Mayaや3ds Maxなどではキャラクター制御用のカーブアイテムが大量にビューポートに表示されているのを見かけることが多いと思います。現在のキャラクターリグでは主流ですが、コントローラが多いとモデルが見づらい、数が多いとアイテム選択しづらい、ビューポートのパフォーマンスが低下するなどの問題もあります。
このためPixarの「Presto」やドリームワークスなどインハウスのアニメーションソフトでは、コントローラを使用するのではなく、モデルを直接操作するようなリグが試されてました。最近だと「Rumba」も同じような機能が搭載されていますね。
コマンド範囲は901で追加されましたが、modo 14.2で機能拡張されて表示や使い勝手が良くなりました。今回はじめて本格的に使って見ましたが14.2ではマウスオーバー表示に問題があるのと選択中のアイテムがわかりにくいので、もう少し改善が必用に感じます。
ちなみに「Rig Clay」という名称はPixarのキャラクターTDだったRichardさんがmodo向けに考案したワードのようです。
ビューポートのアイテム表示やデフォーマの計算を切り替えるポップアップです。このポップアップはロケータにユーザーチャンネルを追加して、ロケータが選択された場合にチャンネルポップアップを表示するコマンド item.channelPopover を実行してます。
アイテムの表示はグループの「可視」チャンネルを使って切り替えています。modoには複数のアイテムを管理するためにアイテムリストとは別にグループビューポートがあります。
グループを使用するとアイテムの表示をまとめて切り替えたり、選択したり、ロックしたり、チャンネルにキーを作成したりと色々できて便利です。
アイテムごとにデフォーマをON/OFFする機能もつけました。これは不要な計算を省きたいときに使用すると便利です。デフォーマはNormalizing Folder の「有効」を制御することで、フォルダ内のインフルエンスをまとめてON/OFFすることができます。
アイテム選択を便利にするアイテムピッカーです。Webビューを使用してコマンドを実行しています。
WebビューはHTMLからコマンドを実行できる自由度の高いビューポートです。ビューポートで選択し難いアイテムを選択する場合に便利です。アイテムのトランスフォームにキーの追加/削除、ポーズのリセットなどアニメーションで便利なボタンを追加しています。
modoのリグ構築に使うスケマティックビューポートです。スケマティックはリグごとにワークスペースを分けることができるので処理を管理するのが楽です。またフェイシャルリグのスライダーのようなパーツはアセンブリとして使い回すことができて便利です。
modoのスケマティックはオブジェクト、プロシージャルモデリング、マテリアル、シェーダーノード、パーティクルなど多くの機能を全て同じように使うことができるので便利です。ノードやバックドロップに色を設定したり、コメントノードを使用したりグラフィカルに管理することができます。
今回作ったキャラクターリグの紹介です。元々素体用の簡素なモデルを作ってたのですが、modoのアニメーション機能をテストするうち楽しくなって過剰に自動制御のリグを追加してしまいました。
本職のリガーやTDさんが公開しているビデオを参考に、見よう見まねで作りましたがそれっぽく動かせてる気がします。
キャラクターリグのベースにはCharacterBoxを使用しています。CharacterBoxはモジュラーリグプラグインで、いくつかのリグを組み合わせてオリジナルのキャラクターリグを作ることができます。
表情はスライダーを使用して複数のモーフを制御してます。モーフはリニアに補完されるためモーフを単純にミックスするとメッシュがめり込むことがあります。スライダーを使用することでモーフの中間で変形を補正するモーフを加えて表情をブレンドしてます。
モーフで表情を制御する場合は他のソフトでは左右別々にモーフを作成するのが一般的だと思いますが、条件式ノードを使ってフォールオフを回転して左右のどちらか一方向のモーフの影響をマスクしてみました。
モーフマップを左右分けて管理する必要がないのでモーフの数が少なくてすみ、モーフの修正も楽になります。
表情を微調整するためのコントローラも仕込んでます。これはmodo標準のトランスフォーム デフォーマを使用しています。
赤色のロケータは頂点コンストレイントを使用してモーフに合わせて移動してます。本来は微調整用の緑色のロケータを赤色のロケータにペアレントしたかったのですが上手くいかなかったです。
眼球の動きに合わせてまぶたを動かす処理も入れてみたのですが、あまり効果が感じられなかったかも。
キャラの髪はCharacterBoxの尾リグを使ってます。キーは全部同じフレームに作成してますが、遅延の設定をリグごとに少しずらして動きにバリエーションを持たせてます。
スケルトンだけ表示したビデオ。
体はCharacterBoxをベースにしていますが、プリセットそのまま使うのではなくカスタムした構造にしました。例えば鎖骨、手の甲の骨は関節数が1つの指リグを追加して、IKで制御できるようにしています。
好みの問題ですが鎖骨や手の甲にアニメーションをつけるとき、移動と回転でツールを切り替えるのが面倒です。CharacterBox標準の鎖骨は使用せず、移動ツールで制御できる指リグに置き換えました。
腕や脚のツイストはCharacterBoxのセグメントを使用してます。メッシュの細かさによりますがセグメント数は3～5個くらいあると綺麗にツイストできる気がします。
関節はホース状につぶれないように変形を補助するボーンを4個追加して、角度に合わせて自動で動くように制御してます。筋肉の収縮や皮膚のスライドも補助ボーンを使用して制御しています。この補助ボーンは全てチャンネル リレーションシップを使って制御してます。
補助ボーンの設定についてはMayaのウェビナーが参考になると思います。
スケルトンの角度を取り出す方法は以前書いたワールド回転からローカル角度を計算する方法と同じで、ヒジやヒザのように1方向にしか回転しない関節はMatrix To Eulerの「回転順」を変更して欲しい軸の角度を取得しています。肩や股関節のように回転軸が多い関節はTwist Extractorを使用するのが便利だと思います。
角度とチャンネル リレーションシップ使ってスケルトンの位置、回転、スケールを制御しました。チャンネル リレーションシップを使うと自動制御はとても簡単に作成することができます。
自動制御は体の左右で同じ制御を使いたいので、ノードをインスタンスコピーして管理や修正が楽になるようにしています。下の画像では紫色のリレーションシップがインスタンスされたノードです。
自動制御にはCharacterBoxの単体のスケルトンを使用してます。modo標準のスケルトンを使用してもリグは作れるのですが、筋肉のようにスケールしたときmodo標準のスケルトンは変化がわかり難いのでCharacterBoxのスケルトンを使用してます。
耳、胸、二の腕、腹、太もも、ふくらはぎはCharacterBox のマッスルで揺らしてます。
呼吸っぽくお腹動かすリグも仕込みましたが、少し効果がわかり難かったですね。
作ったリグを使用して簡単にアニメーションつけてみました。スカートはSyflex。
3ds MaxやMayaには標準で人形リグが入っててポーズやアニメーションのコピーやミラーに対応してたりしますが、カスタムで追加したリグは自分で何とかする必要があります。運よく作ったリグで動くコピースクリプトが見つればいいのですが、スクリプト書けないとカスタムリグを作るのは面倒です。
その点CharacterBoxは1.2.0からカスタム追加したロケータやスケルトンに簡単に対称編集やポーズのコピーができるようになり、スクリプトを書かなくてもカスタムリグの構築が楽にできるようになりました。
この機能を使用するとフェイシャルで微調整用のロケータを対称編集したり、ミラーコピーがプラグイン任せできるようになります。
今回手の込んだキャラクターリグを作ってみようと思えたのは、セットアップするときに面倒くさいカスタムリグの対称編集をプラグイン任せにできるというのが大きな理由です。
補助ボーンの自動制御やコマンド範囲の設定はそれほど難しいことはないので単純に根気です。コマンド範囲はとても可能性を感じる機能なので、自動生成する機能を標準で追加して欲しいですね。
以上ザックリとした紹介と解説ですが、modoを使ったリギングがどんなものか参考になったなら嬉しいです。
ABCアニメーションスタジオのリグシステム「ARS」の紹介記事が公開されています。
国内のMayaのリグ関係を調べると「ローカルリグ」「ローカル空間リグ」「ローカルセットアップ」と言うような表現がよく出てきます。どんな物なのか定義が書かれてなかったりよくわからなかったのですが、何となくイメージしてた物で合ってたみたい。
旧来のMayaは、高速に動作するリグを作るために「ローカル計算」を多用することが多くありました。
例えば「腕から手まで」という範囲内にひねりやカーブリグ等複雑なギミックを入れ込んでいく際、ワールド計算（コンストレイン等）をしてしまうと他の部位（例えば背骨）が動いた際も、このギミックの計算が走ってしまいます。
https://area.autodesk.jp/column/tutorial/maya-rigging-technique/01-ars-overview/
