Language:
Page Info
Skill Level:
Engine Version:

VR パフォーマンス テスティング

一般的に、VR フレームレートの維持は、推奨デバイスでも非常に難しいです。フレーム速度が落ちると、快適なユーザー体験が台無しになってしまうため、 フレームレートの一貫性は、通常のリアルタイム レンダリングよりも重要です。

これを踏まえて、平均より長くなる可能性のあるフレームを確実に吸収できるようにしておく必要があります。インプット / トラッキング レイテンシーが導入されるため、 複数のフレームレートのパイプライン処理することはできません。つまり、ゲーム スレッドは常にレンダリング スレッドの 1 フレームだけ先になり、GPU とレンダリング スレッドは同じフレームで同期します。リプロジェクションのオーバーヘッドのため、 GPU 時間は 11ms より若干短くなります。ゲームプレイ コード オーバーヘッド、ドロー コール オーバーヘッドによるレンダリング スレッド、トランスフォームもしくはシェーディング オーバーヘッドによるGPU が原因で、ゲーム スレッドのフレーム時間が長くなると、フレーム時間が不足します。この 3 つのバランスを よく考慮しなければなりません。

ベスト プラクティス ガイド のコンソール変数設定に従えば、レンダリング スレッドは適度なパフォーマンスになります。そこから、 コンテンツとゲームプレイを最適化して、フレームレートを維持することが重要です。コンテンツは、できるだけ簡単になるようにします。

一般的には、以下の方法でコンテンツを簡略にします。

  • 動的ライトとシャドウを避けること。

  • 透過性を使い過ぎないこと。

  • 表示できるバッチでインスタンス化すること。インスタンス化したグループのエレメントが表示されれば、グループ全体が描画されます。

  • すべてに LOD を作成すること。

  • マテリアルの複雑度とオブジェクトあたりのマテリアル数を低くしておくこと。

  • うまくできそうなものはすべてベイクしてしまうこと。

  • プレイヤーを取り囲んでしまう大きなジオメトリは避けること。

  • 可能な限り、事前計算されたビジビリティを使用すること。

スライド資料 Bullet Train および Showdown では、 エピックが制作した実際よりも複雑に見える VR コンテンツの例を紹介しています。さらに、スクリーン スペースで使えるコツのほとんどは、ステレオではうまくはいきません。通常は、フラット、あるいは単に間違っているように見えます。

プロジェクト使用中はずっとプロファイルするようにして、必ずフレームレートが維持されるようにしてください。減らす部分を探していくよりも、先端に到達するまで徐々に複雑度を追加していく方が、 シッピングの数日前のターゲット パフォーマンスに間に合わせるための管理が簡単です。

ドローコールの削減にはコツが 2 つあります。できるだけ多くのマテリアルを組み合わせるようにし、インスタンス化されたスタティックメッシュ コンポーネントを多数使用するようにしてください。
インスタンス化する場合、一部でも表示されれば、その対象の全体が描画されるということを覚えておいてください。これによりインスタンス化の利点がほとんど生かせなくなる場合もあります。 バッチ処理でほどんどのオブジェクトが同じ点から表示あるいは非表示になる場合は、バッチでインスタンス化するようにしてください。

ボリュームをカリングして、外側にはみ出ている見えない空間を完全にカリング処理する方法も検討の価値があります。オクルージョンは、描画対象の選択に関して若干自由なので、 ボリュームをカリングすると、選択方法を少し保守的にすることができます。さらに、同じエフェクトを出すために、アクタ上で可視性の切り替えもできます。

アルファが 0 であっても描画されてしまう場合もあります。これはとても重要なので覚えておいてください。従って、レンダリングしない場合は、レンダリングされないように必ず非表示にしてください。

一般的な統計を取得する

Oculus と SteamVR にはパフォーマンスを監視する外部ツールが付いています。これらのツールを使って、コンポジタのオーバーヘッドの実際のフレーム タイミングを確認することを推奨します。

UE4 には、ゲーム中に一般的な統計を取得する方法が何通りかあります。

コンソール コマンド

説明

stat unit

一般的なゲームスレッド、ドロー スレッド、および GPU 時間と全体のフレーム タイミングです。フレーム時間合計が足りているかどうか、およびゲームスレッド時間についての情報収集に最も便利ですが、描画スレッドと GPU 時間には使用できません。

startfpschart / stopfpschart

90Hz 以上になった時間の割合を知りたい時に使うコマンドです。開始してから停止までのウィンドウに関する統計データをキャプチャ、集計し、フレームレート情報がバケット処理されたファイルをダンプします。実際 90 Hz の場合でもゲームは 90Hz より若干低く報告することがあるので、フレームレートにかかった実時間を判断するには、バケットを 80 以上チェックするのが最善です。

stat gpu

4.14 で新たに追加されたコマンドです。GPU プロファイラに同様の統計を、ゲーム中に見て監視できる形式で送ります。GPU の実行負荷をすぐに確認できます。

リアルタイム GPU プロファイラ

新たに登場したリアルタイム GPU プロファイラを使うには、ゲームまたはエディタで stat gpu と入力します。統計は階層ではなく累積なので、イベント ツリーの深い階層まで探さずに主要カテゴリを見ることができます。例えば、シャドウ プロジェクションは (ビュー全体の) すべてのライトに対するすべてのプロジェクションの合計です。

StatGPU.png

ゲームプレイ中に統計を収集したい時 (グラフ作成用に)、リアルタイム統計が特に便利です。リアルタイム表示を使うと、コンソール変数または品質設定でオンにされた機能をプロファイルしたり、エディタ内を最適化してすぐに結果を表示できます。

統計情報は float 型のカウンタとしてコードで宣言されます。例えば、 DECLARE_FLOAT_COUNTER_STAT(TEXT("Postprocessing"), Stat_GPU_Postprocessing, STATGROUP_GPU);

レンダリング コード ブロックは SCOPED_GPU_STAT マクロで計測可能で、SCOPED_DRAW_EVENT と同様に動きます。例えば、 SCOPED_GPU_STAT(RHICmdList, Stat_GPU_Postprocessing);

ドロー イベントとは異なり、GPU 統計は累積です。同じ統計に対して複数のエントリを追加すると、それらは集約されます。

明示的なマークアップがないものはすべて、キャッチオール [unaccounted] 統計に分類されます。値が高くなると、明示的な統計に何も入っていないので、トラッキング マクロを追加する必要があることを示しています。