モバイル HDR 機能を活用して最大限の忠実度を実現しながら、モバイルでのパフォーマンスを最適化するためのガイドラインとベスト プラクティスについて説明します。次のトピックが含まれます。次のトピックが含まれます。
-
モバイル デバイスでの「パフォーマンス バジェット」に影響を及ぼす要素についての情報
-
モバイル HDR 機能を有効にしたプロジェクトのパッケージ化に関するベスト プラクティス
Unreal Engine アプリケーションに潜むパフォーマンスのボトルネック要素を検知するための各種ツールの紹介
次の各リンク先には、Android でのパフォーマンスに関する全般的なトピックについての有益な情報が含まれています。
パフォーマンス バジェットについて把握する
アプリケーションのターゲット デバイスでは、メモリ内でのオブジェクトの維持と処理の両方に対して使用できるリソースの量は限られています。アプリケーションをビルドする際には、これらのリソースを何に対して使用するかを決定しなければなりません。そのため、CPU および GPU のスピード、スレッド、帯域幅に関するターゲット デバイスの仕様、さらにはデバイスのメモリ、グラフィック メモリ、ディスク容量について把握しておく必要があります。
また、 ベンチマーク を行って、ターゲット デバイスの実行状況やパフォーマンス ボトルネックとなり得る領域を確認しておく必要もあります。デバイスに対してベンチマークを行うには、ベンチマークで対象のアプリケーションまたは技術デモを実行し、そのパフォーマンス統計情報を確認します。
パフォーマンス統計情報を表示するためのコンソール コマンド
一連の コンソール コマンド を利用することでパフォーマンス統計情報を確認できます。モバイル デバイス上でデベロッパー コンソールを開くには、同時に 4 本の指でディスプレイをタップします。オンスクリーン キーボードが開き、コンソール コマンドを入力できる画面が表示されます。
モバイル アプリケーションに表示されたコンソール ウィンドウ
このコンソールと 4 本の指でのタップを利用できるのはデベロッパー ビルドのみです。シッピングまたはテスティング用のビルドでは利用できません。
コンソール内では、コマンドを入力して画面にデバッグ情報を表示することができます。次の表には、パフォーマンス情報を提供する各コマンドが記載されています。
| コマンド | 説明 | |||
|---|---|---|---|---|
| Stat GPU | GPU によってさまざまなプロセスに使用される時間 (ミリ秒) を表示します。
|
|||
| Stat Unit | CPU によってさまざまなプロセスに使用される時間 (ミリ秒) を表示します。さらに、ゲーム スレッド、レンダリング スレッド、GPU 時間も表示されます。 | |||
| Stat UnitGraph | CPU と GPU の使用率を時間の経過とともに示すグラフを表示します。スパイクの検知に役立ちます。 | |||
| Stat TextureGroup | テクスチャのさまざまなプールのメモリ使用量を表示します。 |
デバイス上でのアプリケーションのパフォーマンスを分析する他のコンソール コマンドについては、「Stat コマンド」を参照してください。
全般的なパフォーマンス要素
デバイスのパフォーマンス データを得る手段については説明したので、このセクションでは、Unreal Engine のモバイル レンダラでパフォーマンスに最も影響を及ぼすいくつかの要素について説明します。アプリケーションに影響を及ぼす要素とその仕組みを理解することで、Unreal Engine の診断ツールを使用して迅速に問題を特定し、解決を図ることができます。
法線マップと高品質の頂点メッシュ
Unreal Engine のモバイル レンダラでは多数の頂点のレンダリングを効率よく実行できる一方で、モバイル レンダラでの高品質の法線マップにはビット深度の問題が発生する可能性があるだけでなく、高ポリゴン モデルよりも多大なパフォーマンス コストがかかります。
ローエンドなハードウェアでは、法線マップを使うことで、反射の品質とモデルのサーフェス上でのライティングが大幅に向上しますが、車体パネルなどの繊細な形状はこのようなマップでよく使用される 8 ビット デルタを超える可能性があり、最終的なレンダリングでカラーバンディングが生じる場合があります。
これを補正するために 16 ビットの法線マップも使用できますが、16 ビットの法線のピクセル コストは、高密度のメッシュの頂点コストよりも高くなります。エンジンでは 16 ビットの法線は圧縮されないため、そのサイズは通常の法線マップの 8 倍の大きさとなります。
次の画像では、法線マップを含まない高密度の車体パネルを使用しています。ターゲットが Galaxy Tab S6 の場合、それぞれの車体パネルを組み合わせるとおよそ 500,000 個の頂点になります。
高解像度の法線マップに対するベスト プラクティス
ローポリ モデル向けに高解像度の頂点を法線マップにベイクするプロセスは複雑になりがちで、エンジンに取り込むまでにさまざまな要因で法線マップ テクスチャの品質が低下することがあります。法線マップのベイクにはさまざまなツールセットがありますが、Epic では XNormal を推奨しています。Xnormal を使った当社のプロセスの概要は次のとおりです。
- 法線マップを Xnormal で 4xAA の 8k TIFF としてベイクする。
- TIFF を Photoshop にインポートして 1k テクスチャに解像度を下げる。
- ガウス ブラーを「.35px」の値で適用する。
- 画像を 16 ビットから 8 ビットに変換する。
- 画像を 24 ビット TGA にエクスポートする。
- 最終的な法線マップを Unreal にインポートする。
ベイク処理で使用するサーフェス法線とエンジンで提供されるものとが同じになるように、最適化された法線は Unreal からエクスポートしてください。ベイク処理するモデルを Unreal にインポートして独自の法線を作成し、Xnormal でベイク処理するモデルを Unreal からエクスポートします。これは、Xnormal では高解像度モデルからのオフセットを適用するために、メッシュのサーフェス法線について認識しておく必要があるため、高品質の法線マップを作成する際には重要なステップです。
最後に、 スタティック メッシュ のレンダリング時にアーティファクトを低減する 2 つのオプションがあります。
-
最大精度の UV を使用する
-
高精度タンジェント ベースを使用する
これらの設定は、いずれも スタティック メッシュ エディタ の [Details (詳細)] パネルにあるそれぞれの LOD 設定セクションにあります。
ドローコール
ドローコールは、フレームごとに生じるアセットのルックアップと言えます。アプリケーションで使用されるドローコールの数は、シーン内の固有のメッシュ数と、各メッシュで使用される固有のマテリアル ID 数に基づいています。現時点ではドローコールの数がグラフィックのパフォーマンスに最も影響を及ぼす要素であるため、ドローコールの数を可能な限り減らす必要があります。
例えば、高度に最適化された自動車モデルに独立したメッシュが 5 または 6 個含まれており、これらのコンポーネントにはそれぞれ 1 つのマテリアルのみが含まれているとします。
Galaxy Tab S6 の場合、最適化されたシーン内での適切なドローコールの数はおよそ 700 回であり、ローエンドなハードウェアの場合は 500 回未満になります。HMI 向けのプロジェクトでは非常に特有または複雑なマテリアルを使用する傾向にあるため、Galaxy Tab S6 の場合は 100 回のドローコールが適切と言えますが、可能であれば 50 回未満に抑えることが理想的と言えます。
ドローコールの数を出力するには、 Stat RHI コンソール コマンドを使用します。
ドローコールの数は、PIE モードかデバイス上であるかどうかによって異なることに注意してください。|
メッシュの数を削減する
ドローコールの数を減らすための最も簡単な方法は、ワールド内の固有のメッシュを削減する方法です。メッシュを削減するには、Unreal へのインポート前に Maya、3DSMax、Blender などのデジタル コンテンツ制作 (DCC) ツールセットを使用して、できる限り多くのオブジェクトを 1 つのメッシュに組み合わせます。
マテリアル ID の数を削減する
メッシュ上の固有マテリアルの数を削減するにはいくつかの方法があります。
最もシンプルなのは、 Substance Painter など、複数のマテリアルを同じテクスチャに統合するプログラムを使用する方法です。このようなプログラムを使用することで、非常にシンプルな Unreal マテリアルに含まれる膨大な数のマテリアル タイプを利用できるようになり、これらをテクスチャのシンプルな入力を受け入れる マテリアル インスタンス の基礎として使用できるようになります。こうすることでマテリアルの命令数を減らすこともでき、パフォーマンスもさらに高まります。
拡大表示するには画像をクリック
もう一つの方法は マスキング を使ったよりプロシージャルなアプローチです。マテリアルでは、カラーやラフネス、メタリックの品質など、サーフェスの特定の性質を示すことができます。メッシュのさまざまなパーツに対して異なるマテリアルを使用するのではなく、マスクを使ってメッシュの UV のパーツを分離し、各セクションに異なる設定を適用できます。基本的なマスクは白黒のテクスチャを使って作成できますが、 頂点カラー を使用したほうが効率的です。
下の図では、さまざまなマテリアル タイプの定義に頂点カラーを使用しており、マテリアルではこれらのパーツの外観に個別に影響を及ぼすパラメータを定義しています。頂点カラーによるマスキングではテクスチャの解像度に左右されないため、分離をよりうまく行うことのできる効率的な方法と言えます。
さまざまなマテリアル タイプを分けるために頂点カラーを使用しているマテリアル。
マテリアル
マテリアルの複雑度 によってレンダリングにおけるピクセル コストが増加することがあります。各ピクセルに対する命令数が増えると、レンダリング時に最終的な値を算出するための時間がより多くかかります。不透明型のマテリアルは最もコストがかからないものではありますが、実際にはシェーディング モデルまたはベース シェーダ コードに応じて大幅に変わります。
マテリアルの命令数を確認するには、 マテリアル エディタ の [Stats (統計情報)] ウィンドウに示される計測値を参照してください。
命令数を表示する統計情報。拡大表示するには画像をクリック。
命令数は、マテリアル内の演算関数の数によっても変わります。レンダリングするマテリアルに含まれるノード数が多いほど負荷も高くなります。また、演算にはより多くの負荷がかかるものもあります。複雑なマテリアルをビルドする際は、できるだけ命令数を少なく抑えてください。
透明 および 半透明 のマテリアルは、いずれも最も負荷のかかるマテリアル タイプです。透過処理における個別のレイヤーにはピクセルごとに高い負荷がかかり、透明性の複数のレイヤーをスタックしてレンダリングする際には多大な負荷となります。これは「 オーバードロー 」として知られています。
透明性に関連する問題を示す例として車のヘッドライトとテールランプがあります。多くの場合は、マテリアルの複雑度を抑えるために手描きのテクスチャ マップを使用します。平坦なテクスチャを使っている場合でも、複雑な形状と深度をうまく描画することができます。
テクスチャ解像度を最適化する
高解像度のテクスチャを使用すると、デバイスとデバイスのテクスチャ メモリに保存するために大量の容量が必要になります。テクスチャが大きいと、それに伴ってレンダリング処理するピクセルの数が増えます。忠実度は高まりますが、デバイスの画面解像度とテクスチャの視野角に応じて、テクスチャ サイズに対する効果は収穫逓減的に低下します。可能な限り小さなテクスチャを使って期待どおりの忠実度を実現することが重要です。
テクスチャ関連のニーズを明確にするには、まずモデルの表示に使用する カメラ位置 と 視野角 (FOV) を最終化する必要があります。こうすることで、すべてのメッシュとマテリアルのスクリーン空間を判断しやすくなります。
カメラ位置を決定したら、次に特殊なデバッグ テクスチャを使ってさまざまなマテリアルに使用するテクスチャ解像度を判断します。このデバッグ テクスチャでは ミップマップ のビヘイビアを利用し、各ミップマップにさまざまなカラーを適用して、それぞれのコンポーネントに必要な解像度を判断します。これによって、マテリアルが使用するミップと使用すべきテクスチャ解像度を特定しやすくなります。
含まれるテクスチャをライティングなしマテリアルのエミッシブ チャンネルに接続し、そのマテリアルをメッシュに適用します。このメッシュを適切な距離のカメラ位置から見ると、そのカラー コーディングから、エンジンでのレンダリングで使用しているミップ レベルを判断することができます。表示可能な最高レベルは、法線マップおよびアンビエント オクルージョン マップのネイティブのテクスチャ サイズになります。
パッケージ サイズと起動時間
アプリケーションとそのアセットをパッケージ化する際には、ディスク上のパッケージ サイズとランタイム起動時のパフォーマンスとの間にトレードオフが生じます。
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 (プリミティブ統計)] では、三角ポリゴンの数、メモリ消費量、カウントなどの情報が表示されます。
プリミティブ統計を表示する統計ウィンドウ
ここに表示される他のデータには、テクスチャの使用量やスタティック メッシュのライティング情報などがあります。[Statistics] ウィンドウでは、アセットを最も使用量の大きい順などで並べ替えることができます。[Cooker Stats (クッカー統計)] では最後のパッケージ化プロセス時にクックされたすべてのアセットを表示することができ、これも非常に便利なリストです。
メモリ レポート
ここまでで説明したとおり、統計とサイズ マップの各ツールでは Unreal Editor 内でファイルのデータ フットプリントを表示できますが、ターゲット デバイスで実行されるアプリケーションのインストールから Memreport -full コンソール コマンドを使用することもできます。このコマンドでは、デバイスの圧縮設定を適用済みの正確な詳しいファイル サイズが表示されます。
アプリを開発コンフィギュレーションでビルドしてデバイスにロードしたら、コンソール ウィンドウを開いてこのコマンドを入力してください。このメモリ情報はデバイス上のプロジェクト ディレクトリに保存されます。通常は「Game/[YourApp]/[YourApp]/Saved/Profiling/Memreports/」ですが、実際の環境によって異なる場合もあります。
.memreport ファイルは、ほとんどのテキスト エディタで読み取り可能なテキスト ファイルです。テキストの冒頭には割り当てられたメモリとプール サイズの情報が含まれており、それ以外は、ロードされたレベル、RHI 統計情報、レンダリング ターゲット、シーンの情報などに関する記録が記載されています。これらはクック処理とパッケージ化プロセス後の実際のデータを示すものであるため、デベロッパーにとっては非常に有益な情報です。
「 Listing all textures 」で検索すると、アプリケーション内のすべてのテクスチャと、そのテクスチャ タイプ、グループ、サイズ、メモリ フットプリントに関する詳細な情報を含むリストを確認できます。このリストではメモリ サイズの大きなテクスチャから降順で並べられています。このリストを利用すれば、どのテクスチャが最も多くのメモリを消費しているかを素早く簡単に確認できます。
起動時間を分析する
起動時間に影響を及ぼす要素には次のようなものがあります。
-
初期アセットのロードと圧縮解除にかかる時間の長さ
-
アプリケーションの全体的なサイズ
-
ユーザーのインストールで有効にする必要のあるプラグイン
-
解析する必要のある文字列データの量
-
ユーザーのデバイス上のメモリ割り当てまたは断片化
アプリケーションの起動時間を解析するツールにはさまざまなものがありますが、パフォーマンス データをターゲット デバイスからリモートでプロファイリング可能な Unreal Insights を強く推奨します。このツールセットの詳細については、「 Unreal Insights 」の各セクションを参照してください。