Pixarの新作「マイ・エレメント」のカーブを使用したキャラクターリギングのデモ映像が公開されています。カーブを使用したリグは去年論文を公開していましたが、実際に制作で使用されてるグラフィカルなコントローラーを見ることができます。
Rigging
modoでプロシージャルな鎖を作る方法
modoでプロシージャルな鎖(リンクチェーン)を作る方法について書いてみます。鎖はアクセサリーや駐車場スタンドなど身近でよく使われているので、CGで作る機会の多い定番の題材です。
modoには鎖を表現する方法がいくつかあります。どのような作り方があるのかいくつか作り方を紹介してみたいと思います。基本的にはReplicatorを使用して、鎖の輪をカーブに沿って配置します。
輪のペアをカーブに沿って配置する方法
輪2つを1アイテムにした物を、Replicatorを使用してカーブに配置する方法です。どの3Dソフトでも実現できる一番標準的な鎖の作り方です。
スケマティックはこんな感じです。
カーブをCurve Particle Generatorに繋いで、Replicatorで輪を複製する単純な作り方です。
この方法のメリットは作るのが簡単なことです。
デメリットは輪が2つで1アイテムなので、カーブが輪の長さよりも鋭角に曲がった場合に、輪の繋がりが破綻しやすいです。
Foundryフォーラムではdanperkさんが、輪をプロシージャルにしてアセンブリにまとめたファイルを公開しています。自分用に鎖アセンブリの作成を作る場合に参考になると思います。
1つの輪をカーブに沿って配置する方法 (Particle Step Modifier篇)
1つの輪をReplicatorを使用してカーブに配置する方法です。Particle Step Modifierを使用して輪を1つおきに90度回転します。
スケマティックはこんな感じです。
輪を回転する処理はParticle Step Modifierの「回転 Z」を使用します。
カーブの長さに応じて自動的に「回転 Z」を設定したいので、Curve Particle Generatorの頂点数をArray Countを使用して数えて、輪が90度回転するように掛けた値を「回転 Z」に入力します。
この方法のメリットは輪が1つなので、カーブが鋭角に曲がっても破綻しにくいことです。
デメリットはParticle Step Modifierの計算誤差が蓄積する影響なのか、カーブの始点から終点にかけて微妙に輪がねじれてしまいます。
1つの輪をカーブに沿って配置する方法 (Array篇)
1つの輪をReplicatorを使用してカーブに配置する方法です。Array Operatorを使用して輪をを1つおきに90度回転します。
スケマティックはこんな感じです。
輪を回転する処理にArrayノードを使用します。Curves to ArrayはCurve Particle Generatorのように距離を使用してカーブを細分割できないので、Path Constraintでカーブの長さを輪の長さで割って「ステップ」を自動的に計算するようにします。
Array Operatorは配列を編集して出力するためのノードです。「インデックス」を剰余ノードで2で割り、1つおきに配列を選択し90を掛けて、Matrix From Eulerの「入力Z」に接続します。Matrix Composeに「ワールド回転」と「エレメント(出力)」を接続してマトリクスを構築し「エレメント(入力)」に戻します。これで配列を1つおきに90回転したことになります。
Array Operatorの「出力」をParticle Generatorの「ユーザー配列」に接続して、Replicatorで使用できる頂点情報にします。最後のParticle Modifierはチェーン全体のひねり用で、なくても問題ありませんが、あると少し調整の幅が広がりそうです。
この方法のメリットは輪が1つなので、カーブが鋭角に曲がっても破綻しにくく、Particle Step Modifierを使用したときのようにねじれも発生しません。
デメリットはArrayを使う必要があるので構築するのが大変です。
このArrayの使い方は、Foundryフォーラムではkhellstrさんが公開していたファイルを参考にしています。
Arrayを使うとカーブを編集したときに、頂点数が変化して終端の輪の角度が縦横激しく変化してるのに気がつきます(画像右側)。
こういう場合は、Curves to Arrayの「ステップ」を偶数か奇数に固定すると安定ます。
鎖の間隔を計算する部分で、長さを剰余ノードで2で割り、条件式ノードで1より大きい場合は0を、1より小さい場合は1を出力することで、「ステップ」を奇数に固定しています。
2種類の輪をカーブに沿って配置する方法
縦横角度の違う2種類の輪を、Replicatorを使用してカーブに配置する方法です。パーティクルアイテムマップを使用して、角度の違う輪を1つおきに配置しています。
スケマティックはこんな感じです。
カーブをCurve Particle Generatorで細分割した後、Merge Meshesでカーブを結合します。Select by PatternとSet Weightで1頂点おきにウェイトを設定します。
設定したウェイトをRemap Weightでパーティクルアイテムマップに変換します。
パーティクルアイテムマップによって、Replicatorで複製されるアイテムが1つおきに切り替わります。
この方法のメリットは輪が1つずつのアイテムなので、カーブが鋭角に曲がっても破綻しにくいです。2つのアイテムを使っているので、デザインの異なる輪を配置したい場合に便利です。
デメリットはMerge Meshesを使用してるので、頂点数が多くなるとパフォーマンスが下がる可能性があります。
たまにはよくある題材と言うことで、鎖の作り方をいくつかご紹介しました。用途に応じて試してみてください。
カーブに輪を配置する関係で、輪が1つの場合でもカーブが鋭角に曲がった場合、どうしても輪がずれる場合があります。輪が完全にずれないようにしたい場合は、鋭角な部分にだけベベルを適用するような処理を追加するとうまく行くかもしれません。
参考
カーブを再編集できなくてもOKという人向けには、昔ながらのカーブ複製ツールがあります。
昔からあるCurve Particle Generatorのみを使用する方法。
Dynamic Curveで鎖を物理計算。
Compact Biped Selector for 3ds Max
3ds Max用のCompact Biped Selector スクリプトが公開されています。
https://www.scriptspot.com/3ds-max/scripts/compact-biped-selector
Jim Jaggerのbiped select toolをフォークし、いくつかの機能を追加したものです。 Jim Jaggerのオリジナルのスクリプトは何年も更新されておらず、もう利用できません。 また、外部のmaxscriptファイルや、様々なフォルダに散らばるアイコンに依存していました。
この新しいバージョンは、完全に自己完結しており、すべてのアイコンと機能が1つのmaxscriptに組み込まれています。
使用方法
- LClick = ボディパーツを選択
- RClick = ボディパーツを選択 + 子供
- CTL + LClick = 選択範囲に追加
- ALT + LClick = 選択範囲から引く
上段のボタンは、二足歩行を隠す/表示する、ボックスモードやX線モードをオンにするなど、さまざまな表示オプションが可能です。
下段のボタンは、植え込み/スライド/フリーキーの設定、キーの削除など、一般的なキーフレーミングツールです。
対応バージョン:2009以降
Baguette for Maya リリース
Maya用の無料のノード リギング システム「Baguette」が公開されています。
https://github.com/nimsb/Baguette/releases
FramestoreのリギングスーパーバイザーであるNims Bun氏が、Maya用のノードリギングシステム「Baguette」を無償で公開しました。
Pixomondoのプロダクションで使用されていたこのツールセットは、アーティストがキャラクターや乗り物の柔軟で再利用可能なリグを作成でき、制作作業を効率化するための多くの機能を備えています。
2013年から開発され主要なVFX映画の制作で使用
公開されたばかりですがBaguetteは10年前から開発されていたそうです。昨年の3DVFのインタビューでBunは、2012年にミニオンズ映画の制作を終えた後、すぐに制作を開始し、8ヶ月間フルタイムでBaguetteを開発したと語っています。
その後、Bun氏がSony Pictures ImageworksやIndustrial Light & MagicなどのVFX施設で働くようになったため開発は一時中断し、2018年にPixomondoに入社し、リギングリードになったことで再開されました。
その後Pixomondoは『Goosebumps 2』を皮切りに、いくつかの映画の制作でこのツールセットを使用しました。
ノードを配線して超カスタマイズ可能なキャラクターリグを作成できる
Baguetteはリガーがノードを配線してジョイントを作成するだけで、リグを作成することができます。
頭部、脚部、腕部、四足歩行、手、足といったボディパーツのノードが用意されているほか、さまざまなタイプのジョイントチェーンが用意されており、これらを接続することでカスタムリグレイアウトを素早く作成できます。
ユーザーは、リグコントロールとして使用するプリセット形状のリストから選択するか、独自のカスタム形状を割り当て、Mayaのビューポートでコントロール形状を直接編集することができます。
リグの顔、二足歩行、四足歩行、乗り物まで
ビデオでは、Baguetteを使ってFACSベースのフェイシャルリグを作成していますが、ノードネットワークがスキャンベースのフェイシャルブレンドシェイプのセットを駆動していることがわかります。
このフレームワークには、二足歩行のキャラクターや四足歩行のキャラクター、さらには車や飛行機などの乗り物用のプリセットが用意されており、さまざまなリグを素早く作成することが可能です。
プロフェッショナルなVFX、アニメーション、ゲーム開発のパイプラインで使用するために設計されています。
すべてのノードが独立しているため、Baguetteをプロダクションで使用する利点として、個別に更新することができ、キャラクターの更新時にリグ全体を再構築する必要がないことが挙げられます。
各ノードは、BaguetteのUI内で直接Pythonスクリプトを使用してカスタマイズすることができます。
また、Mayaのプロジェクト間でノードをカット&ペーストしたり、リグをノードのセットとして他のアーティストと共有することも可能で、Bun氏によると、標準的なMayaシーンよりも「100倍小さい」ファイルになるそうです。
その他にも、Mayaのシェルフにあるボタンでトランスフォーム空間を切り替えたり、キャラクターをゼロポーズ、カスタムポーズ、個々のコントローラのデフォルトポーズにリセットすることができるなど、優れた機能を備えています。
Polly for MODO
複数のMeshOpsやChannel Modifiersが含まれるmodo用のユーティリティ集「Polly for MODO」がリリースされました。価格は$15です。
https://stevehill3d.gumroad.com/l/Polly
Polly for MODO
Pollyには新しいMeshOpsとChannel Modifiersが含まれており、MODOでモデルを操作する際の柔軟性がさらに向上します。
- Radial Align ダイレクトモデリングツールRadial Alignのプロシージャルバージョンです。
- Linear Align ダイレクトモデリングのLinear Alignツールのプロシージャルバージョンです。
- ポリゴンを作る(Make Polygons)は、ダイレクトモデリングの "p "コマンドの手続き版です。
- 球形、円柱、立方体を作成は、選択範囲を指定された形状に合わせます。
- Arrays to Polygonsは、配列データ(位置と面)から新しいジオメトリを作成します。
- Arrays to VMAP 配列データから頂点マップを作成します。
- ChannelRemapは、数値をある範囲から別の範囲に再スケーリングします(勾配付き)。
- ChannelBundleおよびChannelUnbundleは、チャンネルをパックおよびアンパックします。
- ChannelDistributeは複数の出力チャンネルに値をコピーします。
動作環境
- MODO バージョン15以上
- PC Windows(Windows 10で動作確認済み)、Linux(Ubuntu 18で動作確認済み)、Mac(Big Surで動作確認済み)
更新履歴
- バージョン1.1では、アクション・トランスフォームが導入され、ダイレクト・モデリングにおけるアクション・センター・ローカルと同様の機能を提供します。
- バージョン1.1では、リニアトランスフォームとラジアルトランスフォームがフォールオフで制御できるようになり、ラジアルトランスフォームにはポリゴン形状を作成するための新しいモード「N-Sided」を追加しました。
- バージョン1.2では、Make Spherical、Make Cylindrical、Make Cubic、Channel Distributeを追加しました。
- バージョン1.2.1では、Radial alignとMake* meshopsが強化されました。
- バージョン1.2.2では、Make Polygonsが改良しました。
- バージョン1.3.0では、中央揃えと移動のメッシュトップを追加しました。
- バージョン1.4.0では、EnforcerとTrailerメッシュトップを追加しました。
Rigging help me ! セミナームービー
2018年2月24日(土曜)に開催された「Rigging help me !」セミナームービーが誰でも視聴可能になったそうです。Maya界隈でよく使われるローカルセットアップについての映像です。
https://support.borndigital.co.jp/hc/ja/articles/360002870994
BACKBONE福本氏セッション
カナバングラフィックス宮田氏セッション
ダンデライオンアニメーションスタジオLLC西谷氏セッション
アバター 2 の新しいフェイシャル パイプライン
アバター 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
新しい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氏。「そこで、まずはリターゲティングで試してみようと考えました。そして、それを実行したのです。そして、うまくいくようになりました。
Pixarのプロファイル カーブによるキャラクターの表現
ピクサーのカーブを使用したキャラクター制御の新しいアプローチの論文が公開されています。
https://graphics.pixar.com/library/ProfileMover/
概要
コンピュータアニメーションは、キャラクタのサーフェスをさまざまなポーズで表現するリギングセットアップに大きく依存しています。長年にわたり、多くの変形戦略が提案されてきたが、キャラクタリグの構築は、限られた間接的なシェーピング制御で、ポイントウェイトと修正スカルプティングのオーサリングを繰り返す面倒なプロセスです。
本論文では、変形サーフェスをプロファイルする3Dカーブによって完全に制御された、ディテールを保持した変形を生成する、キャラクタ・アーティキュレーションのための新しいアプローチを紹介します。
本手法はスプラインベースのリギングシステムから始まり、アーティストがサーフェスプロファイルを記述する疎なカーブネットを描いてアーティキュレーションすることができる。リギングされた曲線のレイアウトを分析することで、メッシュの連結性とは無関係に、各曲線の辺に沿った変形を定量化し、関節制御を基礎となるサーフェス表現から分離します。
カーブネットのアーティキュレーションをキャラクター表面に伝播させるために、リギングされたカーブネットに適合させながら表面の詳細を再構成する変形最適化を定式化します。このプロセスにおいて、メッシュ要素をより小さなポリゴン(場合によっては亀裂を含む)に切断することにより、サーフェスメッシュにカーブネットを結合するカットセルアルゴリズムを導入し、次に、曲線の不連続性を伴う調和的な補間を提供するカットを考慮した数値離散化を導出すします。一連のアニメーションクリップを用いて、本手法の表現力と柔軟性を実証します。
MODO | ACES in MODO
modoのOCIO カラーマネジメントを使用してmodoで ACES を使用する方法と、レンダリングを Photoshop に取り込む方法の簡単なチュートリアルです。
modo 14.1 でカラーマネジメントにACECが追加されましたが、古いバージョンのようです。
追記 2021年7月23日
Modo 15.1 からは、カスタム OCIO プロファイルをキットとして追加できるようになりました。
CLIP STUDIO PAINTの漫画パース特許
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は段階的にパフォーマンス改善しています。
- 10.2 デフォーマキャッシュ追加
- 11.0アイテム描画キャッシュ
- 11.2 末端のスケルトン変形速度の向上
- 12.2 バウンディングボックスしきい値追加
- 13.1 サーフェス計算コードの書き直し
- 15.1 デフォーマの計算や法線の計算を保留する機能追加
modo 15.1になってMaya、3dsMax、LightWaveなど、他の3Dソフトで見かけるアニメーションパフォーマンスを改善する機能が一通り搭載されたように思います。
ハイポリのサブディビジョンメッシュを滑らかにアニメーションできるような改善には至っていませんが、現時点でアニメーションを作成する場合に、どのような所に注意した方がよいのかまとめてみたいと思います。
アニメーション再生が遅い原因は?
modoのアニメーション再生が遅い原因でよく言われるのが「デフォーマの計算が遅い」です。
リグ単体では早いのに、スケルトンにバインドした場合や、デフォーマを追加した場合にパフォーマンスが遅くなるので「デフォーマの計算が遅い」と言われていました。
しかし、開発者の方の発言によるとmodoのデフォーマはマルチスレッドで計算しており、実際の原因はグラフィックボードに送信するためのデータ生成(メッシュの細分割、三角形のインデックスの生成、法線計算、位置の計算)がボトルネックになってるとのことです。
この計算はデフォーマを使用していると毎フレーム発生するので、デフォーマ計算が遅いと思われていました。
modo 13.1ではボトルネックを解消するためサーフェス計算が新しく書き直されましたが、サブディビジョンサーフェースやカーブなど、一部のポリゴンタイプはまだ作業中です。(この書き換えによってデフォーマキャッシュが使用できなくなったのが残念です)
GPUを強化すれば早くなる?
グラフィックボードに送信するためのデータ生成がボトルネックということは、強力なグラフィックボード(GPU)にすればアニメーションのパフォーマンスがよくなるのでしょうか?
残念ながら劇的に速くなくことはありません。昔からmodoのビューポートパフォーマンスは、GPUよりCPUの速度の方が重要だと言われています。Windows10のタスクマネージャーを使用するとGPUの使用率を見ることができますが、modoはGPU使用率が低いことがわかります。
もちろんGPUレンダラーのmPathや、NVIDIA OptiXデノイザなどGPUを使用する機能を使う場合はGPUの性能が重要になりますが、modoのアニメーション再生やビューポートパフォーマンスには大きな影響はありません。
ゲームエンジン的なアプローチのアドバンストビューポートを使用するとGPU使用率が上がりますが、デフォルト表示に比べてアドバンストは描画速度が遅いのでアニメーション作成に使用するのはお勧めしません。
恐らくボトルネックになるサーフェス計算がCPUでおこなわれているため、modoではGPUよりもCPUのクロック数が高い方がパフォーマンスへの影響が大きいのかなと思います。以上のことから、modoでアニメーションを速くするには以下の2つが重要になります。
- クロック数の高いCPUを使用する。またはCPU使用率(計算量)を下げる
- GPUに転送するデータ生成量を減らす
modoに限らず3DCG全般で同じ事が言えますね。
キャラクターアニメーションのパフォーマンスをよくする方法
前置きが長くなりましたが、modoでキャラクターアニメーションの再生パフォーマンスを速くした場合は以下の点に注意するといいです。
- サブディビジョンはOFFの状態でアニメーションを作成すると軽い
- サブディビジョンを使用する場合はSub-D、またはOpenSubdivを使用する
- 速いリグを使用する
- 複数のキャラクターが登場するシーンは、シーンを分けて作る
- メッシュに依存したリグは避ける
- 「メッシュスムージング」「シェーダーツリーを使用」をOFFにする
- ディスプレースメントやバンプを使用する場合は、レイヤーの「GL 表示」をOFFにする
- プロキシメッシュや代理メッシュを使用する
以降ではキャラクターアニメーションのパフォーマンステストについて書いてみます。
アニメーションのパフォーマンステスト
キャラクターアニメーションを速くする方法をまとめるにあたり、「ポリゴン数」「リグの速度」「ビューポートの表示」の設定を切り替えて、アニメーション再生のパフォーマンスをテストしました。
自分のPC環境でファイルをダウンロードして検証できるように、modoで代表的なリグであるCharacterBoxとACSのサンプルシーンを使用しました。
- CharacterBoxのサンプル「Human.lxo」
https://www.psoft.co.jp/jp/download/cbox/ - ACSフリー版のサンプル「Bolo_Walk.lxo」
https://lukpazera.gumroad.com/l/acsfree
テスト環境
modo 15.1v1
フレームレート
アニメーション再生のパフォーマンスはGLメーターで表示されるフレームレートを参考にします。
リアルタイムで再生 OFF
「リアルタイムで再生」は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が適していそうです。
Sub-D、PSub、OpenSubdiv
ゲームのようなリアルタイム向けモデル以外は、サブディビジョンサーフェースを使用する場合が多いのではないでしょうか。
modoには3種類のサブディビジョンが搭載されていますが、各サブディビジョンでのアニメーション速度をテストしました。
- Sub-D : modoオリジナルのサブディビジョン Tab
- Catmull-Clark(通称PSub) :ピクサーからライセンスしているサブディビジョン Sift + Tab
- OpenSubdiv : Catmull-Clarkのオープンソース版。GPU計算に対応ししている
サブディビジョンサーフェースはポリゴンを細分割して、曲線的なモデルを作成する機能です。Sub-DとCatmull-Clarkでは分割アルゴリズムが異なるので、サブディビジョンレベルによってポリゴンの増加量が違います。
Sub-D
サブディビジョンレベル 0 (ケージ ON)
79FPS。レベル 0よりレベル1の方がフレームレート出るので、レベル 0は最適化されていない等の問題がありそうです。
33FPS。レベル 0からレベル5までフレームレートに大きく変化がないので、このような単純なモデルの場合サブディビジョンよりACSのリグ計算がフレームレートのボトルネックになっていると思われます。
サブディビジョンレベル 1
98FPS。
33FPS。
サブディビジョンレベル 2
88FPS。
32FPS。
サブディビジョンレベル 3
74FPS。
31FPS。
サブディビジョンレベル 4
59FPS。
29FPS。
サブディビジョンレベル 5
49FPS。
28FPS。
Catmull-Clark
サブディビジョンレベル 0 (ケージ ON)
69FPS。
33FPS。
サブディビジョンレベル 1
74FPS。
32FPS。
サブディビジョンレベル 2
39FPS。
25FPS。
サブディビジョンレベル 3
18FPS。
18FPS。
サブディビジョンレベル 4
7.4FPS。
9.7FPS。
サブディビジョンレベル 5
2.3FPS。
3.7FPS。
OpenSubdiv 3.0
演算には「マルチスレッド」を使用しています。「CPU」より「マルチスレッド」の方がわずかにパフォーマンスがよかったのですが、1CPUしか使用しないようです。
本来はGPUが最もパフォーマンスがいいはずなのですが、PC環境のせいでGPUを設定するとmodoがクラッシュするため、GPUを使用してテストできませんでした。
サブディビジョンレベル 0 (ケージ ON)
80FPS。
35FPS。
サブディビジョンレベル 1
104FPS。
36FPS。
サブディビジョンレベル 2
83FPS。
34FPS。
サブディビジョンレベル 3
46FPS。
29FPS。
サブディビジョンレベル 4
17FPS。
18FPS。
サブディビジョンレベル 5
4.8FPS。
7FPS。
サブディビジョン OFF
サブディビジョン OFFの状態で、Catmull-Clarkを使用して細分割したモデルをアニメーションしました。
サブディビジョンレベル 0 相当
110FPS。
34FPS。
サブディビジョンレベル 1 相当
69FPS。
32FPS。
サブディビジョンレベル 2 相当
26FPS。
19FPS。
サブディビジョンレベル 3 相当
7.3FPS。
7.3FPS。
サブディビジョンレベル 4 相当
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倍
|
Human.lxoのフレームレート
サブディビなし
|
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
|
Bolo_Walk.lxoのフレームレート
サブディビなし
|
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のパフォーマンスがよい
今回テストしたモデルではOpenSubdivとSub-Dのパフォーマンスがよいようです。
modoにはOpenSubdivがオープンソースとして公開される前に、ピクサーから直接ライセンスしたCatmull-Clarkを独自に実装していました。このCatmull-ClarkはOpenSubdivよりトポロジー編集が速い物だとのことですが、やはりアニメーションの再生では、OpenSubdivの方が高速なようです。
Sub-Dも決して遅くないので、アニメーションではOpenSubdivかSub-Dを使用するのがよさそうです。ただしOpenSubdivは少し動作が不安定でクラッシュしやすいように感じました。
サブディビジョンレベル 0より、レベル1の方がフレームレートが高い
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
- メッシュとスケルトン表示 25FPS
- スケルトンだけ表示 420FPS
- 全て非表示 590FPS
Bolo_Walk.lxo
- メッシュとリグ表示 28FPS
- スケルトンだけ表示 250FPS
- 全て非表示 490FPS
2つのシーンでフレームレートに差が出てるのは、データの違いによる物です。
Human.lxoはポリゴン数が多いのでメッシュを表示してると遅い。Bolo_Walk.lxoは指にスケルトンが仕込まれてるので、スケルトン表示のとき遅い。ということだと思います。
リグの速度
リグが動いてる状態でメッシュやリグ、コントローラーを全て非表示にするとリグの速度がわかります。
- メッシュとリグ表示 23FPS
- リグだけ表示 160FPS
- 全て非表示 200FPS
Human.lxo に指を追加
- メッシュとリグ表示 22FPS
- リグだけ表示 86FPS
- 全て非表示 114FPS
- メッシュとリグ表示 19FPS
- リグだけ表示 44FPS
- 全て非表示 49FPS
CharacterBoxは指を追加すると114FPS。ACSはおよそ49FPSがリグ速度の上限だとわかります。
リグ機能が異なるのでリグその物の速度を比べることは難しいですが、CharacterBoxやACS3は必用に応じてリグを追加できるので、リグのパフォーマンスを制御しやすいかもしれません。
デフォーマの計算速度
メッシュを非表示にしただけだと恐らくデフォーマの計算が走った状態ですが、メッシュを非表示にした場合と大きな違いはありませんでした。もしかしたらメッシュを非表示にするとデフォーマ計算を省くなど、最適化されてるのかもしれません。
- デフォーマON 20FPS
- デフォーマOFF 150FPS
- リグだけ表示 160FPS(デフォーマONでメッシュ非表示にした場合とほぼ同じ)
- 全て非表示 200FPS
またメッシュを参照するコンストレイントを使用していると、メッシュを非表示にしてもパフォーマンスが変わらない場合があります。
例えば下の画像はLocatorをポリゴンコンストレイントと、位置コンストレイントを使用したものです。ポリゴンコンストレイントを使用していると、メッシュを非表示にしてもフレームレートが遅いままです。Locatorを非表示にするとフレームレートが上がります。
リグとメッシュに依存関係がある場合は、フレームレートがメッシュの表示速度の影響を受けるようです。
ちなみに、CharacterBoxに自動制御を組み込んでカスタムした自作リグの場合、補助スケルトンを表示した状態だと14.5FPSでした。
このリグはアニメーション用途ではなくて、どこまで自動制御組み込めるのか色々テストしていた物なのです。IK計算後の角度を使用してスケルトンを自動制御してるのですが、IKのようにワールド座標で計算された角度に連動してスケルトンを制御しようとすると、徐々にパフォーマンスが低下するようです。1関節につき5~6アイテム動いてるので、数が多いというのもあります。
複数リグの速度
シーンに複数のリグがある場合の速度をテストしました。
modoはデフォーマなどマルチスレッドに対応してる機能がありますが、チャンネルモディファイヤは並列処理に対応していません。シーンに複数のリグがある場合、どのようになるのかテストしました。
やはりリグの並列処理に対応していないため、数に応じて速度が低下しました。
Human.lxoは指を追加して実際に使用するリグ構造に近い状態にしました。
リグ1体
- メッシュとリグ表示 59FPS
- リグだけ表示 86FPS
- 全て非表示 114FPS
- メッシュとリグ表示 35FPS
- リグだけ表示 45FPS
- 全て非表示 49FPS
リグ2体
- メッシュとリグ表示 31FPS
- リグだけ表示 46FPS
- 全て非表示 65FPS
- メッシュとリグ表示 17FPS
- リグだけ表示 22FPS
- 全て非表示 24FPS
リグ3体
- メッシュとリグ表示 20FPS
- リグだけ表示 31FPS
- 全て非表示 43FPS
- メッシュとリグ表示 11FPS
- リグだけ表示 14FPS
- 全て非表示 15FPS
リグ4体
- メッシュとリグ表示 15FPS
- リグだけ表示 23FPS
- 全て非表示 32FPS
- メッシュとリグ表示 8FPS
- リグだけ表示 10FPS
- 全て非表示 11FPS
リグ5体
- メッシュとリグ表示 12FPS
- リグだけ表示 18FPS
- 全て非表示 26FPS
- メッシュとリグ表示 6.8FPS
- リグだけ表示 9FPS
- 全て非表示 9.6FPS
複数リグのテスト結果
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
|
Bolo_Walk.lxoのフレームレート
メッシュとリグ
|
リグ
|
全非表示
|
|
リグ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にすることができます。
- ファー ON 21FPS
- ファー OFF 86FPS
ディスプレースメント
ディスプレースメントマップをOFFにすることができます。複数のテクスチャを一時的にOFFにしたい場合に有効なオプションです。
- レイヤー OFF 86FPS
- ディスプレースメント ON 16FPS
- ディスプレースメント OFF 43FPS
実はこの「ディスプレースメント」や、初期設定の「GLでのディスプレースメント有効」をOFFにしてもあまり速くなりません。ビューポートでディスプレースメントを表示しなくていい場合は。テクスチャーレイヤーの「GL 表示」をOFFにする方がパフォーマンスが上がります。
メッシュスムージング
ポリゴンのスムージング計算を無効にしてフラットシェーディングにします。ポリゴン数の多いモデルで効果があります。
サブディビジョンを適用したメッシュには効果がありません。modoのサブディビジョンは細分割時に自動的にスムージングを適用するので、サブディビジョンを使用した段階でスムージング計算が走ります。
画像はサブディビジョンレベル 3でフリーズしたモデルです。
- メッシュスムージング ON 5.9FPS
- メッシュスムージング OFF 7FPS
以前、自作のモデルでメッシュスムージングのオプションが凄く効果的だった記憶があるのですが、どんな条件だったか出てこないので、思い出したら追記します。
シェーダーツリーを使用
シェーダーツリーの計算を省略します。テクスチャの多い複雑なモデルで効果があります。
マテリアル数が少なく、テクスチャが使用されてないモデルでは効果が薄いです。
- シェーダーツリーを使用 ON 85FPS
- シェーダーツリーを使用 OFF 86FPS
modoのシェーダーツリーはとても便利です。複数のマテリアルに同じテクスチャを一度に適用できたりマテリアルのオーバーライドが簡単で、階層構造で管理するマテリアルシステムの完成形というくらい素晴らしい機能なのですが、modoのパフォーマンスが悪い原因として上げられることが多いです。
今回調べてみたら大きな速度低下はありませんでしたが、いくつか気になる点をまとめてみました。
テクスチャを使うと速度が低下する
あたり前ですがテクスチャを使うと少しフレームレートが低下します。ディスプレースメントを使用すると特に速度が低下しますが、バンプもそれなりに速度低下します。
ディスプレースメントとバンプ以外は、どのレイヤーエフェクトを使用しても低下率はだいたい同じです。「ディゾルブ」のようにビューポートで効果が確認できないものや、「ポーリュームサンプル密度」のようにレンダリングでも効果のないエフェクトでも、一律フレームレートが低下します。
テクスチャを一度でもビューポートに表示するとそれ以降は若干パフォーマンスが低下し、シーンを読み直すと改善します。
ディスプレースメントとバンプを表示すると、それ以降ディスプレースメントやバンプ以外のテクスチャに切り替えてもフレームレートが落ちたままになります。
- レイヤーなし 85FPS
- 一度テクスチャを表示した後レイヤーをOFF 67 FPS
- ディフューズ 65FPS
- スペキュラ色 65FPS
- バンプ 40FPS
- ディゾルブ 41FPS (バンプを表示しない場合は65FPS)
- ボリュームサンプル密度 41FPS (バンプを表示しない場合は65FPS)
テクスチャ解像度を変更しても速度は一定
初期設定にはビューポートの「テクスチャ解像度」の設定があります。テクスチャ解像度を変更しても速度は低下しませんでした。テクスチャを多く使用してるシーンでは違いが出るかもしれません。
- テクスチャ解像度 64 66FPS
- テクスチャ解像度 2048 66FPS
- テクスチャ解像度 4096 66FPS
複数のテクスチャを使用しても速度は一定
複数のテクスチャを適用しても速度は低下しませんでした。
テクスチャを選択すると速度が低下する
シェーダーツリーでテクスチャを選択するとわずかに速度が低下します。ドラッグアンドドロップのような操作は更に速度低下します。ディゾルブなど一部のエフェクトは選択したテクスチャをビューポートに表示するので何か処理が走ってるのかも。
特に必要のない場合は、シェーダーツリーでは選択を解除した方が少しパフォーマンスがよくなるかもしれません。
- 非選択 85FPS
- 選択 77FPS
今回テストした範囲では大きなパフォーマンス低下は確認できませんでした。テクスチャ表示やディスプレイスやバンプの速度が妥当なのかわかりませんが、表示する要素が増えると相応に処理が発生するのは理解できます。
シェーダーツリーは機能の特性上、少しの変更でもツリー全体を更新する必用があるらしく、特にマテリアルの数が多い場合にパフォーマンスを低下させることが多い言われています。
Vrayのようにビューポートを更新しないマテリアルはパフォーマンスがいいようなので、アニメーションで使用する場合は「GL 表示」をOFFにして必用なレイヤーだけビューポートに表示する使い方が適してそうです。
表示スタイル
ビューポートの表示スタイルを変更して、速度に変化があるかテストしました。表示スタイルの違いがパフォーマンスに影響することはないようです。
アドバンスト表示は遅いですが、他の表示スタイルの速度は大きく変わりませんでした。メッシュがビュー全体を覆うようにズームした場合は、ワイヤーフレームの表示がわずかに速いようです。
ワイヤーフレームオーバーレイ
modoはメッシュにワイヤーフレームがうっすらと表示されています。他にもビューポートで表示する様々な表示を切り替えたらパフォーマンスに影響するかテストしました。
昔使ってたソフトではワイヤーフレーム表示を使うと遅くなることがあったのですが、modoでは特に問題になることはないようです。
サブディビジョン2でフリーズしたメッシュ。
アニメーションを速くする工夫
ここまではmodoの機能を使用したパフォーマンス改善をテストしました。テスト結果からよりアニメーションを速くするための工夫を紹介します。
プロキシメッシュ
メッシュを関節ごとに個別のアイテムに分割して、スケルトンにダイナミックペアレントする方法です。
サブディビジョンレベル 4でフリーズしたメッシュ(948,736ポリゴン)だとフレームレートが1.6FPSしかでません。同じポリゴン数でも関節ごと個別のアイテムに分割して、スケルトンにペアレントすることで高速にアニメーション再生することができます。
- メッシュ 1.6FPS
- リグのみ 120FPS
- プロキシメッシュ 100FPS
プロキシメッシュを使用する方法は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のメッシュオペレーターをアセンブリとして保存する方法について書いてみます。
modoはスケマティックで作成した処理をアセンブリとして保存して、他のシーンで簡単に使い回すことができる仕組みがあります。
プロシージャルモデリングに使用するメッシュオペレーターもアセンブリとして保存して使い回すことができます。しかし、メッシュオペレーターをアセンブリとして保存すると、メッシュオペレーターの順番が変わってしまう問題があります。
例えばメッシュをマージして、Polygon Bevel、Edge Bevel、Transform Deformerの順番でメッシュを編集するアセンブリを作ったとします。
上の画像のような状態で「アセンブリプリセットを保存」し、保存したアセンブリを読み込むと、メッシュオペレーターリストの順番が変わってしまいます。
また、「アセンブリプリセットを保存」する場合はメッシュの接続を切った状態で保存しないと、中身が空になることがあるので注意が必要です。
メッシュオペレーターの順番を維持した状態でアセンブリを保存するには、デフォームフォルダを作成して、アセンブリにデフォームフォルダを入れた状態でアセンブリ保存する必用があります。
デフォームフォルダを含んだアセンブリでは、メッシュオペレーターの順番が維持されているのが確認できます。
Modo15.1ではメッシュオペレータースタックノードが追加されたので、スタックノードを使用してメッシュオペレーターの順番を維持することができるようになりました。
あまりメッシュオペレーターのアセンブリを作ることがないのですが、先日この問題にははまりました。こういう初見殺しの問題は早く修正して欲しいですね。
参考
Multimax rig
3ds Max用のキャラクターリグ「MultiMax」がリリースされてます。価格は$25。
https://lopa.artstation.com/store/9bgA/multimax-rig
概要
Multimaxは、調整可能な3dsMaxキャラクターリグで、基本的なスキニング以外のリギングスキルがなくても、すぐに設定できます。
キャラクターをインポートし、チューナーを適切な位置に移動させるだけで、リグがリアルタイムに調整されます。
以下のような業界標準の機能を備えた二足歩行のキャラクターリグを手に入れることができます。
- IK/FKスイッチ
- IK/FKスナップ
- 弧状の手足
- ストレッチ/スカッシュ
- ボリュームの保存
- 余分な手足の長さ/曲げのコントロール
- 簡略化された指/足のコントロール
- ハイブリッドIK/FKスパインセットアップ
- ミラー/フリップ/リセット・ポーズ
あなたが手にするのは
- マルチマックスリグ
- デモキャラクター
- デモキャラクター用4kテクスチャ3セット
将来的には、適切なドキュメントとチュートリアルを追加し、より多くの機能を追加し、ゲームエンジンへのエクスポート用に軽量化したバージョンを作る予定です。
リリースノート
- ゲームエンジンでのエクスポート用に、軽量版を追加しました。
- 手足のボーン数を減らし、"bendy limbs "機能を追加しませんでした。
背骨と手足のストレッチ/スカッシュのためのボリューム保存はありません。
ML Custom Deformer in Unity
Unityのエンジニアの方がハックウイーク 2021で作った、機械学習したリグから高速変形変形近似FDDAを使用したカスタムデフォーマのビデオを公開してます。
ビデオでは前腕にツイスト用ボーンが入ってないにもかかわらず、ツイスト変形してるのが興味深いですね。
UnityのBarracudaパッケージ(ML推論ライブラリ)を使用してFDDAベースのアルゴリズムをプロトタイピングし、訓練されたNNを変形のためにランタイムで評価しました。
このカスタムデフォーマは基本的に、リジッドスキニングパスに続いて、ボーンの回転に基づいて頂点を変位させるML補正パスを行います。
FDDA Paper
modoでウェイトマップをパーティクルサイズマップにリマップ
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にかけて頂点マップ系のノードが増えて便利になってます。この調子でマップ制御系のノードを充実して欲しいですね。