Render Thread のプロファイリングと最適化

概要

レンダリング スレッドにおいては、2 つのことが高負荷となります。それは、ビジビリティを決定する場合と、描画コールを GPU へサブミットする場合です。この 2 つは、可視的な部分 / 要素の数に依存します。そして、このこと自体は、可視的なメッシュの数とそれらメッシュそれぞれが有するセクションの数によって決まります。

レンダリング スレッドのコストについて覚えておかなければならないことは、分割スクリーンでは負荷が倍になるということです! レンダリング スレッドをプロファイリングする場合は常に分割スクリーンのパフォーマンスを調べる必要があります。

レンダリング スレッドのプロファイリング

RenderThread タイムが高い場合には、遅れの原因を見つけ出す必要があります。不正なフラグがセットされている単一オブジェクトが原因となっていることもあります。（例: レベル全体に渡って膨大なシャドウをキャストしている場合。）

実際にプロファイリングを行う場合、以下のことが参考になります。

• Trace Render では単一フレームのトレースを行います。（特にパフォーマンスが劣る領域に行ける場合にはこれが有効です）。
• サンプル プロファイリング：スパイクではなく、ごく普通のパフォーマンスのみの場合に、非常に有効です。

STAT SCENERENDERING

STAT SCENERENDERING コマンドは、一般的なレンダリング統計値を示すためのものです。レンダリング プロセスにおいてパフォーマンスが遅い一般的な部分を発見するには、ここから始めるのがよいでしょう。

STAT INITVIEWS

STAT INITVIEWS コマンドは、ビジビリティ カリングの期間とその効果の程度に関する情報を表示するためのものです。可視的部分の数は、レンダリング スレッドのパフォーマンスで最も重要な統計値です。これは、 STAT INITVIEWS 下の Visible Static Mesh Elements (可視的な静的メッシュ要素) によって決定されますが、 Visible Dynamic Primitives (可視的な動的プリミティブ) も要因となります。

STAT SCENEUPDATE

STAT SCENEUPDATE コマンドは、ワールドの更新に関する情報を表示するためのものです。この情報には、シーンにおいて光源を追加、更新、削除するのに必要な時間、ならびに、プリミティブを追加、削除にするのに必要な時間が含まれます。

サンプル ワークフロー

1. Stat unit を実行します。
   • render thread が 50 ms かかることを示しています。
2. 次に、 stat scenerendering を実行します。
   • RenderViewFamily において 25 ms あることを示しています。
   • レンダリングコマンドが取る 25 ms が残されています。
3. 最後に、 stat sceneupdate を実行します。
   • AddLight Rt において 25 ms あることが分かります。
   • 1 フレームにつき 10 回呼び出されていることが見て取れます。
4. 次に、ブレークポイントを使用して AddLight を呼び出しているものを調べなければなりません。また、特定のライト (複数あり) を追加することがなぜこれほど遅くなるのかを理解します。大抵の場合は、実際に必要となること以上のことを行わせるようにして、特定のライトを追加しています。(例: ライトの付属 / 再付属)

レンダリング スレッドの最適化

レンダリング スレッドのパフォーマンスを改善するためにデザイナーとアーティストによって使用される、関連する最適化のテクニックがいくつかあります。レンダリング スレッドのパフォーマンスを最適化する場合、静的メッシュおよび骨格メッシュ、SpeedTree 、テレインのコンポーネント数を最小限に抑えることが重要です。各メッシュのエレメント数を最小化することも極めて重要です。これは通常、メッシュ上で使用される一意なマテリアルの数を制限するということになります。

レベルのレイアウト

レンダリング スレッドが関する限り、レベルの設計において最も大きなファクターとなるものは、ビジビリティ、および、そのビジビリティが影響を及ぼす可視的な要素の数です。オクルージョンを効率的に使用するように設計されたレベルは、視覚化される要素の数を抑える可能性が常に高くなります。単一プレイヤーのゲームプレイについては、マップを通してジグザグフローを実装することによって、「Unreal Engine 3」のオクルージョン機能が完全にその能力を発揮できるようになります。

「Unreal Engine 3」で使用可能なカリングの方法については、 ビジビリティ カリング のページを参照してください。

コンテンツの構成

レベルのレイアウトに加えて、使用されるメッシュがどのように構成されているかという問題も重要です。この分野においてはトレードオフが必要となります。極端な例をあげるならば、再使用可能な小さなメッシュを多数使用して、レンダリング スレッドを損なうことがあり得ます。それと反対の例としては、大型のメッシュをより少なく使用し、メッシュが再使用できなくなることがあり得ます。この両極端の間のどこでバランスを取るかという問題は、出荷された「Gears of War」、「Unreal Tournament 3」、「Gears of War 2」のレベルを観察して、どの部分が機能しているかを調べてみることによってヒントが得られます。ただし、最善の POC は、ターゲット プラットフォームで作成およびプロファイリングしようとしているものの見本となるテスト用レベルを実際にセットアップしてみることです。

広いエリアを見通せるビスタ (眺望) は、部分の数を注意深くコントロールしなければ、大きな問題になる場合があります。「Gears of War 2」の SP_Assault が効率的なビスタの非常によい例です。多くの木が単一のメッシュに統合されています (選択されている部分で分かります)。これによって部分の数を小さく保つことができるのです。このテクニックが有効に働くのは、プレイヤーがビスタの遠いところまで進んで行かない場合だけです。プレイヤーが遠くまで行く場合は、より積極的な LOD システムを使用する必要があります。

忠実度を低くする

スプリットスクリーンでは、ワールドについて 2 個のビューがあるため、レンダースレッドは多くのことを 2 度おこないます。ゲームは通常、シングルプレーヤーにおいて最大限のスピードで作動しています。したがって、作業量を 2 倍にしたら、他の何かを減らさなくてはなりません。ゲームにマイナスとなる忠実度を下げるための領域を見つけることがポイントです。

ゲームプレイの コードは、オブジェクトをスポーンし、エフェクトを生成する役目を担っています。そのため、多くの場合において、特別なコードを書くことが必要となるはずです。エンジン内のシステムの中には、設定のできるものもあります。しかし、大部分は領域を識別し、無効にしたり、量を減らしたりするだけのものです。

忠実度を下げることができる重要な領域は、以下の通りです。

• デカール ： 同時に動作する最大数を減らします。
• オブジェクトが生きている期間 (Duration Objects Live): エフェクトタイプのオブジェクトが有するライフタイムを減らします。(例、Gibs)
• 骨格メッシュにアタッチするデカール数を減らします。
• AI キャラクターについては、あまりビジュアルなものをしないことです (例、大群を扱っている)。弾丸のインパクトごとに破裂デカールスプレーやエフェクトを持つ必要はありません。

分割スクリーンの詳細モード

最後の努力としては、詳細モード機能を使用して、分割スクリーンで描画されないメッシュを選択することが有効となります。「Gears of War 2」では、あらゆるマルチプレイヤーマップ上でパスが実行され、高詳細としてビジュアル専用詳細のメッシュをマークしました。

高詳細パスが完了すると、分割スクリーンのための詳細モード設定項目が次のように設定されます。

[SystemSettingsSplitScreen2]
DetailMode=1

この設定項目によって次のどちらかの結果となります。すなわち、分割スクリーン内で、高詳細モードに設定されたメッシュが描画されないか、あるいは、レンダリングのオーバーヘッドをまったく持たなくなるかということになります。