Unreal Engine でリアルタイムレンダリングの最適化に関するガイドライン | Unreal Engine 5.0 ドキュメンテーション

このページでは、リアルタイムレンダリング機能によりできる限り忠実度を高めながら、パフォーマンスを特定および最適化する方法に関するガイドラインおよびベストプラクティスについて説明します。

このページでは次のことについて説明します。

パフォーマンス割当量に影響を及ぼしている要因
プロジェクトのパッケージ化に関するベストプラクティス
パフォーマンスのボトルネックを割り出すために使用できるツールの使用手順

パフォーマンス割当量を把握する

プロジェクトを開発する場合、アプリケーションのターゲットプラットフォームでは、オブジェクトをメモリ上に保持しそれを処理するために使用できるリソースの量は限られています。アプリケーションをビルドする際に、それらのリソースを何に使用するかを決めておく必要があります。CPU と GPU の速度、スレッド数、帯域幅に関するターゲットプラットフォームの能力、および見込みメモリ量、グラフィックメモリ、空きディスク容量について把握しておくことは、すべて考慮すべき重要な要因です。

また、搭載する予定のすべてのプラットフォームでプロジェクトのベンチマークを行って、どのように実行されて、どこがパフォーマンスのボトルネックに直面するかを把握しておくことも重要です。プラットフォームまたはデバイスでベンチマークを行うには、要求の厳しいアプリケーションまたは技術デモを実行して、そのパフォーマンス統計情報を確認します。プロジェクトを同じやり方で定期的にテストおよびベンチマークすることが重要です。

パフォーマンス統計情報を表示するためのコンソールコマンド

プロジェクトの実行中に一連のコンソールコマンドを使用して、パフォーマンス統計情報をチェックします。それらのコマンドは、プロジェクトが起動されている場合、または開発ビルドとしてパッケージ化されている場合に、コンソールウィンドウで入力できます。

The console window displayed in a mobile application with the onscreen keyboard.

モバイルアプリケーションに表示されたコンソールウィンドウ

このコンソールと 4 本指でのタップコマンドを利用できるのは開発ビルドのみであり、シッピングビルドやテスト用ビルドでは利用できません。

コンソール内では、コマンドを入力して画面にデバッグ情報を表示することができます。パフォーマンス情報を提供するコマンドの一覧を次の表に示しています。

コマンド	説明
`Stat GPU`	さまざまなプロセスでの GPU の使用時間をミリ秒単位で表示します。
`Stat Unit`	さまざまなプロセスでの CPU の使用時間をミリ秒単位で表示します。ゲームスレッド、レンダリングスレッド、GPU 時間も表示されます。
`Stat UnitGraph`	CPU と GPU の使用率の経時変化を示すグラフを表示します。これはスパイクの検知に役立つことがあります。
`Stat TextureGroup`	テクスチャのさまざまなプールのメモリ使用量を表示します。

デバイス上でのアプリケーションのパフォーマンスを分析するために利用できる他のコンソールコマンドについては、「Stat コマンド」を参照してください。

一般的なパフォーマンス要因

パフォーマンスデータを見つける場所は特定できているので、このセクションでは、パフォーマンスに影響を及ぼすことが最も多いいくつかの要素について説明します。どの要因がプロジェクトにどのように影響を及ぼしているかを理解することで、エンジンのビルトイン診断ツールを使用して要因の特定および対処を開始することができます。

高解像度の法線マップに対するベストプラクティス

ローポリモデル向けに高解像度の頂点を法線マップにベイクするプロセスは複雑になりがちで、エンジンに取り込むまでにさまざまな要因で法線マップテクスチャの品質が低下することがあります。法線マップのベイク用のツールセットは多数ありますが、xNormal を使用することをお勧めします。xNormal を使ったプロセスの概要を以下に示します。

法線マップを Xnormal で 4xAA の 8k TIFF としてベイクする。
TIFF を Photoshop にインポートして 1k テクスチャに解像度を下げる。
ガウスブラーを「.35px」の値で適用する。
画像を 16 ビットから 8 ビットに変換する。
画像を 24 ビット TGA にエクスポートする。
最終的な法線マップを Unreal にインポートする。

ベイク処理で使用するサーフェス法線がエンジンに存在するものと同じになるように、最適化された法線を Unreal 内からエクスポートする必要があります。ベイク処理モデルを Unreal にインポートし、独自の法線を作成することを選択し、ベイク処理モデルを Unreal からエクスポートして、xNormal でベイクします。これは、高解像度モデルからのオフセットを適用するために xNormal がメッシュのサーフェス法線を認識しておく必要があるので、高品質の法線マップを作成する場合に重要なステップです。

そして、スタティックメッシュ のレンダリング時にアーティファクトを減らすための 2 つのオプションがあります。

Use Full Precision UVs (最大精度の UV を使用)
Use High Precision Tangent Basis (高精度タンジェントベースを使用)

どちらの設定も、スタティックメッシュエディタの [Details] パネルの [LODs] セクションにあります。

ドローコール

ドローコールは、フレームごとに生じるアセットのルックアップです。アプリケーションで使用されるドローコールの数は、シーン内の固有のメッシュ数と、各メッシュで使用されている固有のマテリアル ID 数によって決まります。現時点ではドローコールの数が多いことがグラフィックパフォーマンスの低下に最も影響を及ぼす要因であるため、ドローコールの数をできる限り減らす必要があります。

たとえば、高度に最適化された自動車モデルに 5 個または 6 個の独立したメッシュがあり、それらのコンポーネントにそれぞれ 1 つのマテリアルのみがあるとします。

最適化されたシーン内での適切なドローコールの数は、Galaxy Tab S6 ではおよそ 700 回であり、ローエンドのハードウェアでは 500 回未満です。HMI 向けのプロジェクトでは非常に独特なマテリアルや複雑なマテリアルを使用する傾向があるため、Galaxy Tab S6 では 100 回のドローコールが適切ですが、50 回未満に抑えることが理想的です。

ドローコールの数を出力するには、コンソールコマンド Stat RHI を使用します。

ドローコールの数は、PIE モードであるかデバイス上であるかによって異なることに注意してください。 |

メッシュの数を減らす

ドローコールの数を減らすための最も簡単な方法は、ワールドでレンダリングされる固有メッシュの数を減らすことです。そのための方法として、エンジンのビルトインツールを使用して複数のメッシュを結合させる方法と、可視性カリングを使用する方法の 2 つがあります。

固有メッシュを結合させる。
外部 DCC アプリケーション (モデリングプログラムなど) を使用して、メッシュを手動で結合する。
または、エディタ内のワールド構築ツール (Hierarchical Level of Detail など) では、複数のメッシュとテクスチャを結合させることによってレベルで自動的にメッシュを生成できるので、ドローコールの数を減らすことができます。
可視性カリング
エンジンは可視性カリングおよびオクルージョンカリングの複数の方法を使用して、レンダリングするメッシュの数を減らします。カリング距離ボリューム (Cull Distance Volume) は、サイズとプレイヤーカメラからの距離で指定された追加メッシュを取り除くことができる配置済みボリュームです。

マテリアル ID の数を減らす

メッシュ上の固有マテリアルの数を減らすにはいくつかの方法があります。

最もシンプルな方法は、複数のマテリアルを同じテクスチャに統合するプログラム (Substance Painter など) を使用することです。このようなプログラムを使用すると、非常にシンプルな Unreal マテリアルに含まれている膨大な数のマテリアルタイプを利用できるようになり、それらをシンプルなテクスチャ入力を持つ マテリアルインスタンス の基礎として使用できます。そうすることで、マテリアルの命令数も減らすこともできるので、パフォーマンスがさらに向上します。

もう一つの方法は マスキング を使ったよりプロシージャルなアプローチです。マテリアルでは、カラーやラフネス、メタリックの品質など、サーフェスの特定の性質を示すことができます。メッシュのさまざまなパーツに対して異なるマテリアルを使用するのではなく、マスクを使ってメッシュの UV のパーツを分離し、各セクションに異なる設定を適用できます。基本マスクは白と黒のテクスチャを使って作成できますが、頂点カラー を使用する方が効率的です。

次の図では、頂点カラーを使用してさまざまなマテリアルタイプを定義していて、マテリアルではそれらのパーツの外観に個別に影響を及ぼすパラメータを定義しています。頂点カラーによるマスキングはテクスチャの解像度に左右されないので、より効率的な方法であり、よりシャープな分離になります。

頂点カラーを使用してさまざまなマテリアルタイプを分離しているマテリアル

マテリアル

マテリアルの複雑さによって、レンダリングされるフレームのピクセルコストが増加する可能性があります。各ピクセルに対するマテリアルの命令数が増えるほど、レンダリング時に最終的な値を算出するのにかかる時間が長くなります。不透明なマテリアルは最もコストがかからないマテリアルですが、実際にはシェーディングモデルやベースシェーダコードに応じて大幅に変わります。

マテリアルの命令数は、マテリアルエディタ 内の [Stats] ウィンドウに示されている測定値で確認できます。

命令数が表示されている [Stats] ウィンドウ

命令数は、マテリアル内の演算関数の数によっても変わります。含まれているノード数が多いほど、マテリアルのレンダリングにかかるコストが大きくなります。また、より多くのコストがかかる演算もあります。複雑なマテリアルをビルドする際は、できる限り命令数を少なく抑えるようにします。

透明な マテリアルは、最も負荷のかかるマテリアルタイプの 1 つです。透過処理における個別のレイヤーにはピクセルごとに高いコストがかかり、透明性の複数のレイヤーをスタックしてレンダリングする際には多大なコストとなります。これは「オーバードロー」として知られています。

透過処理の問題点の例として、車両のヘッドライトとテールライトがあります。多くの場合、マテリアルの複雑さを抑えるために手描きのテクスチャマップが使用されています。平坦なテクスチャを使っている場合でも、複雑な形状と深度をうまく描画することができます。

テクスチャ解像度を最適化する

プロジェクトでテクスチャの最適化に取りかかるにはいくつかの方法があります。ほとんどどのようなサイズのテクスチャでも使用できるようにし、画面上で必要とされるパーツのみをレンダリングする、ビルトインの仮想テクスチャリングを使用することも、標準のテクスチャリング方法を使用することもできます。

仮想テクスチャとして有効になっていない標準のテクスチャでは、特に高解像度のテクスチャで多くのスペースが必要になることがあり、どちらもメモリとディスクに格納されます。忠実度は向上することがありますが、画面解像度とテクスチャの視野角に応じて、テクスチャサイズに対する効果は徐々に低下します。できる限り小さなテクスチャを使用して望ましい忠実度を実現することが重要です。

テクスチャ関連のニーズを明確にするには、まずモデルの表示に使用する カメラ位置 と 視野角 (FOV) を最終化する必要があります。そうすることで、使用されるすべてのメッシュとマテリアルのスクリーン空間を判断しやすくなります。

カメラ位置を決定したら、ミップマップ を調べる特殊なデバッグテクスチャを使用して、さまざまなマテリアルに使用するテクスチャ解像度を判断します。デバッグミップマップテクスチャを使用すると、各ミップマップにさまざまなカラーを適用して、それぞれのコンポーネントに必要な解像度を判断するのに役立ちます。そうすることで、マテリアルが使用しているミップと使用すべきテクスチャ解像度を特定しやすくなります。

テストマテリアルを作成する場合は、デバッグミップマップテクスチャを ライティングなし マテリアルの エミッシブ チャンネルにつなぎ、そのマテリアルをメッシュに適用します。そのメッシュを適切な距離のカメラ位置から見ると、エンジンがどのミップレベルをレンダリングに使用しているかがカラーコードで示されます。表示される最高レベルは、法線マップおよび アンビエントオクルージョン マップのネイティブのテクスチャサイズになります。

デバッグミップマップマテリアルが適用されているメッシュの例

パッケージサイズと起動時間

Unreal Engine プロジェクトとそのアセットをパッケージ化する際に、ディスク上のパッケージサイズとランタイム起動時のパフォーマンスの間にトレードオフが存在します。

ZLib 圧縮 を利用すると、アプリケーションのパッケージサイズをより小さくすることができますが、アプリケーションのロードにより多くの CPU 時間が必要になり、起動スピードが遅くなる場合があります。起動時間を最適化するには圧縮を無効にします。

Zlib 圧縮設定は [Project Settings] > [Packaging] にあります。

推奨されるストリーミング設定

「DefaultEngine.ini」ファイルでは次のストリーミング設定が推奨されます。推奨される設定では、アプリケーションの起動時にアセットの非同期ロードのための時間が余分に提供されるため、起動時間が向上します。

	[/Script/Engine.StreamingSettings]
	s.PriorityAsyncLoadingExtraTime=275.0
	s.LevelStreamingActorsUpdateTimeLimit=250.0
	s.PriorityLevelStreamingActorsUpdateExtraTime=250.0

推奨されるパッケージング設定

「 DefaultEngine.ini 」ファイルでは次のパッケージング設定が推奨されます。起動時における非圧縮 .pak ファイルのロードは ZLib 圧縮ファイルよりもはるかに高速であるため、推奨される設定では、アセットのパッケージ化で使用される圧縮の量を低減します。

	[/Script/UnrealEd.ProjectPackagingSettings]
	bCompressed=False
	BuildConfiguration=PPBC_Development
	bShareMaterialShaderCode=True
	bSharedMaterialNativeLibraries=True
	bSkipEditorContent=True

ディスク上のパッケージサイズを分析する

Unreal Engine には、アセットのデータフットプリントを分析できる便利なツールがいくつか備わっています。

サイズマップ

サイズマップ はエディタでのアセットの相対メモリ消費量を読み取り、比較します。このツールを使用するには AssetManagerEditor プラグインを有効にする必要があります。有効にした後にこのプラグインにアクセスするには、コンテンツブラウザ内でフォルダを右クリックし、コンテキストメニューの [Size Map (サイズマップ)] を選択します。

[Size Map] を選択すると、それぞれのフォルダとファイルのメモリ消費量をアイコンで示すウィンドウが表示されます。アイコンのサイズが大きいほど、そのファイルが消費する容量が大きいことを表しています。

サイズマップの使用については、「クック処理とチャンク化」を参照してください。

サイズマップでは、アセットがエディタ内で使用されるとそのフットプリントを読み取ります。プロジェクトのパッケージ化後はメモリ消費量が変わります。これは、クック処理において異なるタイプの圧縮が行われることが原因です。経験則ですが、サイズマップにはアセットで受け取り可能な最大サイズが表示されることに留意してください。

統計情報

統計ツールは、レベル内のアセットの使用状況に関するより詳細な情報を提供します。このツールは [Window (ウィンドウ)] メインメニューにあります。

[Statistics (統計)] ウィンドウにはレベルファイル内にあるアセットの数がそれぞれ表示されます。すべてのレベルまたは特定のレベルの統計情報を表示できます。[Primitive Stats (プリミティブ統計)] では、三角ポリゴンの数、メモリ消費量、カウントなどの情報が表示されます。

[Primitive Stats] が表示されている [Statistics] ウィンドウ

この一覧に表示される他のデータとして、テクスチャの使用量やスタティックメッシュのライティング情報などがあります。[Statistics] ウィンドウの一覧モードでは、メモリ使用量が最も多いアセットを素早く示すことができます。また、[Cooker Stats (クッカー統計)] のデータでは、直近のパッケージ化プロセスでクックされたすべてのアセットが一覧表示されるので、非常に便利です。

メモリレポート

統計情報ツールとサイズマップツールでは Unreal Editor 内のファイルのデータフットプリントが表示されますが、ターゲットデバイスで実行されるアプリケーションのインストールからコンソールコマンド Memreport -full を使用することもできます。このコマンドでは、デバイスの圧縮設定を適用済みの正確かつ詳細なファイルサイズが表示されます。

アプリが開発コンフィギュレーションでビルドされてデバイスにロードされると、コンソールウィンドウを開いてこのコマンドを入力することができます。このメモリ情報はデバイス上のプロジェクトディレクトリに保存されます。通常は「UE4Game/[YourApp]/[YourApp]/Saved/Profiling/Memreports/」ディレクトリに保存されますが、環境によって異なることがあります。

「.memreport」ファイルはテキストファイルであるため、ほとんどのテキストエディタで読み取ることができますテキストの冒頭には、割り当てられているメモリとプールサイズに関する情報があり、その後の大部分のテキストは、ロードされたレベル、RHI 統計情報、レンダーターゲット、シーン情報などに関する記録を表しています。これらはクック処理とパッケージ化プロセス後の実際のデータを示すものであるため、デベロッパーにとっては非常に有益な情報です。

「Listing all textures」で検索すると、アプリケーション内のすべてのテクスチャと、そのテクスチャタイプ、グループ、サイズ、メモリフットプリントに関する詳細な情報を含むリストを確認できます。このリストは、メモリサイズが大きいテクスチャから降順で並べられています。このリストを利用すれば、どのテクスチャが最も多くのメモリを消費しているかを素早く簡単に確認できます。

起動時間を分析する

起動時間に影響を及ぼす要因を以下に示します。

初期アセットのロードと圧縮解除にかかる時間の長さ
アプリケーションの全体的なサイズ
ユーザーのインストールで有効にする必要のあるプラグイン
解析する必要のある文字列データの量
ユーザーのデバイス上のメモリ割り当てまたは断片化

アプリケーションの起動時間を解析するツールにはさまざまなものがありますが、パフォーマンスデータをターゲットデバイスからリモートでプロファイリング可能な Unreal Insights を強く推奨します。このツールセットの詳細については、「Unreal Insights」の各セクションを参照してください。