Unreal Engine のパフォーマンスプロファイリングと構成の概要 | Unreal Engine 5.6 ドキュメンテーション

パフォーマンスとは、プロジェクトがターゲットハードウェア上でどれほどスムーズに実行されるかを表す言葉です。 Unreal Engine では、ゲームワールドの画像を繰り返し画面に描画 (レンダリング) して、リアルタイムな表現をシミュレートします。エンジンは、フレームをパラパラ漫画のように高速で連続表示して、効果的な動きを生み出します。レンダリングされるフレームのパフォーマンスは、1 秒あたりのフレーム数やフレーム時間によって測定できます。これらを使用すると、特定のフレーム数を目標にしながら、それらのフレーム内の処理時間をミリ秒単位で測定できるため、アプリケーションのパフォーマンスを把握しやすくなります。

1 秒間にレンダリングするフレーム数が多いほど、動きがよりスムーズになり、アプリケーションの応答性も向上します。一般的に、アプリケーションは、パフォーマンスバジェットとターゲットとなるハードウェアを考慮して、1 秒あたりのフレーム数を 30、60、120 に設定します。最高のユーザーエクスペリエンスを提供するためには、フレームレートを高くすることだけでなく、安定性も必要です。このドキュメントでは、基本的なレンダリングのパフォーマンスに関する考慮事項と、Unreal Engine アプリケーションのレンダリングパフォーマンスを分析および管理するためのツールについて説明します。

パフォーマンスについて理解する

Unreal Engine のロジックの多くは、次の 2 点に依存しています。

現在のフレームで何が起きているのか
前のフレームからの経過時間

フレームがレンダリングされると、次のようなことが起こる可能性があります。

ユーザーがキャラクターや乗り物を移動させる可能性があります。
ユーザーがオブジェクトとインタラクトする可能性があります。
AI が制御するエンティティが移動したり、さまざまなアクションを行ったりする可能性があります。
ユーザーの UI が変化する可能性があります。
画面にあるオブジェクトのアニメーションが進んだり、複数のアニメーションが組み合わさって表示される可能性があります。
物理シミュレーションによって物理的なオブジェクトの位置や回転が変更される可能性があります。

これらの各操作により、コンピュータでは各フレームを描画する際に追加の処理が行われます。また、さまざまなレンダリング設定を調整すると、各フレームの描画プロセスをより複雑に、あるいは簡単にすることができます。設定の調整には、次のようなものがあります。

オブジェクトやテクスチャを詳細に設定します。これにより、コンピュータが関連するピクセルの最終的な色を計算するための時間が長くなります。
ポストプロセス効果を追加します。これにより、レンダリングのさまざまな段階で、画像に対する追加のパスが実行されるようになります。
忠実度の高いライティングやシェーディングを使用します。これにより、シーンがよりリアルになりますが、ライティング計算の複雑度も増します。

各フレームに対してアプリケーションで処理する項目が増えるほど、1 つのフレームをレンダリングするのにかかる時間も長くなります。フレームをレンダリングする時間が長くなりすぎると、全体的なフレームレートが低下し、アプリケーションがスムーズではなくなり、応答性も低下します。

1 秒あたりのフレーム数とフレーム時間を計測する

1 秒あたりのフレーム数とフレーム時間を追跡するには、これらの測定値をビューポートに表示させます。ビューポートのハンバーガーメニューで、[Show FPS (FPS の表示)] のチェックをオンにして [Stat (統計データ)] > [Engine (エンジン)] の順にクリックし、[FPS] と [Unit (単位)] のチェックをオンにします。

[FPS] と [Unit] のチェックがオンになっているビューポートのハンバーガーメニュー。

ハードウェアの制限とフレームレートの低下

フレームレートが低下する原因は、1 つのフレーム内で行われる処理が多すぎるためです。これは通常、フレームが画面に描画されるたびに繰り返される処理によって発生します。たとえば、レンダリングされる各フレームを、駅を出発する予定の電車と、そのミリ秒後に到着する別の電車に置き換えて考えてみます。ただし、この電車は、切符を買った乗客がすべて乗車しないと出発できません。そのフレーム内での各操作は、ゲームプレイであってもレンダリングロジックであっても、乗車しなければならない別の乗客のようなものです。

1 つのフレームの処理に時間がかかりすぎる状態は、あまりにも多くの乗客を乗せようとしているために全員がまだ乗車できておらず、電車が発車できないのと同じです。そのため、次の電車が駅に入れません。画面上ではフレームレートが低下します。これは一時的に発生し、特定のフレームが長く停止して画面上で明らかにヒッチが起きることもあれば、各フレームで継続的に発生し、全体的なフレームレートが低下することもあります。

次のコンピュータリソースのいずれかが、ボトルネックの原因となる可能性があります。

CPU：コンピュータの中央処理装置 (Central Processing Unit：CPU) が、1 つのフレーム内で、1 つ以上のスレッドに対して実行している処理が多すぎる場合。これは、アプリケーションの UI、ゲームプレイロジック、その他のコアロジックが非効率的に動作していること、または 1 つのフレーム内で実行されている処理が多すぎることを示しています。
GPU：コンピュータの画像処理装置 (Graphics Processing Unit：GPU) が 1 つのフレーム内で実行している処理が多すぎる場合。これは、ゲームのレンダリングやポストプロセスが非効率的に動作していること、または GPU に過剰な負荷がかかり、処理が追いついていないことを示しています。

メモリサイズ (RAM)：コンピュータのランダムアクセスメモリ (Random Access Memory：RAM) がいっぱいで、空き容量ができるまで処理を完了できない場合。この場合、パフォーマンスが低下 (ヒッチ) するのではなく、メモリ不足による例外によってクラッシュする傾向があります。ガベージコレクションやアセットストリーミングのようなシステムには柔軟性があり、クリーンアップの処理を動的に遅延させることができます。 RAM がいっぱいになると、これらのシステムはクリーンアップと再読み込みをより頻繁に実行する必要があるため、CPU の負荷が増加します。
メモリ速度 (RAM)：CPU は、物理的にコアと同じ場所にある小さなデータのチャンクを処理し、必要に応じてこれらを RAM と交換します。これらの処理は、CPU と RAM 間でチャンクを交換するよりもはるかに早く完了します (たとえば、CPU では新しいデータをロードするのにかかる時間内に、ロード済みのデータを 20 回操作できます)。 RAM の速度が遅いほど、また、操作が必要なメモリのチャンク間でより頻繁にロジックを切り替える必要があるほど、CPU コアではメモリバスを待機するために何もしない時間が増え、アイドル状態になります。
GPU メモリ (VRAM)：GPU の RAM がいっぱいで、空き容量ができるまで処理を完了できない場合。これは通常、テクスチャが大きな容量を占めることによるもので、テクスチャメモリのオーバーロードが原因です。
ハードドライブアクセス：オブジェクトはハードドライブやその他のストレージデバイスからロードされた後、メモリに追加されます。ストレージデバイスへ頻繁にアクセスする必要がある場合、処理が完了できなくなります。
ネットワーク帯域幅：コンピュータのインターネット接続が遅いか信頼性が低いため、信頼性のあるパケットの組み立てや再送信に各フレームでの CPU の負荷が増加します。それにより、いくつものフレームに分散されるはずの処理が急に集中したり、ローカルのパフォーマンスにボトルネックがないにもかかわらず、映像がかくつくことがあります。

CPU バウンドと GPU バウンド

アプリケーションについて、パフォーマンスが CPU と GPU のどちらにより強くバインドされているかを分類します。 CPU がボトルネックを引き起こす可能性が高い場合は、CPU バウンドです。 GPU がボトルネックを引き起こす可能性が高い場合は、GPU バウンドです。 Vsync をオンにして、CPU と GPU の両方がモニターの表示速度よりも速くフレームを生成できる場合、そのアプリケーションはディスプレイバウンドになります。多くの場合、これはターゲットプラットフォームとそのリソースに依存します。

処理スパイク

処理スパイクとは、フレーム内で CPU や GPU の処理時間が突然、一時的に増加することを指します。

コストの高い処理とコストの低い処理

一般的に、コストの高い処理は、実行するために比較的大量のコンピュータリソースを必要とします。これは処理時間が長くなったり、メモリを大量に消費したりすることを意味する場合があります。一方、コストの低い処理は、大量のコンピュータリソースを必要としません。これらの用語は、多くの場合、同様の処理を行うプロセスを比較するために使用されます。

リアルタイムアプリケーションのメモリ

処理やレンダリングが可能なものはすべて、アプリケーションのメモリ内に存在します。ただし、Nanite のバーチャルジオメトリなどの一部のものは、ソリッドステートハードドライブ (SSD) から直接ストリーミングされるため例外です。簡単に考えると、それを画面上に表示させたり、移動させたりする場合は、そのコピーがコンピュータのメモリ内に存在し、オブジェクトのテクスチャ、シェーダー、メッシュなどのレンダリングされたリソースは、GPU メモリ内に存在します。

パフォーマンスと使用電力

電力の使用量はハードウェアアーキテクチャによって異なりますが、一般的に、処理する負荷が大きい場合や、1 秒あたりにレンダリングするフレーム数が多い場合は、どちらもより多くの電力を消費することにつながります。モバイルや HMI の場合はデバイスの電力消費量が大きな懸念事項となるため、アプリケーションはできるだけ効率的に動作させることが強く推奨されています。プレイヤーは、他のゲームに比べてスマホのバッテリー消耗が激しいゲームに対して、否定的な評価をすることがあります。また、より多くのエネルギーを消費することでスマホの温度が上昇すると、サーマルスロットリングが発動し、スマホが冷めるまで CPU の動作が遅くなります。

プロファイリングツール

プロファイリングとは、CPU や GPU の処理、メモリ使用量、ネットワーク帯域幅など、アプリケーションによるシステムリソースの使用状況を分析することを指します。 Unreal Engine では、プロファイリングツールのセットをいくつか提供しています。


ツール	説明
Unreal Insights	フレームごとにパフォーマンスのデータを記録し、確認します。
Stat コマンド	パフォーマンスに関する統計情報を画面に表示します。

Android デバイスで Unreal Insights を利用する際の詳細は、「Android デバイスでの Unreal Insights」ページを参照してください。

また、プロファイリングには、次のようなサードパーティのツールも使用できます。


ツール	説明
RenderDoc	アプリケーションのグラフィックスの単一フレームキャプチャをデバッグします。
Perfetto	完全なシステムプロファイルを作成し、トレースデータを処理します。

プロファイリングは、ゲームが使用しているのと同じ CPU、RAM、ディスクを使用する点に注意してください。プロファイラをアタッチしてゲームを実行すると、パフォーマンスがわずかに低下します。これには良い面もあります。パフォーマンスの目標を達成したように見える場合でも、実際にはその目標を超えており、予期しないシステムの変動が発生しても、ゲームが目標の状態を維持できるように空きリソースを確保できます。

Unreal Insights

Unreal Insights は、Unreal Engine で利用できる堅牢かつ強力なプロファイリングツール群で、個々のスレッド、メモリ使用量、ネットワーク帯域幅をプロファイリングする機能を提供します。各処理が CPU や GPU 上で何ミリ秒かかるか、Memory Insights でどれくらいメモリが割り当てられているか、Network Insights でテレメトリやパケットデータの詳細を確認することができます。また、タスクグラフ、コンテキストスイッチ、Slate UI 要素向けの特別なモードも提供され、アプリケーションのパフォーマンスについて深く分析することができます。

Stat コマンド

Stats とは、実行中の UE アプリケーション内で統計情報を画面に出力するために使用できる一連のコンソールコマンドを指します。統計コマンドは、次のような幅広い処理やシステム向けに用意されています。

メモリトラッキング
GPU と CPU のロード
ゲームプレイティック
UI
アニメーション

Stat コマンドの使用は、Unreal Insights や RenderDoc を利用する場合ほど堅牢ではありませんが、アプリケーションの実行またはテスト中に発生している状況に関するデータを取得できる最も簡単な方法です。

Stat コマンドの完全なリストについては、「Stat コマンド」ページを参照してください。

RenderDoc

RenderDoc はオープンソースのグラフィックデバッガです。UE にアタッチして単一フレームのキャプチャを出力できます。 RenderDoc には多くの機能があり、たとえば次のような処理を実行できます。

テクスチャ、モデル、シェーダーを調査する。
個々の描画イベントを表示する。
フレームをキャプチャする時点でのアプリケーションのパイプラインの状態を詳細に表示する。

Unreal Insights を使用すると、レンダリング処理中に、特に多くの処理リソースやメモリリソースを消費している部分に関する概要が提供されます。一方、RenderDoc はレンダリング処理に関する詳細な診断により適しており、バグの発生場所を正確に特定することができます。たとえば、ターゲットデバイスではアーティファクトがレンダリングされるのに、Play-In-Editor ではされない場合、RenderDoc を使用すると、両方でフレームをキャプチャしてデータを比較し、アーティファクトの表示に差が出る原因を調べることができます。

パフォーマンス構成ツール

プロジェクトのレンダリング設定とスケーラビリティ設定を調整するための手順の多くは、コンソールコマンドや変数を参照しています。このセクションでは、それらの使用方法と、深く理解するのに役立つリソースについて説明します。

コンソールコマンドと変数

コンソールとは、Unreal Engine 内で設定の変更、デバッグコマンドの実行、実行しているゲームの情報取得に使用できるコマンドラインです。 Unreal Editor やパッケージ化したプロジェクトのデベロッパービルド、デバッグビルドでコンソールコマンドを使用するには、チルダ (~) キーを押します。これによりコマンドラインが開き、コマンドを入力するプロンプトが表示されます。

UE のコマンドでは検索/オートコンプリート機能がサポートされているため、コマンドの一部を入力して、探しているコマンドの候補リストを絞り込むことができます。たとえば、「Stat」と入力すると、Stat コマンドのリストが表示されます。

コンソール変数 (CVar) は、コンソールコマンドを使用して編集できるコンフィグ変数です。コンソールで CVar を直接変更するには、変数の構成パスを入力してから、その変数に設定したい値を入力します。たとえば、次のようになります。

Command Line

r.TemporalAA.Quality 0

r.TemporalAA.Quality 0

上記のコマンドでは、r.TemporalAA.Quality CVar を「0」に設定し、実質的にテンポラルアンチエイリアシングを無効にしています。これにより、オブジェクトのエッジがよりギザギザになり、ピクセル化されたように見えます。

コンソールの詳細については、以下のページを参照してください。

コンソールコマンドと変数 – コンソールの詳細な使用方法の概要です。
コンソールコマンドのリファレンス – コンソールコマンドの完全なリストです。
コンソール変数のリファレンス – コンソール変数の完全なリストです。
コンソール変数エディタ – Unreal Editor からコンソール変数を直接編集するためのプラグインです。

また、ブループリントや C++ でコンソールコマンドを使用すると、シッピングビルドでコンソールが無効になっている場合でも、いつでも変数を変更することができます。これは、アプリケーションの実行中に設定を選択的にスケールするのに役立ちます。

出力ログ

Unreal Editor でコンソールを使用する場合、コマンドとログの記録が含まれる [Output Log (アウトプットログ)] を表示すると、状況を理解しやすくなります。

Unreal Editor で [Output Log] を表示するには、[Window (ウィンドウ)] > [Output Log] の順にクリックします。 [Output Log] がエディタの下部にドッキングされます。

保存されたログファイルがプロジェクトの「Saved/Logs」フォルダに表示されます。

コンフィグファイル

コンソール変数は、ゲームのビルドのデフォルト設定を提供するキー / 値のペアとしてコンフィグ (.ini) ファイルに保存されます。詳細については、「コンフィギュレーションファイル」を参照してください。

デバイスプロファイル

デバイスプロファイルは、プロジェクトがターゲットとする特定のデバイスの設定を含むコンフィギュレーションファイルです。これは、Android_Mid のような大規模なデバイスグループを対象とすることも、個々のハードウェア単位で細かく設定することもできます。各デバイスプロファイルには、その特定のデバイスに対してのみ適用される一連の設定オーバーライドが含まれています。

Unreal Engine のデバイスプロファイルは、主に Adreno 7xx シリーズなどの GPU ファミリを中心に設定されていますが、サポートするハードウェアに応じて独自のカスタムデバイスプロファイルを追加し、ルールを定義することもできます。

詳細については、「Android 向けのデバイスプロファイルとスケーラビリティのカスタマイズ」を参照してください。

参考文献

アプリケーションのパフォーマンスに影響を与える可能性がある状況と要因の詳細については、「パフォーマンスに関する一般的な考慮事項」を参照してください。

ヒントとベストプラクティス

早い段階からテストを行い、頻繁にテストする

テストを行うときは、プロジェクトでサポートしているプラットフォームごとに固有のバグが発生することを想定しておきます。 Unreal Editor では正確なプレビューを提供できるよう最大限の努力をしていますが、ターゲットのハードウェアで直接プロファイリングすることには及びません。ハードウェア上でテストを行わない期間が長くなると、予期しないバグが発生する可能性が高くなります。