レベル最適化ガイド

ドキュメントの概要: レベルコンテンツの最適化ガイド。

ドキュメントの変更ログ: 作成者 Daniel Vogel 。管理者 Richard Nalezynski^? 。

概要

UnrealEngine3 で、ライトとオブジェクト間での相互関係は、レベルをレンダリングするため必要な CPU と GPU 作動の大部分を担っています。レベルを最適化時、どうリットするか検証することから始めるのが一番よいでしょう。

また、以下も確認してみましょう。 https://udn.epicgames.com/Three/MasteringUnrealLevelOptimizationJP

CPU オーバーヘッド

CPU 側から見て最も負荷がかかる部分の一つは、何をレンダリングするかを決める部分です。これについては、その後に起きるレンダラーの変化に対して静的オブジェクトを最適化する必要があります。もう一つは、状態変化によるドライバのオーバーヘッドです。後者の場合、PC 上において短期間における最適化は無理ですが、幸運にもゲーム機器では制限要因にはなりません。ただし、ライト環境のコスト削減のために使用できる設定がいくつかあります。

以下に、ライト環境の設定とそれらを使用する場面を、最もコスト高 (ゲームスレッド上で) の設定から順番に示します。

1) bEnabled=True, bDynamic=True (デフォルト)

この設定は必要な場合のみ使用します。 InvisibleUpdateTime と MinTimeBetweenFullUpdates に基づいてライト環境を更新します。この設定のオブジェクトが 50 以上アクティブ状態で存在することは、いかなる場合にも望ましくありません。可視オブジェクトの場合、プレーヤーから近い距離にある場合か、または移動中にビジビリティチェックを実行します。

2) bEnabled=True, bDynamic=False, bForceNonCompositeDynamicLights=True

この設定は経済的で、最初のティック時に環境を更新するだけで、その後は更新しません。動的ライトの影響を受けるようにするには bForceNonCompositeDynamicLights が必要で、これによるゲームスレッドのオーバーヘッドはほどんとありません。多数存在しても大丈夫で、唯一のコスト (最初のティックの後) は動的ライトのライン チェックです (このチェックはオーナーが可視状態にある場合のみ)。正しいライティングを維持しながら回転できるので、事前計算したシャドウを使用するよりよく見えます。フラクチャー メッシュ、GDO で使用します。

3) bEnabled=False, bUsePrecomputedShadows (プリミティブ コンポーネント上)=True (さらに、動的チャネルから取り出して、静的ライティングチャネルに入れる必要がある)

こららはライトマップ化されるので、レンダリング負荷が小さく、ゲームスレッドのオーバーヘッドは実質上ないはずです (ただし、UDynamicLightEnvironmentComponent::Tick 関数が引き続き呼び出される場合は例外)。移動中には正しく見えません。

さらに、コンソールで 'SHOWLIGHTENVS' と入力すると、そのフレームでティックされるすべての環境のリストを得ることができます。 UnrealConsole に次のような出力結果が表示されます。

Log: LE: SP_MyMap_01_S.TheWorld:PersistentLevel.InterpActor_12.DynamicLightEnvironmentComponent_231 No_Detailed_Info_Specified 1 Log: LE: SP_MyMap_01_S.TheWorld:PersistentLevel.InterpActor_55.DynamicLightEnvironmentComponent_232 No_Detailed_Info_Specified 0 Log: LE: SP_MyMap_01_S.TheWorld:PersistentLevel.InterpActor_14.DynamicLightEnvironmentComponent_432 No_Detailed_Info_Specified 1 ...

行末の '1' は、bDynamic が TRUE に設定されていることを意味します。

レベル内のすべての動的ライトを取得できるもうひとつのコマンドは、'GETALL' コマンドです。 例えば、 'GETALL DynamicLightEnvironmentComponent bDynamic' と入力すると、すべての DynamicLightEnvironmentComponent と bDynamic フラグが表示されます。

'SHOWLIGHTENVS' と 'GETALL' の違いは、 'SHOWLIGHTENVS' がそのフレームで 'TICKED' されるあらゆる環境を表示するのに対し、 'GETALL' はティックの有無に関わらずすべての環境を表示する点にあります。

もうひとつの主な CPU コストは、ドライバのステート変更に関連するオーバーヘッドです。当社のマルチスレッド レンダラーを使用する場合は、通常これはシングル CPU システム上の 1 要因に過ぎません。

STAT SCENERENDERING コンソールコマンドは、 occluded primitives (オクルード (隠蔽) されたプリミティブ)、 visible static mesh elements (可視できる静的メッシュ要素)、 visible dynamic primitives (可視できる動的プリミティブ)、を一覧表示し、各フレームでレンダリングされるプリミティブの個数を判定するのに使用できます。

PC 上では、ドライバによる CPU オーバーヘッドまたは GPU 消費時間を把握するのは非常に難しく、最近の GPU の非同期性のおかげで、本来なら GPU が処理を終了するまで待機するはずの呼び出しが、一見ランダムに登場し、普通以上の時間を拘束する場合がよくあります。 エンジンはフレーム単位で GPU と同期をとり、 STAT THREADING でスレッドあたりの待機時間をレポートします。 Game thread idle time (ゲームスレッドのアイドル時間) が高い場合はレンダリングが遅く、 Rendering thread idle time (レンダリングスレッドのアイドル時間) が高い場合はゲームプレイコードがボトルネックになっていることを意味します。ゲームスレッドのアイドル時間数が高い場合には、別の解像度で試してみて、レンダリングスレッドが CPU または GPU のどちらで処理されるかを判断することができます。

GPU オーバーヘッド

GPU 側から見て最も負荷がかかる部分の一つは、何をレンダリングするかを決める部分です。これについては、その後に起きるレンダラーの変化に対して静的オブジェクトを最適化する必要があります。もう一つは、状態変化によるドライバのオーバーヘッドです。後者の場合、PC 上において短期間における最適化は無理ですが、幸運にもゲーム機器では制限要因にはなりません。

レンダリング関係のオーバーヘッドを調べる際に STAT VISIBILITY をまずチェックするとよいでしょう。また、STAT OCTREE および/あるいは STAT COLLISION では詳細を掘り下げて調べることができます。STAT GAME はゲームプレーのオーバーヘッドを知るために役立つデータのコレクションで、特にランタイムのマテリアル蓄積など、フレームレートの急上昇を起こす一般的な原因の統計データも集められています。

GPU の動作は非同期的であるため、ドライバー別の CPU オーバーヘッドまたは PC で費やされる GPU 時間を特定するのはかなり困難です。これにより、ランダムコールがさらに多くの GPU 作業を終えるのを待つことになり、通常よりも長い時間がかかることになります。エンジンは GPU の各フレームを同期して、同期にかかった時間を STAT D3D に表示します。ただし、特定の 1 シーンがどれほど GPU に依存しているかを測るために最適の方法は、様々な解像度でそのシーンをレンダリングするか、あるいはコンソール特定のツールを使用して各ステージ別の負荷を調べることです。 解像度が高い場合 (例えば通称「720P」の 1280x720 など)、30ms のフレーム時間ではハイエンド GPU でもボトルネックになる可能性があります。このような高解像度によるリット (Lit) 状態の動的シーンでは、主な負荷はシャドウバッファの使用から発生します。これは、シャドウエッジをにじませるのに非常に負荷の大きいシェーダーを使用するためです。視覚的な忠実度に関してさまざまなトレードオフを行うことで、これを最適化するアプローチがいくつかあります。また、解像度に関わらず、ポストプロセスは常にオーバーヘッドであり、最適化の対象です。

コンソール専用ツールまたは PC の nvPerfHUD を使用すると、何に時間を取られているのか、およびその理由に関して詳細な情報を得ることができます。しかし、全般的な最適化に関しては、作成するレベルが以下のガイドラインに準拠していることを確認するだけでも、努力に見合うだけの最大効果が得られるのが普通です。

Stats

通常、レベル内の各種のアセットタイプについてstats コマンドを使用できます。エンジンでサポートされている stat コマンドの詳細な説明は、Stats コマンド解説 ページを参照してください。

ライトマップ

概要

ライトマップを使用すると、CPU、GPU 双方の負荷を軽減するという利点が得られます。すべてのライティング情報がライトマップに記録されているため、エンジン側はライトに関する処理から解放され、CPU 側で処理すべきライトとオブジェクトの相互作用が少なくなります。GPU 側においては、オブジェクトを複数のパスでレンダリングする必要がありません。また、ライトマップ パスをエミッシブ パスに組み込むことができるため、パスの数と、ステータス変更によるオーバーヘッドが軽減されます。

VIEWMODE LIGHTCOMPLEXITY と、これに関連付けられた [Editor] ボタンを使って、オブジェクトに作用する (ライトマップにない) ライトの数を視覚的に理解することができます。カラースキームは以下のとおりです。

ライト	メッシュの色
0	(R=0,G=0,B=0,A=1)
1	(R=0,G=255,B=0,A=1)
2	(R=63,G=191,B=0,A=1)
3	(R=127,G=127,B=0,A=1)
4	(R=191,G=63,B=0,A=1)
5	(R=255,G=0,B=0,A=1)

このイメージでは、シーンのほぼ全体がライトマップ化されていますが (ブラック)、1 つの動的ライトが追加され、レベルをグリーンで現しています。

使用方法

総合的に見て、ライトマップのパフォーマンスは極めて優れています。ライトマップを呼出して使用するには 2 つの方法があり、ひとつはライトの UseDirectLightMap （ダイレクトライトマップ使用） の項を「有効」に設定する方法、もうひとつはプリミティブ（テレイン、 StaticMesh 、 SkeletalMesh など）の bForceDirectLightMap （強制ダイレクトライトマップ） の項を「有効」に設定する方法です。あらかじめ演算した他のシャドウイング情報と同じく、ライトマップは静止オブジェクトについてのみ利用可能です。詳細は、 ライティング参照 をご参照下さい。

一方、ライトマップでは 1 つのライトがライトマップに及ぼす影響をエンジン側で知り得ないところが欠点といえます。というのも、ダイナミックなシャドウイングが不可能だからです。言い換えれば、あるライトがライトマップの一部である場合、ダイナミック オブジェクトはそのライトによる影を静的メッシュに投影できないということです。

こうした制限により、プレーヤが影を投影すべきオブジェクトにつき、有効なライトを少なくとも 1 つ設置することになります。こうしたプレーヤの陰影効果を提供するのがこのライトの役割です。 bForceDirectLightMap （強制ダイレクトライトマップ） を設定しなければ、プリミティブ毎に平均 1 つ以上のライトマップ以外のライト効果を使う必要があり、その顕著な例が半径の大きなポイントライトや指向性ライトを利用する場合です。 bForceDirectLightMap （強制ダイレクトライトマップ） のフラグはこうした状況の唯一の対処法です。このフラグは、プレーヤ（もしくは他のいかなるダイナミック オブジェクト）の影を投影したくないオブジェクトに設定して下さい。

LightMaps (ライトマップ) vs. 頂点ライティング

コスト比較については、付属のスプレッドシートLightMapVSVertexLightingCosts.xlsx 参照してください。 また、頂点ライティングとライトマップデータはメモリ的に非常に異なる方法で処理される点にも注意してください。すべてのライトマップ データはストリーミングテクスチャ プールに格納され、テクスチャは実際のメモリのフットプリントに加算されません。これに対して、頂点ライティングは常にシステム メモリに格納されるので、レベルのロード時には定量のメモリオーバーヘッドになります。 'Stat memory' は、頂点ライティングフィールドを報告しますが、この数字は出来るだけ低い方が望ましく、メモリの問題がある場合に最初にできることは、可能な範囲でライトマップを使用することです。 フラクチャー メッシュを使用する場合は、このメッシュによってポリゴン数が極めて増大し、そのため頂点ライティングがメモリをかなり消費してしまうので、この措置が特に当てはまります。

ダイナミックシャドウ

概要

パフォーマンスに関する問題でもう 1 つ考えられる要因として、ダイナミック シャドウイングがあります。ダイナミック シャドウイングがパフォーマンスに影響を与えるかどうかを検査するには、 SHOW DYNAMICSHADOWS をコンソール コマンドでトグルしてオフにすることです。このコマンドにあるキーをバインドしておくと、キーが押されている間はダイナミック シャドウの表示がオフになり、キーを離すと再び有効になり便利です。これはコンソールから設定できます。例えば、 SETBIND F SHOW DYNAMICSHADOWS | ONRELEASE SHOW DYNAMICSHADOWS となります。

ダイナミックシャドウのパフォーマンス制限事項

オブジェクトがポイントまたはスポットライトへ近づき、シャドウ円錐台の FOV が 90 度を越える場合、レンダラーは、シャドウをキューブマップへ切り替えます。これによって著しいパフォーマンスの低下が起こります。ライトがオブジェクトの境界ボックスに入った場合にも同じことが当てはまります。

シャドウバッファの GPU 負荷は、シャドウ円錐台のサイズに正比例します。これは、シャドウバッファを使用している近くのキャラクターの負荷が、遠くのキャラクターよりも大きいことを意味します。これは、ダイナミックシャドウを投げ掛けている大きなオブジェクトの負荷の方が小さなオブジェクトよりも大きいことを意味します。シャドウの最適化に関する他の情報については、シャドウイング参照 ページと Modulated（モジュレート）シャドウ ページを参照してください。

静的メッシュと他のプリミティブ

概要

パフォーマンス問題の主な根源は静的メッシュにあります。通常、1、2 度しか使わない静的メッシュは、頻繁に使用する同様のメッシュに置換することをお勧めします。スカイボックスにはメッシュを出来るだけ使用しないようにして、頂点ライティングとライトマップ ライティングの間で適度なトレードオフを実施するようにします。さらに、Primitive Stats (プリミティブ統計) ブラウザで bang fot the buck (努力に見合うだけの) 最適化のうち最も効果の高いものを探します (インスタンスあたりの三角形の数でソートします)。

Primitives Stats ブラウザ

以下は、Primitive Stats ブラウザ (旧称 Static Mesh Stats ブラウザ) の各列の説明です。

• Type - リソースタイプ。骨格メッシュ、静的メッシュ、テレイン、または BSP (モデル) のいずれか。
• Count - レベル内の当該メッシュのインスタンス数。
• Triangles - インスタンスあたりの三角形の数。
• Resource Size - KByte 単位で "view resource usage" (リソース使用の表示) コマンドによってレポートされるリソースサイズ。このデータは静的/骨格メッシュの場合のみ重要。
• Lights (avg LM/ other/ total) - ライトマップの平均ライト数 (LM)、ライトマップにないライト (other)、および各インスタンスに作用するライト数合計。
• Obj/ Light cost - オブジェクト/ライトの相互作用のコスト。この数字は、この静的メッシュがライティング目的でレンダリングされる回数を示し、ライトマップにないライトの数と、全インスタンスの合計セクションの数との積になります。ライトマップはエミッシブ パスの一部としてレンダリングされ、そのためコスト "フリー" であることから、この数字には含まれません。
• Triangle cost - ライティング目的でレンダリングする必要がある三角形の数。Z-プリパス、エミッシブ、ライトマップはライト数に関係なく常にオーバーヘッドであるため、この数字から除外されています。
• Lightmap - ライトマップデータが使用するメモリの量。
• Shadowmap - シャドウマップデータが使用するメモリの量。
• LM Res - インスタンスあたりの平均のライトマップ解像度。
• Sections - このメッシュに含まれるセクションの数。
• Radius (min/max/avg) - メッシュの各インスタンスの境界ボックスの最小/最大/平均半径。

マテリアル

シーン内のマテリアルの複雑度が、シーンの GPU オーバーヘッドに大きな影響を及ぼす場合があります。使用する動的ライトの数が増えると、高価なマテリアルのコストがさらに上がります。 エディタでは、次図のような Shader Complexity (シェーダーの複雑度) ビューモードを提供しています。

淡いグリーンはマテリアルの負荷が小さく、濃くなるほどマテリアルの負荷が大きいか、または複数の動的ライトの影響があることを示しています。この場合、シェーダーの複雑度を正確に表示するには、レベルのライティングをリビルトしなければならない点に注意してください。 マテリアルの最適化のヒント:

• Dependent Texture (従属テクスチャ) の読み取り量を出来るだけ制限します。これは、 BumpOffset などテクスチャの UV を編集することになります。
• Material Instancing (マテリアルのインスタンス化) を使用し、負荷の大きいエフェクトには StaticSwitchParameters を使ってオン/オフをトグルできるようにして、パフォーマンスのトレードオフを行います。
• スペキュラー (反射) 性がほとんどないマテリアルからスペキュラーを除外することを検討します。これにより多量のピクセル シェーダーインストラクションが除外されますが、ほとんどの場合は目立ちません。
• 各マテリアルのテクスチャルックアップ回数を出来るだけ少なくします。ルックアップ回数が多いほど、必要なテクスチャを GPU が取得するのにかかる時間が長くなります。

Decal

レベルに配置した静的 Decal は、適切に処理しなければパフォーマンスをたちまちのうちに食いつぶす恐れがあります。放置しておくと、必要のない余分なメッシュに割り付けられ、その結果レンダリングを要するセクションの量が急増します。これらが必要な静的メッシュ/BSP のみに作用するように設定することで、セクション数を大幅に削減できます。

Decal および Decal System の使用法に関する詳細については、Controlling Receiving Surfaces （サーフェス受け取りの制御）に関するDecalシステム参照のページを参照してください。

Skyboxes（スカイボックス）

概要

通常スカイボックスには、その境界がワールドの大半を網羅するようなボックスや球などの非常に大きなオブジェクトが含まれています。これにはいくつかの顕著な副作用があります。一つめは、近くのクリッピング プレーンと交差するオブジェクトについて、たとえメッシュのピクセルが全く見えない場合でも、咬合のクエリーを行わず、常にレンダリングしてしまうことです。これは通常、ライトの影響を受けないアンリット ドームにとっては大きな問題ではありません。これはエンジンが早い段階でハードウェアZ リジェクションの効果を最大限に引き出すために、まずデプス パスをレンダリングするからです。スカイボックスが沢山のライトで照明されている場合は、その状況変化やオーバーヘッドの増加に伴って何らかの剰余が関連する場合もあります。

スカイボックスの境界ボックスはワールド全体であることに注意してください。つまり、ライティングチャンネルまたは手動による除外のいずれかによって明示的に除外されない限り、一つ一つのライトがスカイボックスに影響を与えるということです。このことから、 bForceDirectLightMap を TRUE 、 bAcceptsDynamicLights を FALSE に設定するべき最有力候補は、スカイボックスアクタです。この設定によりレベル内のダイナミックライト一つ一つが再レンダリングされないようになります(たとえば火花など)。スカイボックス内の光が当たっていない移動/回転オブジェクトの場合、 bAcceptsLights を FALSE に設定し、マテリアルに光が当たっているかどうかに関わらず、CPU 側の作業負担を回避することが最も良い方法です。

スカイボックスでの移動の Unlit やオブジェクトの回転には、マテリアルがリットしているかいないに関係なく行われる必要がある CPU サイドで作動するのを避けるため、 bAcceptsLights を FALSE に設定することが最善の方法です。

まとめ

以下は、スカイボックスの設定に関するまとめです。

• 衝突を無効にする
• 光が当たっていないオブジェクトについては bAcceptsLights を FALSE に設定する
• その他のオブジェクトについては bAcceptsDynamicLights を FALSE に設定する
• 必要に応じてスカイボックス ライティング チャンネルを使用した上で、スカイボックス オブジェクトにライトマップを強制するか、またはライトにライトマップを強制するよう設定する
• 必要な部分でスカイボックスの CastShadow を無効にし、 bCastDynamicShadow を無効にする

共通プロパティの説明

プリミティブ コンポーネント

• CastShadow は、プリミティブ コンポーネントが影を投げ掛けるかどうかを制御します。現在、このフラグと bCastDynamicSahdow の双方が有効になっていなければ、ダイナミック プリミティブに StaticMesh クトの影は写りません。
• bCastDynamicShadow は、たとえばプリミティブがライトとダイナミック オブジェクトの間にある場合など、事前に演算されないシャドウイングにおいて、プリミティブがシャドウを投げ掛けるかどうかを制御します。このフラグは CastShadow が TRUE の場合にのみ使用されます。現在、このフラグと CastShadow の双方が有効になっていなければ、ダイナミック プリミティブに静的オブジェクトの影は写りません。
• ライトがライトマップを利用しないよう設定されていても、 bForceDirectLightMap は、プリミティブに影響を与えるすべての静的ライトについてライトマップの使用を強制します。つまり、プリミティブには静的ライトを遮るダイナミック オブジェクトの影は写りません。ダイナミックライトの場合に、正しい影が映ります。
• bAcceptsLights は、プリミティブのライト認識の設定を行います。優れた最適化方法で、ライティングが不要なオブジェクトには「無効」と設定します。
• bAcceptsDynamicLights は、ダイナミックライトによってオブジェクトが影響されるかどうかを制御します。
• LightingChannels は、どのライトがこのプリミティブに影響を与えるかを定義します。

ライト コンポーネント

• CastShadows は、ライトが影を投げ掛けるかどうかを制御します。
• CastStaticShadows は、静的シャドウイングを受けるオブジェクトの影が、このライトによってできるかどうかを制御します。
• CastDynamicShadows は、静的シャドウイングを受けることができないオブジェクトの影が、このライトによってできるかどうかを制御します。
• bForceDynamicLight は、キューブマップについて起きる可能性のある問題を避けるためにシャドウボリューム/ステンシルシャドウの使用を強制します。また、静的シャドウイングでにメモリが使用されることを回避します。
• UseDirectLightMap は、このライトにライトマップを利用するかどうかを決定します。
• LightingChannels は、どのプリミティブにこのライトが影響を与えることができるかを定義します。

その他

Unlit translucency (透明度のアンリット)

複雑なマテリアルによる過度のオーバードロー (無駄な重なり) がある場合、Unlit translucency プロパティの設定によってパフォーマンスに深刻な影響が出る恐れがあります。パフォーマンスへの影響を簡単に測定するには、コンソールでこのプロパティの使用を SHOW UNLITTRANSLUCENCY を使って切り替えるか、またはエディタのビューポートで対応するビューモードフラグを選択解除します。

ヒント:

• SHOW UNLITTRANSLUCENCY でターゲットプラットフォームのパフォーマンスをチェックする。
• 可視化するには VIEWMODE SHADERCOMPLEXITY を使用する。
• レイヤー化を避ける (特に光円錐などの場合)。
• 可能な場合は CullingDistance を利用する。

BSP

ライティング関連のフラグ

BSP は、主に場所に基づいてチャンクに分割されます。これは、個々の BSP セグメント (モデルコンポーネント) が適度な大きさで、複数個のライトを受けることを意味します。ライト/BSP の相互作用を制御する方法のひとつは、BSP ライティング チャネルと、Accepts Light (ライトを認識)、Accepts Dynamic Light (動的ライトを認識)、および Force Lightmap (ライトマップを強制) のサーフェス オプションを使用することです。これらのオプション変更は、BSP がリビルドされると反映され、対応するフラグが BSP チャンクにプロパゲートされ、それらのオプションに基づいてチャンクが部分的にが作成されます。これらはプリミティブコンポーネントの bAcceptsLights 、 bAcceptsDynamicLights および bForceDirectLightMap に直接対応しています。BSP が巧みに使用されたレベルでこれらのフラグを使用すると、レベルのパフォーマンスが大幅に向上します。

'Clean BSP materials' ツールの実行

エディタの CLEANBSPMATERIALS 実行コマンド (UnrealEd の [Tools] メニューの [Clean BSP Materials] (BSP マテリアルを消去) オプションからアクセスします) を実行すると、最終的な BSP に存在しないフェイスのマテリアル参照をブラシが保持していれば、それらを一掃します。このような参照には、例えば、additive (加算的) 空間に完全に内包された 'add' ブラシ、'cospatial' (共有空間) ポリゴン (フェイスを共有する 2 つの隣接する立方体) などが含まれます。

この操作は、レベルの BSP が完成した後でのみ実行するようにしてください。隠れているフェイスのマテリアル参照が消去されるので、後から BSP を編集して非表示のブラシが見えるようにした場合に、それらのフェイスにマテリアルの割り当てを再度適用することになります。

この機能は QA_APPROVED_BUILD_JUN_2007 (2007 年 6 月 QA 承認ビルド) に搭載されました。

'RemoveSurfaceMaterial' の使用

EngineMaterials パッケージには RemoveSurfaceMaterial という特別なブラシが含まれていますが、プレーヤーがまったく見ることのないすべての BSP サーフェスにこれを適用するようにしてください。このマテリアルのマークを付けた BSP サーフェスでは BSP メッシュを生成する三角形がレンダリングされず、静的ライティングを受け取りません (つまり、関連ライトマップの資産を消費しません)。

RemoveSurfaceMaterial のマークが付いたサーフェスは、エディタと PIE では見ることができるので、デザイナーはここでサーフェスの視認性をテストし、必要に応じてマテリアルを元の状態に戻すことができます。ただし、エディタ以外の場所でゲームを実行するときには見えません。

この機能は QA_APPROVED_BUILD_JUN_2007 (2007 年 6 月 QA 承認ビルド) に搭載されました。

レベル

レベルの最適化に関するヒントをいくつか紹介します。

• スカイボックスがアンリット（Unlit）状態で、Decal とライトを受けず、衝突が発生しないことを確認します。
• Primitive Stats ブラウザで、count（カウント数）と instanced triangle（インスタンスされたトライアングル）を基準にソートします。
  • あまり使用されないメッシュのインスタンスを除外/削減します。
  • インスタンスあたりの三角形数が高い場合はできるだけ簡単なメッシュを使用するようにします (例えば、2000 個の三角形を 100 回使用する場合、Triangle 列が 200 になるようにします)。
• 衝突ビューモードを使い、不要な衝突を無効にします。
• ゲームを再生して何が見えるか確認します。エディタの視点はプレーヤーの移動地点や目の高さなどと一致しないので、普通にゲームプレイするときにはまったく見えないメッシュが追加されていることがよくあります。
• ワールドの下、ジオメトリの内側などにメッシュが隠れていないことを確認します。
• 非可視状態にあるすべての BSP サーフェスは、ライティングも受け取らないように設定されていることを確認します。
• 見えない BSP サーフェスにはデフォルトのテクスチャを設定します。
• VIEWMODE LIGHTCOMPLEXITY を使用して、動的ライトがないレベルがブラックであることを確認します。
  • 小さな半径のトグル可能ライトのみ使用します。
  • トグル可能な平行 (directional) ライトを使用しないでください。
• 静的メッシュと静的メッシュセクションの数を控えめに抑えます。

Cull Distance ボリューム

Unreal Engine では、これまで距離ベースでオブジェクトのカリング (不要なオブジェクトの除去) に CullDistance (カリング距離) が使用されていました。多数のオブジェクトをカリングできる場合は、可視要素の数やオクルージョン時間が削減され、パフォーマンスが大きく飛躍します。 時間をかけて CullDistance を手動で設定する代わりに、当社ではこれを CullDistanceVolumes に基づいて自動的に割り当てています。CullDistanceVolume とはボリュームの一種で、このアクタには配列があり、配列に追加される各フィールドに CullDistance と Size 設定があります。 レベルを保存するときに、エディタはレベル内の各オブジェクトのバウンディング球の直径を調べて、その値に最も近い Size カテゴリーに基づいてカリング距離を自動的にを割り当てます。 culldistance ボリュームを追加するには、レベル全体を包囲する大きさのビルダブラシを使い、[Add Volume] (ボリュームを追加) ボタンを右クリックしてリストから [CullDistanceVolumeJP] を選択します。

レベルを保存するときに、エディタはレベル内の各オブジェクトのバウンディング球の直径を調べて、その値に最も近い Size カテゴリーに基づいてカリング距離を自動的にを割り当てます。 culldistance ボリュームの設定では、まず一番小さいオブジェクトの CullDistance を作成し、小さいオブジェクトがほぼ見え隠れするようになるまでそのフィールドの距離/サイズを調整します。次に、その次に大きいものを作成し (culldistance を少し大きくして)、自動的にカリングを実行したい一番大きなメッシュまでこの作業を繰り返します。CullDistance が 0 の場合、カリングされないことを意味します。上図のサンプルイメージでは、10,000 ユニット以上のメッシュは CullDistanceVolume を使用していません。 カリング距離の調整は、明らかなポッピング (飛び出し) が見えなくなるまで行う必要があります。 メッシュを CullDistanceVolumes の対象から外すには、次のフラグを設定します。 StaticMeshComponent.Rendering.bAllowCullDistanceVolume=False 編集不可能フィールド CachedCullDistance には、Cull Distance ボリュームからメッシュに現在割り当てられているカリング距離が表示されます。

詳細については Visibility Culling ページを参照してください。

テレイン

テレインの最適化に関するヒントをいくつか紹介します。

• パッチ バウンダリのビューモードを使用する。
• ワイヤーフレームを使ってテッセレーションの正常性テストを行います。
• 詳細については コード用テレイン^? ページを参照してください。

オーディオ

オーディオの最適化に関するヒントをいくつか紹介します。

• 絶対に必要な場合を除いて、複数のミュージックトラックが使用されていないことを確認します。ミュージックトラックを専用ストリーミング マップに保管して、必要なときにストリームイン/アウトされるようにするのは良いアイデアです (これはパフォーマンスに影響しませんが、レベルの全体的なコストに影響します)。
• STAT AUDIO 、 STAT MEMORY でコストを確認します。
• LISTSOUNDS で現在ロードされているサウンドを確認します。ここには、グループ単位で格納されているサウンドウェーブが表示されるので、どのサウンドタイプがメモリを最も消費しているか分かります。
• LISTWAVES には、現在再生中のサウンドが表示されます (PC のみ)。
• LISTAUDIOCOMPONENTS には、現在 検討中の サウンドが表示されます。

テクスチャ

Unreal Engine 3 ではテクスチャストリーミングプールを使用していますが、これは、すべてのストリーミング テクスチャにはメモリフットプリントの総量があからじめ割り当てられていること、大きなテクスチャ、プレーヤーに近い場所のテクスチャのみを最高の解像度でロードするようにエンジンで配慮していることを意味します。しかし、追加するテクスチャの数が多すぎる場合は、全体的にかすんでしまう可能性を残しています。この場合は、テクスチャの使用量を適度なレベルに削減するのが唯一の解決方法です。 テクスチャの最適化に関するヒントをいくつか紹介します。

• STAT STREAMING とストリーミング補正係数を調べます。この数値が 1.0 の場合は心配ありませんが、1.0 より大きい場合はテクスチャがフィットしていなくて、一部がぼやけています。
• LISTTEXTURES で何がロードされているかを確認します。これは、ログに読み込まれたテクスチャのリストを出力します。この情報を Excel にコピーして、[Text to Columns] (テキストファイル) ボタン ([Data] の下) を押し、[Delimited] (区切られたデータ) ->[Comma] (カンマ) -> [Finish] (完了) を押すと自動的に行/列形式に取り込まれます。次に [Sort] (並べ替え) を押して各行を昇順または降順に並べ替えます。
• listtextures の出力内容を Excel にコピーし、[Current Size] 行を降順にソートしてから、データを使ってワーストケースの原因、つまり最もメモリを要するテクスチャの分析を開始します。

パーティクル

パーティクルの最適化に関するヒントをいくつか紹介します。

• 小さなオブジェクトの衝突を無効にします (UT では Enforcer 武器のスパークで衝突を使用していました...)。
• オーバードローを回避します。
• PIX と VIEWMODE SHADERCOMPLEXITY を使用します。
• STAT PARTICLES でパーティクル数を確認します。
• よく登場するエフェクト、または大きなパーティクルにはバウンディングボックスを手動設定します。
• エディタが自動生成した最大アクティブ数が適正値であることを確認します。
• 詳細については、パーティクル システム ページを参照してください。
• MEMORYSPLIT を使用し、現在ロードされている Active なパーティクルデータの量と、Peak としてロード可能なデータ量 (パーティクルに一度に割り当て可能な最大メモリ量) を確認します。

アニメーション

アニメーションの最適化に関するヒントをいくつか紹介します。

• すべてのアニメーションが圧縮されていることを確認します。
  • 圧縮しない理由がある場合は、プログラマーに確認します。
  • 圧縮しない理由はないはずで、見かけが良くないのはバグです。
• 継ぎ合わせたシネマティクスには、ベイクとプルーニングが必要です。
• OBJ LIST CLASS=ANIMSET
• OBJ LIST CLASS=ANIMSEQUENCE
  • 1 つのアニメーションシーケンスをロードすると、セット内のすべてのアニメーションシーケンスがロードされます。

物理

通常、 rigid body collision view (剛体の衝突ビュー) をオンにします (コンソールで SHOW RIGIDBODY を使用できます)。次に、ビークルまたはラグドールが衝突できないオブジェクトの BlockRigidBody を FALSE に設定します。大型の高層構造物の場合は、すべてのメッシュの剛体衝突をオフにして、大きなブロッキングボリュームをその上にかぶせることをお勧めします。

その他の考慮事項

機能前世代の最適化

前世代の PC タイトルでよく行われていた最適化は、同じマテリアルを使用する小さなオブジェクトを大きなオブジェクトにマージする、というものでした。現世代ではオブジェクト/ライトの相互作用の影響が増大しているため、これは推奨されていません。大きなオブジェクトは、より多くのライトと接触し、より多くの動的オブジェクトによるシャドウ生成の対象となります。

ゲームに (エディタ内ではなく) ロードするコンテンツの検証

OBJ LIST CLASS=SKELETALMESH コマンドを実行して、ロードされたビークルと武器のみが使用されることを確認できます。予想に反する結果が得られた場合は、ゲームプレイ プログラマーと話し合ってください。例えば、以前は特定の Kismet アクションが余計なコンテンツを参照するという問題がありました。

その他の役に立つコマンド:

• LISTSOUNDS (オーディオの場合)
• LISTTEXTURES (テクスチャの場合)

analyzereferencedcontent コマンドレットの実行

過剰な数の 凸状 Hull (外殻) を含むメッシュが存在しないことを確認します。また、使用頻度の最も高いメッシュを最適化します。ワーストケースのマテリアル (特に使用回数の多いマテリアル) 問題の原因を最適化します。

https://udn.epicgames.com/Three/CommandletList#analyzereferencedcontent

プラットフォーム固有のデバッグ

出荷予定のプラットフォーム上でパフォーマンスとメモリのテストを実行するのは常に重要なことです。エディタのデバッグツールも深刻な問題の解決に役に立ちますが、出荷する製品のコンテンツを実際に最適化する唯一の方法は、ターゲットプラットフォームの実行状態を分析することです。エンジンでサポートされている stat コマンドの詳細な説明については、Stats コマンド解説 ページを参照してください。

注意すべき点として、メモリも断片化 (システムフラグメントまたは内部エンジンのフラグメント) します。これは、ゲームがメモリをどのように使用するかに応じて、合計使用量の何割かのバッファが必要であることを意味します。

例えば 200 mbs を使用する場合、ゲームがそこまで使い果たすまでの状況に応じて断片化の割合が予想されます。この断片化はゲーム セッションが長くなるほど悪化しますが、直線的には悪化せず、最悪の可能性に達した時点で (おそらく 10% または 20%) で逆になります。 プログラマーに相談してください。

PC

PC テスティングでは、常に最小ターゲット仕様の範囲内に適合する PC 上で統計を集め、すべてのマテリアルフォールバック オプションが適切に機能していることを確認する必要があります。

Playstation 3

現在執筆中。

Xbox 360

devkit を実際に実行し (結果が PC の場合と異なる可能性があるため)、すべてのテクスチャ ストリーミング、メモリおよびパフォーマンス問題や統計を調べることが大切です。 xbox のパフォーマンス問題のデバッグで最も大切なツールは、Microsoft の Performance Investigator for Xbox (PIX) です。

Performance Investigator for Xbox (PIX)

MDSN の PIX documentation を参照してください。

• LightMapVSVertexLightingCosts.xlsx: N 個のインスタンスの場合を考慮して内容を更新