リアルタイム レンダリングの最適化に関するガイドライン

リアルタイム レンダリングの最適化および開発に関するベスト プラクティス。

Choose your operating system:

Windows

macOS

Linux

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

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

  • パフォーマンス割当量に影響を及ぼしている要因

  • プロジェクトのパッケージ化に関するベスト プラクティス

  • パフォーマンスのボトルネックを割り出すために使用できるツールの使用手順

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

プロジェクトを開発する場合、アプリケーションのターゲット プラットフォームでは、オブジェクトをメモリ上に保持しそれを処理するために使用できるリソースの量は限られています。アプリケーションをビルドする際に、それらのリソースを何に使用するかを決めておく必要があります。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 を使ったプロセスの概要を以下に示します。

  1. 法線マップを Xnormal で 4xAA の 8k TIFF としてベイクする。

  2. TIFF を Photoshop にインポートして 1k テクスチャに解像度を下げる。

  3. ガウス ブラーを「.35px」の値で適用する。

  4. 画像を 16 ビットから 8 ビットに変換する。

  5. 画像を 24 ビット TGA にエクスポートする。

  6. 最終的な法線マップを Unreal にインポートする。

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

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

  • Use Full Precision UVs (最大精度の UV を使用)

  • Use High Precision Tangent Basis (高精度タンジェント ベースを使用)

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

image_2.png

ドローコール

ドロー コールは、フレームごとに生じるアセットのルックアップです。アプリケーションで使用されるドロー コールの数は、シーン内の固有のメッシュ数と、各メッシュで使用されている固有のマテリアル 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 マテリアルに含まれている膨大な数のマテリアル タイプを利用できるようになり、それらをシンプルなテクスチャ入力を持つ マテリアル インスタンス の基礎として使用できます。そうすることで、マテリアルの命令数も減らすこともできるので、パフォーマンスがさらに向上します。

image alt text

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

最終レンダリング

頂点カラー

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

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

マテリアル

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

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

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

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

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

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

image alt text

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

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

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

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

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

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

example mipmap material

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

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

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 (サイズ マップ)] を選択します。

image alt text

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

image alt text

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

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

統計情報

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

image alt text

[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」の各セクションを参照してください。

This page was written for a previous version of Unreal Engine and has not been updated for the current Unreal Engine 5.0 release.