事前計算されたビジビリティ

ドキュメントの概要: Daniel Wright により作成。

概要

cl 572477 (QA_APPROVED_BUILD_AUG_2010で記述予定) から、「UE3」は、ライティングのビルド中にビジビリティを事前計算できるようになります。

事前計算されたビジビリティは、主に、モバイル型プラットホームに役立ちます。これは、ハードウェアによるオクルージョン クエリがないためです。また、コンソール上で分割されるスクリーンのように、レンダリング スレッドのボトルネックになるシナリオで、レンダリング スレッド時間を節約するのにも有効です。事前計算されたビジビリティによって、ランタイム メモリとライトニング ビルドの時間が幾分増加するものの、インゲームでレンダリング スレッドの時間が減ります。レンダリング スレッドの時間が節約されるのは、動的なオクルージョン システム (ハードウェアによるオクルージョン クエリ) によって処理されなければならないプリミティブの数を減らせるためです。また、動作が速いことにもよります。他方、動的なオクルージョン システムであれば、収束する時間が必要となり、これは、しばしばコーナーを回る際や素早く視点を回転させる際にパフォーマンスの低下を招きます。この技術は、中規模以下のレベルに有効です。理由は、レベルのサイズが大きくなれば、メモリおよび演算処理上の要件が増大するためです。また、ほとんど静的な環境においても有効です。たとえば、プレーヤーの動きが限られている場合や、2D 的なプレイ領域においてです。

注意: Lightmass は、事前計算されたビジビリティをビルドする必要があります。

事前計算されたビジビリティを使用するためにゲームをセットアップする

スケーリングがゲームに依存するため、ビジビリティ計算のためのパラメータは、ゲームごとに微調整しなければなりません。パラメータは、BaseLightmass.ini の DevOptions.PrecomputedVisibility セクションにあります。DefaultLightmass.ini の中に DevOptions.PrecomputedVisibility セクションを作成することによって、ゲームはパラメータをオーバーライドします。微調整しなければならない主な設定は、次のものです。

• PlayAreaHeight － カメラが位置することができる、サーフェスより上の高さ。これは通常、最も背が高いプレーヤーの目の高さにジャンプできる高さを加えたものになります。デフォルトでは、220 になっています。

事前計算されたビジビリティを使用するためにレベルをセットアップする

まず、レベルのプレー領域のまわりに、PrecomputedVisibilityVolumes を 1 つ以上配置します。長方形ないしは軸と平行である必要はありません。どんなブラシシェープでも有効です。これらによって、可能な限り厳密なプレー領域が設定されるため、メモリ使用とビルド時間の最適化が図られます。

次に、View->WorldInfo->PrecomputedVisibility の下にある bPrecomputeVisibility を有効にして、レベルのためのライティングをビルドします。カメラがビジビリティ セル内にある場合は、レンダラは、オクルードされることになったあらゆるオブジェクトを選択します

セルの配置

ビジビリティ セルが配置されるのは、配置済みの PrecomputedVisibilityVolumes 内にあるシャドウ キャスティング ジオメトリのすぐ上です。これらは、ビジビリティ ボリュームの外にあっても、Matinee カメラの動きに沿って動きます。事前計算されたビジビリティが有効となるのは、ビューアがこれらのセルのいずれかの中にある場合です。したがって、エディタ内で飛び回っているときは、ほとんど有効にはなっていないはずです。

次の画像は、「UDK」の「DM-Sanctuary」からのものですが、青いビジビリティ セルが緑のビジビリティ ボリュームの内部に置かれているのが分かります。:

次の画像では、青いビジビリティ セルが Matinee カメラの軌道に沿って配置されている様子が分かります。

ビジュアル化の結果

エディタは、1 つのビューを、他のビューの「親オクルージョン」として扱うことができます。 Occlusion Preview (オクルージョンプレビュー) をご覧ください。これを使って、事前計算されたオクルージョンをビジュアル化することもできます。

1. まず、事前計算されたビジビリティのためのレベルをセットアップし、ライトニングをビルドします。
2. 視点をセットアップします。1 x 1 縦分割がかなり有効です。すべてのビューで、リアルタイム更新を有効にする必要があります。パースペクティブ ビューポートをプレー領域 (ビジビリティ ボリュームの内側で、地面に幾分近いところ) に動かすことによって、セルの中に入るようにします。これが有効になったと確認できるのは、コンソール上の stat initviews (統計の初期ビュー) に入るとともにパースペクティブ ビューのための stats (統計) を有効にして、Statically Occluded Primitives (統計的にオクルードされたプリミティブ) が 0 以外の値をとった時です。
3. コンソールに ToggleOcclusion とタイプして、動的オクルージョン システムを切ります。ログに、Occlusion queries are now disabled (オクルージョン クエリが無効になりました) というメッセージが表示されます。これによって、事前計算されたオクルージョンの結果だけを調べればよくなります。
4. パースペクティブビューの中で、ビューポートのドロップダウンから View Culling/Occlusion (カリング/オクルージョンをビューする) をクリックします。

パースペクティブ ビューの錐台が、ワイヤーフレーム上でピンク色で描画されるようになるとともに、事前計算されたオクルージョンによって、どのメッシュが可視と見なされているか分かるようになります。

このシーンでは、事前計算されたビジビリティのカリングが 2487 プリミティブ (下の Statically Occluded Primitives (統計的にオクルードされたプリミティブ) という統計値) になることが示されています。これらのプリミティブは、右側のワイヤーフレームではすべて表示されていません。:

次は、同一のシーンは、カメラをビジビリティセルの外側に少し動かしたものです。したがって、オクルージョンは起きません。右側のワイヤーフレームの新しいメッシュに注意してください。:

ビジビリティの設定

関係する統計

• stat initviews (統計の初期ビュー) の下にある Statically Occluded Primitives (統計的にオクルードされたプリミティブ) は、錘台カリングが起きた後、事前計算されたビジビリティによって、いくつのプリミティブが不可視とされたか表示しています。Occluded Primitives (オクルードされたプリミティブ) は、事前計算されたビジビリティと動的オクルージョン システムの両方によって、いくつのプリミティブが不可視とされたか表示しています。この 2 つの統計値の差は、事前計算されたビジビリティによって見逃されたプリミティブを動的オクルージョン システムがいくつカリングしたか表わしています。事前計算されたビジビリティがうまく機能している場合は、Statically Occluded Primitives (統計的にオクルードされたプリミティブ) は、Occluded Primitives (オクルードされたプリミティブ) の 50～80% 以内であるはずです。事前計算されたビジビリティがカリングするオブジェクトは、より少なく、その理由は、大きなセルのための情報を保存し、動的ないしはマスク化されたオクルーダを扱わないからです。(『制限』のセクションを参照してください)。 注意: この統計は、インゲームおよび PIE において非常に信頼度が高い。ただし、エディタ内ではそうではありません。原因は、エディタ内で描画されるデバッグ関連物すべてにあります。
• stat initviews (統計の初期ビュー) の下にある Decompress Occlusion (解凍オクルージョン) は、事前計算されたビジビリティを解凍するのにどのくらいの時間がかかったかを示しています。
• stat initviews (統計の初期ビュー) の下にある Precomputed Visibility Memory (事前計算されたビジビリティのメモリ使用) は、事前計算されたビジビリティによってどのくらいの実行時メモリが使用されたかを示しています。

結果

次は、「Gears of War 3」の MP レベルからのもので、よいオクルーダ (小さな穴を多数もたない大きな不透明なオクルーダ) が、分割スクリーン内にあります。両方のビューは、マップの中心に向いています。

• トータル 2180 のオクルージョンのうち、1739 が統計的にオクルージョンされたプリミティブです。
• Xbox 360 では、事前計算されたオクルージョンがない場合に比較して、2.7ms のレンダリングスレッド時間の節約になります。(35.4ms ->32.7ms)
• 事前計算されたビジビリティのデータは、627Kb です。
• 新しいエリアに移動すると、そのエリアのためのオクルージョンが解凍されますが、その場合でも、レンダリングスレッドの処理落ちはわずか 1ms です。

制限

事前計算されたビジビリティの現在の実装には、以下の制限があります。

• 動くオブジェクトと動くオクルーダは扱いません。
• 不透明ではないオクルーダは扱いません。理由は、マスクされたオクルーダが、発見困難な小さな穴を開けることが多いからです。
• サーフェスより上のセルしか配置しません。そのため、飛ぶモデルを伴うゲームがそれほど多くの恩恵を受けることがありません。
• ストリーミングレベルを効率的に扱えません。データはすべて、固定したレベルに保存され、ストリーミングレベルを使ったストリームインおよびストリームアウトは行いません。
• 静的シャドウをキャストするトライアングルのみオクルードします。したがって、ライトマップされた interpactor が、オクルードすべきではないときにオクルードすることになります。また、シャドウをキャストしない動かないオブジェクトも、オクルードすべきときにオクルードしないことになります。

これらは、将来改善される可能性があります。

ビジビリティの問題をデバッグする

事前計算されたビジビリティの問題をデバッグする際に役立つ コンソールコマンド がいくつかあります。

• TogglePrecomputedVisibility - 事前計算されたビジビリティ データの使用を切り替えます。
• ShowPrecomputedVisibility - 事前計算されたビジビリティ セルのデバッグ ビジュアル化を切り替えます。

オブジェクトが消えて、TogglePrecomputedVisibility によって表示される場合は、事前計算されたビジビリティがこの問題の原因となっているので、既存の PrecomputedVisibilityVolumes を調整するか、新たに追加することによって、エリアが完全にカバーされるようにする必要があります。