導入

プレイヤーが屋内と屋外エリアの両方を探索する大きなマップに合わせて調整できるようにするために、Enlighten ライトマップを解決する際の詳細度のメカニズムがあります。これはテレイン LODと似ていますが、テレインではないシステムに適用することを意図したものです。テレインシステムに対しては、テレイン LODメカニズムを使用することをお勧めします。

ライトマップ LOD メカニズムの背景にある全般的な思想は、さまざまな解像度で Enlighten システムライトマップを生成し、既定のタイミングでどの解像度を解決およびレンダリングするかをコントロールできるようにすることです。たとえば、以下の図の小屋のモデルを考えてください。プレイヤー (カメラが) 近い場合、高い忠実度で間接光を解決しますが、カメラが離れるにつれて細かな詳細は必要なくなります。

詳細度の低いライトマップピクセルサイズを増加させると、Enlighten ランタイムによって解決されるピクセルが減少します。LOD 0 を解決するには、Enlighten は小屋全体で 4264 ピクセル解決する必要があり、LOD 1 では 2640、LOD 2 では 1400、LOD 4 では 880 に減ります。遠くのオブジェクトで解決する必要があるピクセル数を減らすとマップ全体でより多くの部分を解決でき、その一方で Enligten の割り当て量は維持できます。これにより、幅広い景色がレンダリングされているシーンのパーツで、より滑らかで素早い間接光の収束が得られます。

概要

2 つのジオメトリ (のインスタンス) を含む 1 つの Enlighten のシステムの単純なケースを考えてみましょう。Geom 1 は、床 (Geom 2) の上にあるブロックです。ユーザーが Geom 1 と Geom 2 のためにそれぞれ 3 つの LOD が生成されるよう要求したとしましょう (その方法の詳細は後で説明します)。Geom 1 と Geom 2 は個別にパッキングされます。それぞれが 3 回パッキングされ、パッキングのたびにピクセルサイズが 2 倍に増加します。以下の図をご覧ください。

次の OutputSystem 作成ステップでは、同じ LOD のパッキングされたジオメトリが出力 (パッキングされた) システムの LOD に組み合わされ (そしてリパッキングされ) ます。

システムのすべての LOD バージョンが同じジオメトリ (頂点、面、法線、アルベド UV など) を共有しており、出力ライトマップピクセルサイズとライトマップ UV (チャート) のみが異なることに注意してください。次に、システムにクラスタ (リーフクラスタ、クラスタツリー階層) が作成されます。これは、システムのすべての LOD バージョンで共有されます。すべての LOD でクラスタが同じであるという事実は、実行時に使用されるすべてのクラスタごとのバッファ (入力ライティング、バウンスバッファ、アルベドバッファなど) は、解決された LOD が変わっても有効であり続けることを意味します。

クラスタとダスターの位置は、システムのすべての LOD バージョンで共有されます。ダスターポイントは、各 LOD での位置で個別の UV 座標を持ちます。

Light Transport 作成ステージは、システムのすべての LOD バージョンに対して実行されます。異なる LOD のピクセルから異なるフォームファクターが得られます。最終的なデータセットがコンパイルされ、すべての LOD に個別の RadCore が作成されます。これらの RadCore を使用して、実行時にシステムの特定の LOD バージョンを解決できます。クラスタごとのバッファはすべての LOD 間で共有されるため、LOD の変更の際に入力ライティングを再計算する必要はありません。同様に、前の LOD で使用されていたバウンスとアルベドバッファも再使用できます。既定の LOD でライトマップにアクセスするために必要なライトマップ UV は、パックシステムのパッキングされたインスタンスとパッキングされたジオメトリにアクセスすることで取得できます。

High Level Build System

ライトマップ LOD の生成を有効にするには、XML シーン記述に追加する必要がある特別なマークアップがいくつかあります。このセクションでは、必要なステップとライトマップ LOD が有効な場合のプリコンピュートパイプラインの出力について説明します。

生成する LOD の数は、<geom> ごとに決定します。<Geom> が異なると、LOD の数も異なることがあります。LOD 数の異なる複数のジオメトリのインスタンスが同じシステムにある場合、そのシステムでは、ジオメトリについて要求される最大限の数の LOD が生成されます。たとえば、2 つのジオメトリがあるシステムがあり、ジオメトリがそれぞれ 2 つの LOD と 4 つの LOD を持つ場合、そのシステムの LOD は 4 つになります。ジオメトリに対して存在しない LOD が要求された場合、保持されている最小限の LOD が使用されます。以下の例をご覧ください。

生成する LOD の数は、numLods XML 属性により要求されます (.geom ファイル内)。

<?xml version="1.0" encoding="utf-8"?>
<geom name="Cube_0" version="3" numLods="2" //...他のジオメトリ属性...// >
	<mesh name="Cube_0_LOD0" //...他のメッシュ属性...// />
</geom>

連続した LOD は、それぞれ前の LOD の 2 倍のピクセルサイズを持ちます。numLods 属性は、1 以上の正の整数である必要があります。1 に設定するのは、LOD 生成をオフにすることと同じです。デフォルト値は 1 です。

例とプリコンピュートの出力

単純なシーンを再度考えてみます。シーンは 2 つのインスタンス (Instance A と Instance B) と 2 つのジオメトリ (それぞれ Geom A と Geom B) からなります。Geom A は 2 つの LOD、Geom B は 4 つの LOD を持ちます。

Geom_A.geom

<?xml version="1.0" encoding="utf-8"?>
<geom name="Geom_A" version="3" simpNumIterationsPerSimp="500" simpMaxNumSimps="250" simpUsePixelUnits="true" numLods="2">
	<mesh
		name="Geom_A"
		guid="c9408aee000000000000000000000000"
		filename="Geom_A.pim"
		direct="true" indirect="true" target="true"/>
</geom>

Geom_B.geom

<?xml version="1.0" encoding="utf-8"?>
<geom name="Geom_B" version="3" simpNumIterationsPerSimp="500" simpMaxNumSimps="250" simpUsePixelUnits="true" numLods="4">
	<mesh
		name="Geom_B"
		guid="dc670a1c000000000000000000000000"
		filename="Geom_B.pim"
		direct="true" indirect="true" target="true"/>
</geom>

World.scene

<?xml version="1.0" encoding="utf-8"?>
<scene name="World" version="1" axes="-x+y+z">
	<instance name="Instance_B" instanceGuid="00000000000000000000000000000001" systemId="System_0" systemGuid="8494c213000000000000000000000000" paramSet="High" geometry="Geom_B" type="Radiosity" position="0.000000 20.000000 50.000000" rotation="0.000000 0.000000 0.000000 1.000000"/>
	<instance name="Instance_A" instanceGuid="00000000000000000000000000000002" systemId="System_0" systemGuid="8494c213000000000000000000000000" paramSet="High" geometry="Geom_A" type="Radiosity" position="230.000000 20.000000 290.000000" rotation="0.000000 0.000000 0.000000 1.000000"/>
</scene>

このマークアップのあるシーンが High Level Build System への入力として使用されるとき、以下の出力が precomp フォルダーに生成されます。

ファイル名	説明

ファイル名	説明
Geom_A_High.ig	Geom_A を説明する `IPrecompInputGeometry` オブジェクトのシリアル化です (メッシュ、頂点、法線、アルベド UV など)。また、このジオメトリ向けに LOD をいくつ生成する必要があるかに関する情報を保持します。詳細については、`IPrecompInputGeometry` API をご覧ください。
Geom_B_High.ig	Geom_B を説明する `IPrecompInputGeometry` オブジェクトのシリアル化です (メッシュ、頂点、法線、アルベド UV など)。また、このジオメトリ向けに LOD をいくつ生成する必要があるかに関する情報を保持します。詳細については、`IPrecompInputGeometry` API をご覧ください。
System_0.is	System_0 で使用される Geom_A と Geom_B のインスタンスを説明する `IPrecompInputSystem` オブジェクトのシリアル化です。詳細については、`IPrecompInputSystem` API をご覧ください。
Geom_A_High.pag	Geom_A のすべての LOD 向けの `IPrecompPackedGeometry` のシリアル化です。LOD のアクセス方法については、`IPrecompPackedGeometry` API をご覧ください。各 LOD には、ジオメトリのライトマップ UV が含まれます。これは、`IPrecompPackedSystem` の UV インスタンストランスフォームと組み合わされ、その LOD のライトマップテクスチャにこのジオメトリをマッピングするために使用することができます。
Geom_B_High.pag	Geom_B のすべての LOD 向けの `IPrecompPackedGeometry` のシリアル化です。LOD のアクセス方法については、`IPrecompPackedGeometry` API をご覧ください。各 LOD には、ジオメトリのライトマップ UV が含まれます。これは、`IPrecompPackedSystem` の UV インスタンストランスフォームと組み合わされ、その LOD のライトマップテクスチャにこのジオメトリをマッピングするために使用することができます。
System_0.pas	すべての LOD 向けの`IPrecompPackedSystem` のシリアル化です。LOD のアクセス方法については、`IPrecompPackedSystem` API をご覧ください。各 LOD には `IPrecompPackedInstance` オブジェクトのセットが含まれており、その LOD の既定のインスタンスのためのライトマップ UV の取得に使用できます。
System_0.sdeps	System_0 のシステム依存関係のシリアル化です。システム依存関係は、すべてのシステムの LOD 0 バージョンのみを使用して計算されます。
System_0.prc	プレクラスタリング (クラスタメッシュ、リーフクラスタ) データのシリアル化です。クラスタメッシュの各頂点には、システムのすべての LOD のライトマップ UV があります。
System_0.clu	クラスタツリー階層のシリアル化で、LOD データは含まれません。
System_0.dust	システムダスターのシリアル化です (入力ライティングとバウンスリサンプリングに使用します)。各ダスターポイントには、すべての LOD のライトマップ UV があります。これらは、すべての LOD のバウンスリサンプリングに必要です。
System_0.lt	System_0 とそのすべての LOD のライトトランスポートデータ (フォームファクターなど) を含む、`IPrecompSystemLightTransport` のシリアル化です。
System_0.ltz	RadCore へのエキスポートが可能な形式のライトトランスポートデータを含む `IPrecompSystemCompressedLightTransport` のシリアル化です。

System_0.prc、System_0.clu、System_0.dust、System_0.lt、System_0.ltz は、プリコンピュートパイプラインの内部ステージであり、便利なパブリックインターフェイスはありません。

radiosity フォルダーに、以下の出力が生成されます。

ファイル名	説明

ファイル名	説明
System_0.caw	System_0 のクラスタアルベドワークスペースです。LOD に依存します。
System_0.clo	System_0 のクラスタ出力です。LOD に依存します。デバッグ/診断に使用します。
System_0.iw.ref	リファレンスソルバーとともに使用する System_0 の入力ワークスペースデータです。LOD に依存します。
System_0.iw.sse	SSE 最適化ソルバーとともに使用する System_0 の入力ワークスペースデータです。LOD に依存します。
System_0.lto	すべての LOD の System_0 ライトトランスポート出力です。LOD データへのアクセス方法については、ILightTransportOutput API をご覧ください。デバッグ/診断に使用します。
System_0.vis	System_0 のディレクショナル可視性データです。LOD に依存します。
System_0.mso	LOD 0 メッシュ簡素化出力での System_0 です。デバッグ/診断に使用します。メッシュ、チャート、ライトマップ UV などのパッキングデータを含みます。
System_0_LOD_1.mso	LOD 1 メッシュ簡素化出力での System_0 です。デバッグ/診断に使用します。メッシュ、チャート、ライトマップ UV などのパッキングデータを含みます。
System_0_LOD_2.mso	LOD 2 メッシュ簡素化出力での System_0 です。デバッグ/診断に使用します。メッシュ、チャート、ライトマップ UV などのパッキングデータを含みます。
System_0_LOD_3.mso	LOD 3 メッシュ簡素化出力での System_0 です。デバッグ/診断に使用します。メッシュ、チャート、ライトマップ UV などのパッキングデータを含みます。
System_0.rc.ref	LOD 0 ラジオシティコアデータでの System 0 です。イラディアンスを解決するためにリファレンスソルバーから要求されるコアデータです。
System_0.rc_LOD_1.ref	LOD 1 ラジオシティコアデータでの System 0 です。イラディアンスを解決するためにリファレンスソルバーから要求されるコアデータです。
System_0.rc_LOD_2.ref	LOD 2 ラジオシティコアデータでの System 0 です。イラディアンスを解決するためにリファレンスソルバーから要求されるコアデータです。
System_0.rc_LOD_3.ref	LOD 3 ラジオシティコアデータでの System 0 です。イラディアンスを解決するためにリファレンスソルバーから要求されるコアデータです。
System_0.rc.sse	LOD 0 ラジオシティコアデータでの System 0 です。イラディアンスを解決するために SSE 最適化ソルバーから要求されるコアデータです。
System_0.rc_LOD_1.sse	LOD 1 ラジオシティコアデータでの System 0 です。イラディアンスを解決するために SSE 最適化ソルバーから要求されるコアデータです。
System_0.rc_LOD_2.sse	LOD 2 ラジオシティコアデータでの System 0 です。イラディアンスを解決するために SSE 最適化ソルバーから要求されるコアデータです。
System_0.rc_LOD_3.sse	LOD 3 ラジオシティコアデータでの System 0 です。イラディアンスを解決するために SSE 最適化ソルバーから要求されるコアデータです。
System_0.rnt	LOD 0 ラジオシティ法線テクスチャでの System_0 です。ソルバーがディレクショナルイラディアンスを解決するために必要です。
System_0_LOD_1.rnt	LOD 1 ラジオシティ法線テクスチャでの System_0 です。ソルバーがディレクショナルイラディアンスを解決するために必要です。
System_0_LOD_2.rnt	LOD 2 ラジオシティ法線テクスチャでの System_0 です。ソルバーがディレクショナルイラディアンスを解決するために必要です。
System_0_LOD_3.rnt	LOD 3 ラジオシティ法線テクスチャでの System_0 です。ソルバーがディレクショナルイラディアンスを解決するために必要です。

7.16. ライトマップ LOD

導入

概要

High Level Build System

例とプリコンピュートの出力

Geom_A.geom

Geom_B.geom

World.scene