インカメラ VFX のベスト プラクティス

インカメラ VFX の撮影に使用される環境の構築については、さまざまな課題があります。以下は 2 つの主要な課題です。以下は 2 つの主要な課題です。

• LED ウォール上で本物に見えるアセットの構築

• リアルタイムで実行するための、パフォーマンスに対する環境の最適化

これらの課題を緩和するには、アート チームとステージ チームとの緊密なコラボレーションが欠かせません。ワークステーション環境において Unreal Engine で正しく実行され、十分なパフォーマンスを発揮するエフェクトであっても、多くの場合、LED ウォール上ではそれだけの効果は発揮しません。チーム間での適切なコミュニケーションを確立することで、このような違いから生じる多くの問題を回避することができます。

インカメラ VFX プロジェクトを進めていく上で、これらの検討事項に関する参考資料としてこのページを活用してください。このページはすべての問題や解決策を網羅するものではなく、厳密な規則を提示するものでもありません。パフォーマンスの最適化を目指す上では、ご自分のプロジェクトの要件と制限事項をよく検討してください。

プロジェクト設定

• 効率の良いワークフローを実現できるよう、プロジェクトが適切に設定されていることを確認します。プロジェクト設定に関する推奨例については、「インカメラ VFX のプロダクション テスト」を参照してください。その後、ご自分のプロジェクトの要件に合わせてカスタマイズしてください。

• VR プラグインと 複合現実 プラグインを無効にすることをお勧めします。これによって Unreal Engine を実行するのに必要なリソースが減ります。これらは、バーチャル スカウティング と Live Link XR 以外には、バーチャル プロダクションで使用が制限されます。

• コンテンツ ブラウザ 内で プロジェクト構造 が定義されていることを確認します。複数のレベルおよび環境を作成する場合は、アーティストが使用する構造を最初から定義しておくことを強く推奨します。

• ICVFX プロダクション テストで使用されている構造が、推奨例として以下に文書化されています。

  In-Camera VFX Production Test

パフォーマンス ターゲットとプロファイリング

Unreal Engine のリアルタイム アプリケーションについては、エディタ内のパフォーマンスが、シッピング環境でのものより劣る場合が多くありますが、ICVFX の目的においては、エディタ内のパフォーマンスはステージ上でのターゲット フレームレートよりも大幅に優れたものである必要があります。

ICVFX 環境でレンダリングされる複数のビュー、さらには同期を保証するためにレンダリング時に生じる追加ステップにより、nDisplay には追加のパフォーマンス コストがかかります。同様に、ハードウェアもステージ間と、コンテンツをビルドする個々のワークステーションで異なるため、コンテンツの制作時には、このような違いをパフォーマンス ターゲットと併せて検討する必要があります。

ICVFX プロダクション テスト では、アセットは Dual NVIDIA A6000s および 128GB DDR5 RAM を使用するステージ レンダリング ノードに向けて、Dual NVIDIA RTX 8000 と 128GB DDR5 RAM を装備したマシン上で作成しました。

十分なパフォーマンスを確保するために、Windows での解像度スケールが 100% に設定された 4K の全画面で表示することを想定し、アーティストのワークステーション上で 48～72 フレーム/秒 (FPS) のフレームレートをターゲットとして、これをベンチマークのガイドラインとして使用しました。しかし、オフステージのターゲット デバイスではさらなるテストが必要になりました。このデバイスでは、オンステージ デバイスで考えられる最も重いロードをシミュレートしたビューポートのコンフィギュレーションを使って、nDisplay でシーンを実行していました。さらに、プロダクションに近づくにつれ、これらのシーンは想定されるハードウェアを使ってオンステージで定期的にテストされていました。

このページに記載されている内容はインカメラ VFX のワークフローに特化したパフォーマンスとプロファイリングに焦点を当てていますが、プロジェクトのパフォーマンス向上のための追加資料については、テストおよび最適化 、特に Unreal Insights に関するドキュメントを参照してください。

ステージ向けにシーンを準備する際は、次の点を考慮してください。

• 2～3x のターゲット フレームレートを想定したアプローチによってアーティスト向けのおおまかなガイドラインを提供できますが、すべてのシーンのスケールは異なるため、あらゆる状況においてこれが十分に機能するとは考えないでください。パフォーマンス テストを定期的に実行し、結果を文書化することを強くお勧めします。パフォーマンスは全員の責任であり、早期からテストすることで、セット上で初めてパフォーマンスの低さに気付くようなことはなくなります。

• ICVFX ステージ レンダリング ノードと互換性のあるコンテンツ ワークステーション上での ターゲット FPS を常に目指して作業してください。

  • すべてのアーティスト ワークステーションと常に比較することは難しいかもしれませんが、少なくとも、プロファイリングを実行できるワークステーション 1 台へのアクセスを確保することが重要です。

  • スケーラビリティの設定を使って、ターゲット ハードウェアのパフォーマンスを密接にエミュレートすることは可能ですが、その精度は低くなるため、大まかなガイドラインの設定のみに使用してください。

• 最も重いタスクを処理するレンダリング ノードと同じコンフィギュレーションでシーンを実行することで、オンステージで使用されるものと同じ仕様のマシン上で パフォーマンスのプロファイリング を定期的に実施します。これは、オンステージで使用される最大解像度を使用する単一ノードに対して、インナー錐台およびアウター錐台を適切に設定することを意味します。

• 可能であれば、ステージ チームと協力して、ステージ自体に対するパフォーマンス テストを実施します。このテストは、プロダクションの最終段階に入る前に実施してください。また、ステージ チームがパフォーマンスを最適化してくれると想定すべきではありません。

• Windows のスケーリングが Engine のパフォーマンスに影響を及ぼすことがあります。

  

• Unreal Insights を使用して nDisplay トレースを生成してください。その方法の詳細については、この ライブ ストリーミング を参照してください。GPU プロファイリング と CPU プロファイリング も役立ちます。

アセットの作成と LOD

• LOD (詳細度):画面にレンダリングされるメッシュの大きさに応じて、ポリゴン数の異なるレベルを使用します。詳細度はスクリーン サイズに基づきます。

• 表現:

  • アセットがカメラに非常に近い場合は、ヒーロー表現を使用します。

  • アセットが画面から離れていて、テクスチャとポリゴンの細部が必要ない場合は、プロキシ表現を使用します。一つの方法は、複雑なシェーディングと高解像度のテクスチャを使用してヒーロー ジオメトリを構築し、次に DCC アプリかプロキシ メッシュ ツールを使ってより低解像度のジオメトリを作成し、簡易シェーダーを使ってテクスチャをベイクするやり方です。

  • 撮影中の異なる場面でアセットがカメラの近くと遠くの両方にある必要がある場合は、LOD を使って柔軟性を高めてください。

  • プロキシ メッシュは個別のまたはクラスタの背景アセット用にエディタで生成できます。詳細については、「プロキシ ジオメトリの概要」を参照してください。

  • 共通のマテリアルを使用する一連の同じローカル アクタは、[Merge Actors (アクタをマージ)] 機能を使ってマージできます。

    • 一連のローカル アクタでそれぞれ異なるメッシュとマテリアルが使用されている場合は、Merge Actors 機能を使って、これらのマテリアルを、ドロー コールを減らすためにさまざまなテクスチャをアトラス処理する共有マテリアル アセットにマージできます。アトラス処理では、より小さなサイズのテクスチャになって品質が低下することがあるため、これは中距離程度あるアセットを最適化するのに最も便利な方法です。品質の低下がそれほど気にならない程度であれば、カメラに近い位置にある際に、これらをその場の状況に応じて使用することは可能です。

    マージしたアクタにも LOD や、パフォーマンスを向上するその他の方法を適用できます。

• オブジェクトのカリングはパフォーマンスに悪影響を及ぼす可能性があります。大きなオブジェクトの場合、カリングはそう簡単ではなく、結果的にパフォーマンスに影響を及ぼすことがあります。これは静的なスタティック シーンの場合はさほど問題ではありませんが、LED ボリュームが環境内を移動する場合は、大きなオブジェクトのカリングについて検討する必要性が高まります。この動作のため、メッシュをマージする際はあまり多くのアクタをマージしないでください。大きなメッシュを作成すると、マージされたメッシュをカリングする能力に影響が及びます。

• 自動 LOD では、アセットの外観がよりソフトに、より不明瞭になる可能性があります。手動で LOD を作成するためのリソースを予算に組み込んでおくことをお勧めします。

手動で LOD を作成する際は、レベル 1 のみを作成します (もしくはレベル 2 まで)。それ以外のレベルは、詳細が気にならないほど画面上での表示が小さくなります。

• 可能であれば、アート ディレクターやプロダクション デザイナーなど、外観に関する責任者の承認を得た最適化バージョンを取得します。そうでないと、最適化によって認識可能なビジュアル上の違いが生じる可能性があり、その場合はプロジェクトの予算とスケジュールを再考しなければなりません。

• 最適化プロセスは最後に行うのではなく、作業中に定期的に行いましょう。こうすることでプロジェクトを常に最適化された状態で保つことができ、アート ディレクターの承認を取得して維持する上で役立ちます。また、追加のシステム リソースを解放し、ボリュメトリック フォグや動的ライティングなど、高品質または動的なエフェクトなどに活用できるようになります。

  • また、使用予定の高品質の機能と動的な機能は、すべて最初からオンにしておくことをお勧めします。こうすることで、パフォーマンス コストや残りの作業量、さらには Cvar を使って品質を調整する必要性などについて一貫して考慮することができます。

• クワッド オーバードローにより、パフォーマンス コストが大幅に増加する可能性があります。これを最小限にとどめるには、以下の課題と最適化を考慮してください。

  • 特に大規模な不透明のエリアなど、透過処理を過度に多用することは避けます。代わりに、パフォーマンス コストの低い、マスクされたマテリアルを使用することをお勧めします。

  高密度のメッシュを避けます。モデルはスクリーン サイズに合わせて作る必要があります。ソリッド メッシュをワイヤー フレーム モードで表示したり、ソリッド カラーに近づけたりすると、パフォーマンスが低下する可能性があります。

  • 法線マップは細部のみに使用します。法線マップをジオメトリには使用しないでください。

  • シーンのプロファイリングには、ビューポートの [Quad Overdraw (クワッド オーバードロー)] モードを使用します。緑色またはそれ以下を示す色でレンダリングされたメッシュは、クワッド オーバードローのコストを抑えるために回避すべきです。画面内のほとんどの要素が青系の色でレンダリングされるようにしましょう。

  • 画面にレンダリングされて表示されるメッシュの量を把握しておくことが重要です。経験上、ジオメトリをどのように使用すべきか考慮しないチームを多く見てきました。たとえば、ある山が LED ウォール上で 100px x 100px にしか映らない場合、その山は 200 万個の三角ポリゴンで構成されたものである必要はありません。

  • 同じ最適化の実践事項はテクスチャにも当てはまります。GPU では、8k のテクスチャがカメラの直接的なビューに入るまで、これをロードしないことがあります。

• アセットを再利用して、Engine がそれをインスタンス化できるようにします。パフォーマンスが低下するので、固有のメッシュの多用は避けてください。統計 ウィンドウを使って、シーン内にある固有のアセットやほとんど使用しないアセットの数を特定します。[HWInstance] 列に「1」と「2」が多く表示される場合は、これを解決する必要があります。これにはいくつかの例外があります。アクタをマージすることや、プロキシ メッシュを作成することで、固有のアクタが新たに作成されるためです。

• メッシュのマテリアル ID の数を可能な限り減らします。できるだけ、アセットあたり 1 つのマテリアルになるようにします。このために [Merge Actors] ツールを使用できます。それぞれのマテリアル ID によってドロー コールが追加されるため、パフォーマンス コストを下げるために、ドロー コールの数を最小限に抑える必要があります。インポート時にアセットが正しい数のマテリアル ID で設定されることが理想的です。

• マテリアル関数 を使って共通の機能をグループ化し、マテリアルを肥大化させることなく、維持可能な状態に保ちます。

• マテリアル パラメータ コレクション を利用して、マテリアルの設定を簡素化します。

• できるだけマスター マテリアルを使用して、変更を簡単に一括で加えられるようにします。ただし、マスター マテリアルに多くのスイッチを含めるとシェーダー順列が増加し、シェーダーのコンパイル時間が長くなることに注意してください。保全性とコンパイル時間とのバランスを考慮してください。セットの段階ではマスター マテリアルに対する間際の変更に注意しましょう。多くのマテリアルを再コンパイルしなければならない可能性があります。

• カメラに近いアセットにはより複雑なシェーディングを使用し、カメラから遠いアセットにはよりシンプルなシェーディングを使用します。さまざまな品質レベルでの複数のマスター マテリアルを避けるためにスタティック スイッチを使用し、LOD を使ってこれらを実装します。次に、遠い距離にある (画面上で小さくレンダリングされる) 際のマテリアルにおけるエフェクトの計算に多数の複雑なノードを使うのではなく、シェーダーの複雑度、つまり命令数を削減するために、出力結果をテクスチャにベイクすることをお勧めします。詳細については、マテリアルのテクスチャへのベイク に関するこちらのライブ ストリームを参照してください。

• 4k または 8k の高解像度アセットは、ビジュアルとパフォーマンスの両方の面で良い選択肢とは言えません。リアルタイム プロダクションにおいては、より解像度の高いアセットが常に良い選択肢とは限りません。ほとんどの場合、高解像度は必要なく、これがあることで他のシーン要素に使用できたメモリが消費されることになります。詳細については、LOD テクスチャ プロパティ に関するドキュメントと、画像シーケンスでのミップマッピング の使用方法を参照してください。

• ミップマッピングとストリーミングの理由から、テクスチャは両方の次元で 2 の累乗である必要がありますが、完璧な正方形である必要はありません。垂直解像度と水平解像度の両方がそれぞれ 2 の累乗であれば、長方形でもかまいません。たとえば、128x256 と 256x256 のテクスチャは意図したとおりに機能しますが、8080x8080 は機能しません。

• デカールを使用していなければ、[Project Settings (プロジェクト設定)] の [Deferred Decals (ディファード デカール)] を無効にします。

• ビデオ要素は使用せず、フリップブック を使用します。

  • ICVFX では、ウォールにレンダリングされているすべてのノードが同期されていることを確認してください。ビデオ要素をエンコードする方法が異なるため、各マシンでビデオの同じ「フレーム」をポイントするように、これらを適切に同期する方法はありません。

  • マテリアル パラメータでアニメートされたテクスチャ フリップブックを使用する方法、または同時に再生されているレベル シーケンスによって駆動される EXR シーケンスを使用する方法は、いずれもアニメートされたシーケンスを同期するための良い方法です。

ライティングおよびレンダリング

• 効率的なライティング:レイ トレーシングの使用、または動的ライトの多用は避けます。このような ライティング は高コストになります。ライトのベイクなど、パフォーマンス コストが低く、より効率の良いツールを代わりに使用してください。動的ライティングは優れたツールですが、慎重に使用する必要があります。

  • 動的ライティングが必要な場合は、パフォーマンスへの影響を緩和するために [Cast Shadows (シャドウをキャスト)] を無効にすることを検討してください。

  • ライト関数 と 矩形ライト に依存しないようにしてください。IES プロファイル や スポット ライト などのより低コストな技法と比べると、いずれも高コストなオプションです。

  • 事前計算されたライティング シナリオ を設定して、オンセット時に異なる設定をすばやく切り替えられるようにすること検討してください。

• nDisplay のコスト： 複雑なシーンを設定する際は、nDisplay を使用することで、シーン自体のベースライン コストを越えるパフォーマンス コストが追加でかかることに留意してください。これは、ワークステーションで Unreal Engine を使ってシーンをレンダリングした場合と、インカメラ VFX の撮影用に LED ウォール上にシーンをレンダリングした場合のパフォーマンスの違いの原因となりえます。

• レイ トレーシング は パス トレーシング ではありません。Unreal Engine でのリアルタイム レンダリングにおいて、レイ トレーシングの意味が曖昧になることがあります。レイ トレーシングはパフォーマンスの点でコストが高くなるため、ボリューム ライト マップと反射プローブを備えた、ベイクされたライティングを使用することで、より見栄えが良く、安定性の高い画質を実現できます。

  • GPU ライトマスを機能させるにはレイ トレーシングが必要ですが、レイ トレースされたシャドウやアンビエント オクルージョン、グローバル イルミネーション、反射などのデフォルトで有効な追加のレイ トレーシング機能は必要ありません。そのため、以下のコンソール コマンドを使用して、それらの機能をすべて無効にしておくことをお勧めします。

          r.RayTracing.ForceAllRayTracingEffects 0
    Copy full snippet

    r.RayTracing.ForceAllRayTracingEffects 0

    細については、メインの「GPU Lightmass グローバル イルミネーション」を参照してください。

  • 高性能の環境であれば他のレイ トレーシング エフェクトを使用することは可能ですが、慎重に行ってください。例として、インカメラ VFX プロダクション テスト では、レイ トレースされたシャドウと反射を使用しています。

  • プロジェクトでレイ トレーシングが必要な場合はすべてのマテリアルを確認し、RayTracingQualitySwitch を使用して、これらをレイ トレースされたシーンに向けて最適化することをお勧めします。また、サンプルやレイの距離、バウンスなど、レイ トレーシングのあらゆる設定を見直すこともお勧めします。詳細については、全般的な レイ トレーシング に関するドキュメントを参照してください。

• 通常、シネマティック エンジンのスケーラビリティ の品質設定は必要ありません。代わりに、シネマティックで同様の見た目になるように、すべての品質設定を下げることをお勧めします。こうすることで、シーンでのパフォーマンス コストを大幅に抑えることができます。

シネマティック エンジンのスケーラビリティではさまざまな設定の値をそれぞれ自動的に判断するため、より低く設定したい場合は、設定の一部を手動で行う必要があります。

• 新規プロジェクトの開始時には、[Project Settings (プロジェクト設定)] の [Rendering (レンダリング)] にあるすべての設定項目を確認し、プロジェクトに必要な設定をすべて有効または無効にしてください。こうすることですべてのシェーダーが再コンパイルされますが、派生データ キャッシュ を設定した後は、シェーダーの再コンパイルに関して多くの問題は生じなくなります。

• すばやく変更できるようにしたいという理由で、ベイクされたライティングに難色を示す方もいるので、ベイクされたライティングと動的ライティングの「両方」を適切に使用する方法の価値を強調することが大切です。

  ベイクされたライティングを使用する場合は、ライトマップ解像度を感知可能な度合いに保つことをお勧めします。解像度を 4096p に設定する必要はありません。

• ベイクされたライティングを使用しない場合は、[Project Settings] の [Allow Static Lighting (静的ライティングを許可)] を無効にしてください。

• ボリュメトリック クラウド とライティング エフェクトはコストが高くなります。これらを多用する際は注意が必要です。ボリュメトリック クラウドのベイクは、希望の外観が整った後に行うよう検討してください。

• ボリュメトリック フォグ もパフォーマンスの面で高コストになるので、代わりに通常のフォグを使用することや、シェーダーを工夫して活用することを検討してください。ボリュメトリック が必要な場合は、その品質を調整することをお勧めしませう。ボリュメトリック フォグを最適化するには、以下の CVars を使用します。

  CVar コマンド	説明
  r.VolumetricFog.GridPixelSize 8	「8」がデフォルト値です。この値を「16」などに上げるとパフォーマンスが向上しますが、アーティファクトが生じる場合があるため、この値を変更する際は注意してください。
  r.VolumetricFog.GridSizeZ 128	「128」がデフォルト値です。この値を「64」などに下げるとパフォーマンスが向上しますが、アーティファクトが生じる場合があるため、この値を変更する際は注意してください。

• ライトマップ (CPU と GPU):適切なライトマップを設定してください。詳細については、「ライトマップで UV をアンラップする」を参照してください。

  • 大きなメッシュを含むライトマップを使用する際は、ライトマップ密度が薄くなるため注意が必要です。

  • ライトマップの自動生成アルゴリズムによって複雑なメッシュを効率よく評価することは困難です。生成されるライトマップに、ベイクされたライティングの情報をまったく受け取らない、細かい UV トライアングルが含まれる可能性があります。このような場合は、手動で生成したライトマップを使用することを検討してください。

• 動的ライトのオーバーラップ：ライトの半径とフォールオフに注意してください。オーバーラップを減らすにはこれらの設定を調整し、小さなメッシュに対しては [Cast Shadows] を無効にすることを検討してください。オーバーラップは、[Light Complexity (ライトの複雑性)] 表示モードでプレビューできます。

• 動的シャドウ：プロジェクトで動的シャドウが必要な場合は、パフォーマンスとビジュアル品質とのバランスをうまく取る必要があります。ビジュアル品質への影響を最小限に抑えながら、パフォーマンスを向上する方法がいくつかあります。

  • プロキシ ジオメトリ シャドウ を使って複雑なメッシュ用のシャドウを簡素化します。

  • カスケード シャドウ マップ (CSM) を使用する場合は、動的シャドウ距離 と 動的カスケード シャドウ数 の設定を下げるとパフォーマンスが向上します。

  • 距離フィールド (DF) シャドウまたは 遠方シャドウ カスケード シャドウへの切り替えを検討してください。DF シャドウは静的であり、遠方カスケード シャドウは特定のアクタのみで使用されるため、いずれも動的シャドウよりパフォーマンスが高くなります。

  • いくつかの追加のコンソール コマンドの設定を調整して、パフォーマンスを向上することもできます。

    • r.ShadowQuality
    • r.Shadow.MaxResolution
    • r.Shadow.RadiusThreshold
    • r.Shadow.DistanceScale
    • r.Shadow.CSM.TransitionScale これらのコマンドの詳しい使用方法については、「拡張性のリファレンス」を参照してください。

ステージ上

• レベル内にステージの 3D 表現を設置し、それが空白で、その地面が平面であることを確認します。ステージ エリアは、草やフォリッジなどの CG アセットがまったくない状態にする必要があります。また、シーン内を移動するアセットや、ボリュームに入るパーティクル エミッタに注意してください。ステージ エリア周辺での正確なビルドが可能になるため、ステージを使用することは開発とレベル デザインの上で有用です。

  • 理論上、LED ウォールのボリュームには、撮影用のいかなる 3D アセットも含めるべきではありませんが、実際には、撮影時に LED ウォールのボリューム内に 3D アセットを含めることは可能です。ただしその場合は、実質的な床と天井をフレーム内に収めるべきではありません。これらの要素が異なる深度にあることがわかってしまうためです。撮影時にステージ上の 3D アセットが機能するか、慎重に検討してください。

• 撮影現場で Web Remote Control の機能を使って動的コントロールをビルドするか、iPad やタブレットなどのデバイスで制御可能なブループリントに動的コントロールをビルドしてください。

• 直射日光はステージ上では再現しにくいので、屋外の場合は日陰の場所にステージを設置することを検討してください。

• ステージ上のカメラ位置と距離を考慮してください。すべてのものをシネマティック品質でレンダリングする必要はありません。カメラ ビューに含まれるものだけで十分です。

• シーンが静的なセット エクステンションであるかどうか、または背景の動きやアニメーションのために動的なコンテンツを含める予定かどうかを検討してください。動的な背景では、高品質のものをリアルタイムでレンダリングするため、コストが高くなります。