モバイル向けのレンダリング最適化

モバイル HDR 機能を活用して最大限の忠実度を実現しながら、モバイルでのパフォーマンスを最適化するためのガイドラインとベスト プラクティスについて説明します。 これには以下が含まれます。

• モバイル デバイスでのパフォーマンス バジェットに影響を及ぼす要素に関する情報

• モバイル HDR 機能を有効にしたプロジェクトのパッケージ化に関するベスト プラクティス

• Unreal Engine アプリケーションに潜むパフォーマンスのボトルネック要素を測定するために利用できるツールの紹介

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

アプリケーションのターゲット デバイスでは、メモリ内でのオブジェクトの維持と処理の両方に対して使用できるリソースの量は限られています。 アプリケーションをビルドする際には、これらのリソースを何に対して使用するかを決定しなければなりません。 そのため、CPU および GPU のスピード、スレッド、帯域幅に関するターゲット デバイスの仕様、さらにはデバイスのメモリ、グラフィック メモリ、ディスク容量について把握しておく必要があります。

また、デバイスのベンチマークを行い、デバイスの実行状況やパフォーマンスのボトルネックが発生する部分を把握しておく必要もあります。 デバイスに対してベンチマークを行うには、ベンチマークで対象のアプリケーションまたは技術デモを実行し、そのパフォーマンス統計情報を確認します。

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

一連のコンソール コマンドを利用することでパフォーマンス統計情報を確認できます。 モバイル デバイス上でデベロッパー コンソールを開くには、同時に 4 本の指でディスプレイをタップします。 オンスクリーン キーボードが開き、コンソール コマンドを入力できる画面が表示されます。

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

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

デバイスのパフォーマンス データを得る手段については説明したので、このセクションでは、Unreal Engine のモバイル レンダラでパフォーマンスに最も影響を及ぼすいくつかの要素について説明します。 アプリケーションに影響を及ぼす要素とその仕組みを理解することで、Unreal Engine の診断ツールを使用して迅速に問題を特定し、解決を図ることができます。

法線マップと 高品質の頂点メッシュ

Unreal Engine のモバイル レンダラでは多数の頂点のレンダリングを効率よく実行できる一方で、モバイル レンダラでの高品質の法線マップにはビット深度の問題が発生する可能性があるだけでなく、高ポリゴン モデルよりも多大なパフォーマンス コストがかかります。

ローエンドなハードウェアでは、法線マップを使うことで、反射の品質とモデルのサーフェス上でのライティングが大幅に向上しますが、 車体パネルなどの繊細な形状はこのようなマップでよく使用される 8 ビット デルタを超える可能性があり、最終的なレンダリングでカラーバンディングが生じる場合があります。

これを補正するために 16 ビットの法線マップも使用できますが、16 ビットの法線のピクセル コストは、高密度のメッシュの頂点コストよりも高くなります。 エンジンでは 16 ビットの法線は圧縮されないため、そのサイズは通常の法線マップの 8 倍の大きさとなります。

次の画像では、法線マップを含まない高密度の車体パネルを使用しています。 ターゲットが Galaxy Tab S6 の場合、それぞれの車体パネルを組み合わせるとおよそ 500,000 個の頂点になります。

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

ローポリ モデル用の法線マップに高解像度の頂点をベイクするプロセスは複雑になりがちであり、エンジンに取り込まれるまでに多くの要因によって法線マップ テクスチャの品質が低下することがあります。 法線マップのベイク用のツールセットは多数ありますが、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 つのオプションがあります。

• 最大精度のUVを使用

• 高精度タンジェントベースを使用

これらの設定はどちらも、スタティック メッシュ エディタの [詳細] パネルの [LOD] にあります。

ドロー コール

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

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

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

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

メッシュの数を減らす

ドローコールの数を減らすための最も簡単な方法は、ワールド内の固有のメッシュを削減する方法です。 メッシュを削減するには、Unreal へのインポート前に Maya、3DSMax、Blender などのデジタル コンテンツ制作 (DCC) ツールセットを使用して、できる限り多くのオブジェクトを一つのメッシュに組み合わせます。

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

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

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

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

最終レンダリング

頂点カラー

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

マテリアル

マテリアルの複雑度によってレンダリングにおけるピクセル コストが増加することがあります。 各ピクセルに対する命令数が増えると、レンダリング時に最終的な値を算出するための時間がより多くかかります。 不透明型のマテリアルは最もコストがかからないものではありますが、実際にはシェーディング モデルまたはベース シェーダ コードに応じて大幅に変わります。

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

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

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

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

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

高解像度のテクスチャを使用すると、デバイスとデバイスのテクスチャ メモリに保存するために大量の容量が必要になります。テクスチャが大きいと、それに伴ってレンダリング処理するピクセルの数が増えます。 忠実度は高まりますが、デバイスの画面解像度とテクスチャの視野角に応じて、テクスチャ サイズに対する効果は収穫逓減的に低下します。 できる限り小さなテクスチャを使用して望ましい忠実度を実現することが重要です。

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

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

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

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

アプリケーションとそのアセットをパッケージ化する際には、ディスク上のパッケージ サイズとランタイム起動時のパフォーマンスとの間にトレードオフが生じます。

ZLib 圧縮が有効になっていると、アプリケーションのパッケージ サイズはより小さくなります。 アプリケーションのロード時に必要とされる CPU 時間が長くなって、起動速度が遅くなることがあります。 最適な起動時間にするために、圧縮を無効にすることができます。

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

「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 プラグインを有効にする必要があります。 有効にした後にこのプラグインにアクセスするには、コンテンツ ブラウザ内でフォルダを右クリックし、コンテキスト メニューで [サイズ マップ] を選択します。

サイズ マップでは、それぞれのフォルダとファイルのメモリ消費量を表すアイコン付きのウィンドウが表示されます。 アイコンのサイズが大きいほど、ファイルのメモリ消費量が大きいことを表しています。

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

統計情報

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

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

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

メモリ レポート

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

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

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

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

起動時間を分析する

起動時間に影響を及ぼす要素には次のようなものがあります。

• 初期アセットのロードと圧縮解除にかかる時間

• アプリケーション全体のサイズ

• ユーザーのインストールでアクティブ化する必要があるプラグイン

• パースする必要がある文字列データの量

• ユーザーのデバイス上でのメモリ割り当てまたは断片化

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

たとえば、Android アプリケーションで Unreal Insights を使用する方法については、「Android デバイスでの Unreal Insights」を参照してください。