「Unreal Indie Development Day 2019: UE4 でのパフォーマンス分析と最適化」の抜粋とメモ。アーカイブおよび公開されています。
UE4 でのパフォーマンス分析と最適化:
最適化関連の作業は早ければ早いほど良いです。
最適化では、まず GPU または CPU のパフォーマンスのボトルネックを判断します。
stat Unit コマンドは、各フレームのレンダリング時間を表示します。
パフォーマンスを評価するときは、エディターでパフォーマンス分析を実行しないようにしてください。デバッグは実際に実行中のプラットフォームで行うのが最善です。PC ゲームを開発している場合は、エディターでデバッグする必要がある場合は必ずスタンドアロン モードで実行する必要があります (具体的な注意事項については、上の図を参照してください)。
上記のスレッドは並行して実行されますが、前のスレッドの計算結果に依存します。
ゲーム スレッドはすべてのゲーム ロジック、データなどを計算します。これらの結果とデータは、描画する必要のないコンテンツを計算するために描画スレッドによって使用され、最後に GPU スレッドが実際に画面上の最後のピクセルを描画します。いわゆるボトルネックは、特定のスレッドが長時間遅延し、次のスレッドが待機することである可能性があります。
各スレッドの役割。
StartFPSChart および StopFPSChart コマンドは、統計ユニットの出力を取得し、CSV 形式でテキスト ファイルに記録できます。
stat startfile および stat stopfile コマンドを使用して CPU を分析することも役に立ちます。関連する分析ファイルが生成されます。
Unreal Insights ツールはプロファイラーに似ていますが、スタンドアロン プログラムです。
ゲーム ロジックに関連するすべての計算は CPU 上で実行されます。
通常、ゲーム スレッドのパフォーマンスの問題の原因は、Tick イベント (フレーム イベント) の複雑なロジックです。多くのアクタがゲーム シーンで Tick イベントを使用している場合、ゲームのパフォーマンスが大幅に低下する可能性があります。
stat game コマンドは、特定の状況におけるゲーム ロジックのフレームごとの時間を表示でき、dumpticks コマンドはティックしているアクタをリストできます。
複雑なロジックを計算するために Tick イベントを使用する必要がある場合は、タイマーを使用するか Tick 呼び出しの頻度を減らすことによって Tick サイクルを短縮するか、プレイヤーから遠すぎるアクターの Tick を無効にすることができます。
マテリアルを通して簡単なフェードインおよびフェードアウト効果を実行し、GPU 側に負荷をかけます。
ゲームプレイとはほとんど関係のないアニメーション ロジックは、マテリアルを使用して実装できます。
パフォーマンスのオーバーヘッドが比較的高い一部の関数 (たとえば、クラスのすべてのアクターを取得する) は、操作の開始時に呼び出して、後で使用できるように関連データを配列に保存できます。
Tick イベントのロジックが非常に複雑な場合は、C++ の使用を検討できます。UE4 には、ブループリントを C++ に変換できる関連関数があります。
UE4 は混合プログラミングを使用できるため、最も複雑な関数を C++ に変換してブループリントに公開できます。
アニメーション ブループリントではファスト パス機能を忘れずに使用してください。
一般的なエンジンのレンダリングの限界は 10 ～ 15,000 オブジェクトです。
上の図の円柱は別のオブジェクトであり、数字はDraw Callの数を表します。右側の円柱の 1 つは 2 つの異なるマテリアルを使用しているため、追加の Draw 呼び出しが必要です。
Draw Call の問題はパフォーマンスに大きな影響を及ぼします。関連するコマンド ラインに加えて、RenderDoc などのオープン ソース ツールも Draw 呼び出しの分析に役立ちます。
ポリゴンがパフォーマンスに与える影響と比較して、Draw 呼び出しはパフォーマンスにはるかに大きな影響を与えます。
Draw 呼び出しを減らす方法は、マージされた大きなモデルを使用して多数の小さなモデルを置き換えるなど、比較的一般的ですが、カリング計算への影響など、いくつかの副作用が生じます。
もちろん、LOD を使用すると、Draw 呼び出しの改善にも役立ちます。
レベルをモジュール的に構築すると便利ですが、描画コールも増加します。いつでもモデルのマージに注意してください。
インスタンス化されたレンダリングでは、描画コールも減らすことができます。たとえば、植生システムは自動的にインスタンス化され、レンダリングされます。他のタイプのモデルには手動設定が必要です。
HLOD 機能の原理は Merge Actor の原理と似ていますが、HLOD は自動的にマージされ、非破壊であるという点が異なります。たとえば、HLOD はオブジェクトのグループをベイク処理した後に生成されます。LOD と同様に距離を置くとベイク処理された HLOD に切り替わりますが、各オブジェクトは編集中に個別に調整できます (もちろん、HLOD は後で再ベイクする必要があります)。
GPU スレッドは最終的に画面上にピクセルを描画します。この段階でパフォーマンスの問題を見つける最も簡単な方法は、さまざまなコマンドを使用してさまざまな機能をオフにすることです。
ProfileGPU はエディターで呼び出すことができるだけでなく、開発バージョンで関連ファイルを生成することもできます。
マテリアルごとの描画呼び出しの数を表示する関連コマンドもあります。
オーバーシェーディングを解決する主な方法は LOD を使用することです。
関連するモードを使用してエディターでオーバードローを表示します。
Shader Complexity モードも非常に重要です。
シェーダーの複雑さを軽減するためのいくつかのテクニック、フィーチャー レベル スイッチを使用してシェーダー コードを異なるプラットフォームに切り替える。
いくつかの複雑な演算を VS に移動して計算することに注意してください。
パーティクル システムは、画像を自動的にトリミングしてアルファ チャネルに近づけ、オーバードローを減らすことができるパーティクル カットアウト機能を使用する必要があります。ただし、植生の場合は、モデルを自分で手動でトリミングする必要があります (高品質の植生の作成を参照) 。
照明の複雑さも最適化の重要な部分です。
最後に、照明に関する最適化の提案をいくつか紹介します。