modoのキャラクターアニメーションのパフォーマンスについて書いてみます。
はじめに
modoはキャラクターアニメーションのパフォーマンスが遅いという問題があります。この問題を改善するためmodoは段階的にパフォーマンス改善しています。
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のサンプルシーンを使用しました。
テスト環境
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
複数のテクスチャを使用しても速度は一定
複数のテクスチャを適用しても速度は低下しませんでした。
テクスチャを選択すると速度が低下する
シェーダーツリーでテクスチャを選択するとわずかに速度が低下します。ドラッグアンドドロップのような操作は更に速度低下します。ディゾルブなど一部のエフェクトは選択したテクスチャをビューポートに表示するので何か処理が走ってるのかも。
特に必要のない場合は、シェーダーツリーでは選択を解除した方が少しパフォーマンスがよくなるかもしれません。
今回テストした範囲では大きなパフォーマンス低下は確認できませんでした。テクスチャ表示やディスプレイスやバンプの速度が妥当なのかわかりませんが、表示する要素が増えると相応に処理が発生するのは理解できます。
シェーダーツリーは機能の特性上、少しの変更でもツリー全体を更新する必用があるらしく、特にマテリアルの数が多い場合にパフォーマンスを低下させることが多い言われています。
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でリレーションシップにバグが発生していてファイルを開くことができないので試せませんでした。バグが修正されたらテストしてみたいと思います。
もっと複雑なモデルだとパフォーマンスを下げる要因がより複雑になると思います。もしパフォーマンスの問題に遭遇したら、この記事で書いたことが何らかのヒントになったなら嬉しいです。
