UE5 における 3DGS シーンのフレームレートチューニング

ステップ 1：ボトルネックを特定する

パラメーターを調整する前に、フレームレートの低下が 3DGS によるものかを必ず確認する。シーン内のライティング、影、後処理、通常のモデル、Blueprint のロジックがいずれも本当のボトルネックになりうる。その場合は LCC のパラメーターをどう調整しても改善しない。

まず 3DGS がボトルネックであることを確認する

シーン内の 3DGS 以外の要素を非表示にするか削除して、フレームレートの変化を比較する。

1. 現在のフレームレートを基準として記録する（stat fps または stat unit）。
2. LCC Actor を非表示にし、シーンの残りの部分だけを残してフレームレートを記録する。
3. 逆に LCC Actor だけを残し、他のモデル、光源、後処理ボリューム、UI を非表示または削除してフレームレートを記録する。

元のシーンに要素が多く 1 つずつ非表示にするのが面倒な場合は、空のレベルを新規作成し、LCC Actor 1 つだけを置いて同じデータを読み込み、同じ視点でフレームレートを記録するほうがきれいである。これで元のシーンのすべての干渉を排除でき、得られるのが 3DGS 自体のパフォーマンスの基準値になる。

3 組のデータを比較する。

まずエンジン既定のシーン要素を除外する

レベルを新規作成するとエンジンが既定の Actor をいくつか付けてくる。そのうちいくつかはコストが小さくなく、3DGS のコストだと誤解されやすい。もっとも典型的なのは **VolumetricCloud（ボリュメトリッククラウド）**である。フレームごとにボリュームレイマーチングを行うため、画面に空がわずかしか映っていなくても GPU を消費し続ける。

プロジェクトで空の効果が不要な場合は、次の Actor をレベルから直接削除する。

3DGS データ自体には通常すでに環境の情報が含まれているため、これらの効果は多くの場合不要である。削除してからフレームレートを測り直し、そのうえで LCC のパラメーターを調整する必要があるかを判断する。

テスト時は条件を固定する。そうしないとデータを比較できない。同じマップとスポーン地点、同じカメラ位置または経路、同じ解像度と Screen Percentage を使い、Lumen、Virtual Shadow Map、後処理、SceneCapture のオン / オフの状態を一致させる。先にウォームアップを一度走らせてから記録し、初回のシェーダーコンパイルと初回のディスク読み取りを安定したフレームレートに混ぜ込まない。1 回につき 1 種類の設定だけを変更する。

よく使う観測コマンド：

stat fps         // フレームレート
stat unit        // Frame / Game / Draw / GPU の 4 項目のフレーム時間
stat gpu         // GPU Pass の内訳
stat rhi         // ドローコール、プリミティブ、ビデオメモリ
ProfileGPU       // 1 フレームの GPU Pass の明細

3DGS と確認できたら LCC の統計を使う

Actor パネルの Actions > Stats で統計パネルを開ける。コンソールで stat xgrids と入力してもよい。

stat xgrids で LCC のリアルタイムパフォーマンス統計を確認する

パラメーターの詳しい情報は パフォーマンスパラメーター：統計データ を参照する

重点的に見るのは Current Render Main Splats と Current Render Nodes である。多くのパフォーマンス問題の直接的な原因は、同一画面のレンダリング点数が多すぎることにある。

同時に LOD の可視化も開く

統計の数値を見ながら、Actor パネルの Actions > Debug Node Bound でノードの Level の可視化を開き、現在の視点の LOD 分布を直感的に確認する。カラーが暖色に近いほど Level が低く、ディテールが高い。

最適化の考え方は、見え方が許容できる範囲で同一画面の点数をできるだけ減らすことである。重点は Level 0 がどこまで広がっているかを見ることにある。

• 画面内の暖色の領域はどこまで伸びているか。その距離で本当に最高精度のデータが必要か。
• より粗い階層へ切り替わる距離を早めたとき、見え方に体感できる低下があるか。

多くのシーンでは Level 0 の作用距離が実際に必要な距離より遠い。より早く粗い階層に切り替えさせると点数の低下がすぐに効き、すべての手段の中でもっとも効果が明らかな項目になる。圧縮の余地があると確認できたら ステップ 2 に進んで Level Factor を調整する。

ステップ 2：LOD を調整する

これがもっとも効果の明らかな手順である。多くのシーンでは Level 0 の作用距離が実際に必要な距離を大きく超えており、より早く粗い階層に切り替えさせると同一画面の点数がすぐに下がる。それでも見え方には体感できる変化がないことが多い。まずこの手順を行い、そのうえで以降の手段を検討する。

LOD には独立した 3 つのつまみがある（Level Factor、Start Level、End Level）。

Level Factor、Start Level、End Level を設定する

2.1 まず Level Factor の働き方を把握する

2 つのパイプラインでは Level を選択する仕組みが異なるため、Level Factor の働き方も異なる。ただし方向は同じで、値が大きいほどノードが早く低ディテールの階層に切り替わる。

LCC2 パイプライン：スクリーンスペース誤差

LCC2 は RangeForLevel を使わず、ノードごとにスクリーンスペース誤差を計算する。ノード自身のジオメトリ誤差を画面に投影したときに何ピクセル分になるかである。誤差がしきい値を超えるとより細かい子ノードへ細分化し、超えなければ現在の階層に留まる。

この誤差はノードの距離、視野角、画面の解像度の影響を同時に受けるため、同じ Level Factor でも解像度や FOV が異なると実際の切り替え距離は同じにならない。つまり LCC2 の LOD 分布は 1 枚の距離テーブルで事前に算出できないので、2.5 の Debug Node Bound で実際に観察するしかない。

パラメーターの調整方法は LCC パイプラインと同じなので、2.2 のテストの段階表をそのまま見る。

LCC パイプライン：距離テーブル

Level Factor の働きは、グローバルな RangeForLevel 配列をこの値で割ることである。値が大きいほど各 Level の作用距離が短くなり、ノードが早く低ディテールの階層に入る。

RangeForLevel の既定値（11 項目、ProjectSettings > Plugins > LCC4Unreal > Level）：

Level:  0    1    2    3    4    5    6    7    8    9    10
メートル: 15   50   80  110  140  170  190  220  250  280   350

Level Factor で割った後の実際の作用距離（単位：メートル、整数でない値は四捨五入して表示）：

この表の使い方：Level Factor = 2 の場合、もともと 15 メートル以内で最高ディテールを使っていたところが、7.5 メートル以内でのみ最高ディテールを使うようになる。これは「ディテールを半分にする」という言い方よりはるかに正確である。変わるのは各 Level の作用距離であり、点数の比率ではない。

Level と距離の正確な比較方法（上界か下界か、開区間か閉区間か）は内部実装に属する。上の表は調整幅を見積もるためのものであり、実際の Level 分布は 2.5 の Debug Node Bound で確認する。この表は LCC パイプラインにのみ適用される。

距離が RangeForLevel の最後の項目を超える場合、ノードは自身で使える最も粗い Level をそのまま使うので、階層が見つからないという事態は起きない。したがって Max Distance を 350 メートル超に上げるときに、このテーブルを合わせて調整する必要はない。

プロジェクト設定で Range For Level の距離配列を設定する

2.2 Level Factor

値の範囲と既定値は パフォーマンスパラメーター：Level Factor を参照する

LOD の調整はまずこのつまみを使う。効き方がなめらかで、ディテールの階層をまるごと切り落とすことがないためである。

テストの段階：

1.0 → 1.25 → 1.5 → 2.0

先に確認する箇所：輪郭、細い線、小さな物体、地面のディテール、Level の遷移領域。これらの場所ではディテール不足と LOD のポッピングがもっとも早く現れる。

Level Factor を調整した後の LOD の変化

2.3 Start Level

値の範囲と既定値は パフォーマンスパラメーター：Start Level を参照する

上げると、番号の小さい（もっとも細かい）Level をそのまま飛ばす。

0 → 1 → 2

これは Level Factor を少し変えるよりはるかに強い手段である。距離をスケールするのではなく、Level をまるごと捨てるためである。次の 2 つの条件がどちらも満たされるときにのみ使う：stat xgrids で Level0 Splats が本当に主なコストになっていること、そして近景の品質が粗くなっても許容できること。近景が目に見えてぼやける場合は 0 に戻す。

Start Level を上げて高ディテールの Level を飛ばす

2.4 End Level（通常はそのままにする）

値の範囲と既定値は パフォーマンスパラメーター：End Level を参照する

下げると使用できるもっとも粗い Level が制限される。データ側にあるより粗い階層が一切使われなくなり、遠景の内容は End Level に留まるしかなく、必要より多くの点をレンダリングすることになる。高速化のためのボタンではないので、データの Level 構造を把握していない限り既定値のままにする。

Start Level <= End Level を満たす必要がある。セッター側で検証は行われない。

End Level を調整して低ディテールの Level を制限する

2.5 Debug Node Bound で検証する

Actor パネルの Actions > Debug Node Bound でノードのバウンドと Level を可視化できる。カラーの並びは赤、橙、黄、緑、青、紫であり、赤がもっとも低い Level（もっとも高いディテール）、白がもっとも高い Level（もっとも低いディテール）を表す。

LOD のパラメーターを変更した後の確認に使う。近景がまだ赤 / 橙（高ディテール）になっているか、遠景が寒色へなめらかに遷移しているか、同じ距離で Level が繰り返し反転している領域がないかを見る。

Debug Node Bound で LOD の分布を確認する

LOD の検証ポイント

• ノード数と Splat 数が下がっているか
• 近景が早すぎるタイミングで粗くなっていないか
• カメラの移動中に明らかな LOD のポッピングが出ていないか

ステップ 3：最大レンダリング距離

値の範囲と既定値は パフォーマンスパラメーター：Max Distance(m) を参照する

Max Distance 最大レンダリング距離を設定する

LOD との違い

Max Distance はその距離より遠いデータをそのまま切り落とし、レンダリング可能な空間の範囲を縮める。LOD は範囲内の精度を下げる。両者は補完関係にあるので、LOD の調整を終えてもまだ圧力が残る場合にこれで範囲をさらに絞る。

候補ノードを減らし、それに続くトラバース、読み込み、アップロード、ソート、フィルの作業量も一緒に減らせる可能性があるが、どれだけ減るかは実装とデータに依存する。一定の割合で効果が出ると決め込まず、実際の統計データで検証する。

まず横のチェックボックスをオンにする。そうしないと変更が効かない

Performance カテゴリーの各パラメーターには左側にチェックボックスがある。オフのままでは入力欄の数値は効かず、実行時はプラグイン内蔵の既定値が使われる。調整しても効果がないときは、まずここを確認する。

距離を調整する手順

1. シーン内でモデルデータをもっとも遠くまで見せる必要がある位置に立ち、実際に必要な距離を測る。
2. パラメーター左側のチェックボックスをオンにする。
3. 「実際の最大可視距離 + 必要な余裕」に設定する。
4. 段階的に絞る。いきなり非常に小さい値まで落とさない。

300 m（既定値） → 225 m → 150 m → プロジェクトの実際の距離に微調整

上記はテストの段階であり、推奨値ではない。屋内、市街地、大規模シーン、空撮では妥当な値が大きく異なるので、プロジェクトごとに測る。

Max Distance を調整した後のレンダリング範囲の変化

距離の検証ポイント

• Current Render Nodes と Current Render Splats が下がっているか
• GPU ms または Traversal Time が下がっているか
• 距離の境界まで歩いたときに内容が突然消えていないか
• 高速に移動したときに未読み込みの領域が見えやすくなっていないか

ステップ 4：点数の上限を固定する

値の範囲と既定値は パフォーマンスパラメーター：Max Splat Num を参照する

Max Distance が制御するのは空間の範囲だが、同じ範囲内でもデータの密度は大きく変わりうる。Max Splat Num はフレームごとの作業量の上限を与えるもので、高密度の領域に入ったときに点数が跳ね上がるのを防ぐ。LOD と距離を補完するものであり、どちらの代わりにもならない。

大きすぎる値は 1 フレームで GPU がレンダリングできる量に自動的に制限されることに注意する。パネルの値を上限まで引き上げてもハードウェアの能力を超えることはなく、単に上限が効かなくなるだけである。実際に効かせるには、現在の視点の実際の点数より小さく設定する。

Max Splat Num でフレームごとの点数上限を設定する

点数上限を調整する手順

1. パラメーター左側のチェックボックスをオンにする。
2. 既定値から比率で下げていく。単位は 1 万である。

3000 → 2250 → 1500 → 1000

3. 1 段下げるごとに、開けた場所だけでなく高密度の領域で観察する。

Max Splat Num を調整した後の点数と画面の変化

点数上限の検証ポイント

• GPU ms と Current Render Splats が上限に合わせて下がっているか
• 局所的に薄くなる、ちらつく、半透明の構造が崩れるといった現象が出ていないか

上限を下げても点数も GPU ms も変化しない場合は、現在の視点がその上限に到達していないので、これは今のボトルネックではない。ステップ 1 に戻ってもう一度特定する。

ステップ 5：ピクセルフィルのコストを下げる

5.1 SplatScale

パラメーターの詳しい情報は 画面調節：SplatScale を参照する

小さくすると Splat 1 個が画面を覆う面積が減り、半透明の重なりもそれに応じて減る。

方法：現在の品質の値から小刻みに下げ、高解像度、近景、物体の輪郭の周辺で確認する。下げすぎると表面に穴が空いたり、明らかに薄く見えたりする。

SplatScale を調整してガウス点が覆う画面の面積を減らす

5.2 Small Splat Threshold (px)（LCC2 パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：Small Splat Threshold を参照する

CVar で実行中にテストできる。再起動は不要である。

r.LCC2.SmallSplatThreshold 0
r.LCC2.SmallSplatThreshold 0.5
r.LCC2.SmallSplatThreshold 1

値が大きいほど得られる効果も大きくなるが、遠景の粒状感も目立つようになる。GPU または SH の計算が本当にボトルネックになっているときにのみさらに上げる。データ自体に SH が含まれない場合、SH をスキップして得られる効果は限られる。

Small Splat Threshold のピクセルしきい値を設定する

5.3 Quad Extent Threshold（LCC2 パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：Quad Extent Threshold を参照する

この値を大きくするとクアッドがよりコンパクトになり overdraw が減るが、半透明な縁が切り取られることがある。

r.LCC2.QuadExtentThreshold 0.006 → 0.008 → 0.01

輪郭が硬くなる、縁が欠ける、splat の形状がおかしく見える場合は元に戻す。

Quad Extent Threshold を設定して splat のクアッドの広がりを制御する

5.4 Frustum Cull Margin（LCC2 パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：Frustum Cull Margin を参照する

これが制御するのはカリングの余裕であり、点数の上限ではない。

画面端でポッピングが出ない範囲で、1.0 に向けて小刻みに下げることだけを試す。

r.LCC2.FrustumMargin 1.2 → 1.1 → 1.0

カメラを素早く回したときに端の内容が出たり消えたりする場合は、下げすぎである。

Frustum Cull Margin 視錐台カリングの余裕を設定する

5.5 アンチエイリアス

アンチエイリアスの GPU コストは小さくなく、特に TSR は顕著である。シーンに 3DGS しかなく、通常のメッシュや UI がない場合は、対応する項目を None に設定すると画質の低下はごくわずかで、フレームレートの向上は大きい。

各パイプラインの既定の方式とトレードオフは パフォーマンスパラメーター：アンチエイリアスの方式 を参照する。

LCC の各パイプラインのアンチエイリアスの方式を設定する

ステップ 6：必要のない機能をオフにする

この手順の効果は明確だが、いずれも機能面の代償を伴う。すべてオフにするのではなく、プロジェクトで本当に不要かを項目ごとに確認する。

各機能の詳しい説明は 画面調節 と パフォーマンスパラメーター を参照する。

ステップ 7：ソートとビデオメモリ

半透明のソートとビデオメモリの管理はパイプラインごとに扱われる。Sort Factor と追加のプリロードは LCC1 にのみ存在し、GPU ビデオメモリの予算は LCC2 にのみ存在する。

7.1 Sort Factor（LCC パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：Sort Factor を参照する

グローバルな SortFrequencyForLevel のテーブルに作用し、各 Level のノードを再ソートする頻度を制御する。値が大きいほどソート回数が減ってパフォーマンスは上がるが、カメラやノードが変化した後の半透明の順序の更新が遅くなり、一時的に前後関係が誤って交差して見えることがある。

Sort Factor を設定して LCCActor のソート頻度を調整する

各 LOD Level の Sort Frequency を設定する

7.2 追加のプリロードノード（LCC パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：Add Extra Preload Nodes を参照する

目的は、視点を素早く回したときの画面端の穴を緩和することである。引き換えにノードの作業量が増える。

この項目には 2 段階の状態があり、間違えやすい。

• 左側のチェックボックスがオフの間は内部の既定値にフォールバックするので、実際の結果は有効のままである
• 本当にオフにするには、まずチェックボックスをオンにし、そのうえで値を無効に設定する

統計データでノード数とプリロードが本当に明らかな負担になっていることが分かり、かつプロジェクトが高速に振り向いたときの端の穴を許容できる場合にのみオフにする。穴が現れたらすぐ元に戻す。データが用意できていないことをスレッドの追加でごまかさない。

追加のプリロードノードを設定して高速に振り向いたときの穴を緩和する

7.3 LCC2 GPU Memory Budget（LCC2 パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：LCC2 GPU Memory Budget (MB) を参照する

LCC2 GPU Memory Budget のビデオメモリ予算を設定する

集計されるのは LCC2 モデル 1 つの位置、カラー、球面調和のデータのみである。予算を上げて効果があるのは次の場合に限られる。

• GPU にまだ十分な空きビデオメモリがある
• カクつきが主に新しい領域へ移動したときや複数ビューポートを扱うときに起きている

Splat 数、ソートの作業量、ピクセルの被覆を減らす効果はない。追い出しや断片化の問題がない状態で予算を上げても、常駐するビデオメモリが増えるだけでフレームレートは改善しない。

調整の手順：

1. まず LCC の予算だけでなく、マシン全体のビデオメモリのピークを記録する。
2. 既定値から 1024 MB 刻みで上げる。
3. 変更するたびにエンジンを再起動する。
4. もっとも負荷の高い視点、すべての SceneCapture / nDisplay のビュー、長時間の連続動作を再テストする。
5. UE のシーンテクスチャー、Render Target、Nanite、Lumen、VSM、ソート用バッファー、そして OS のためにビデオメモリを残す。

ビデオメモリの監視が完全でない状態で 8192 MB に設定してはならない。

ログにはビデオメモリ使用量の内訳も出力されるので、予算が妥当かの確認に使える。

GPU footprint: %u slots (%s), %.2f MB total - gaussian %.2f, SH %.2f, sort %.2f (1 view), other %.2f MB

sort の項目はソート用バッファーである。ログは 1 ビュー分で計算されているので、複数ビューポートの場合はビュー数で掛ける。

ステップ 8：読み込み、スレッド、メモリ

8.1 まずスレッドを増やさない（LCC パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：スレッドプールの設定 を参照する

スレッドを増やすと CPU の並列度は上がりうるが、同時にスレッドの競合、コンテキストスイッチ、瞬間的なディスク負荷、アップロードのピークも増えうる。エクスポーターのスレッドは実行時のレンダリングと直接の関係がないので、そこを調整してもフレームレートは改善しない。

判断の基準：統計データで対応するキューが詰まっており、かつ CPU にまだ空きコアがある場合にのみ、一度に 2〜4 スレッド増やして再テストする。CPU がすでに飽和している場合は、スレッドを増やすのではなく作業量を減らす。

Create Thread の項目に時間コストが出続けている場合はスレッドプールが繰り返し拡張されているので、上限ではなく事前作成数を調整する。

8.2 Splat Number For Discard Per Node（LCC パイプライン のみ）

値の範囲と既定値は パフォーマンスパラメーター：Splat Number For Discard Per Node を参照する

ノードごとの疎な splat の破棄しきい値を設定する

意図は極端に疎なノードを無視することである。データセットの中には splat を 1 個か 2 個しか持たないノードが大量に含まれるものがあり、これらのノードの管理コストは画面への寄与より大きい。

大きくすると低密度のノードの管理コストを下げられる可能性があるが、同時に孤立したディテールを取り除いてしまう可能性もある。全体のフレームレートだけを見るのではなく、細い線、木の枝、手すり、遠くの小さな物体で確認する。変更後はデータを再読み込みする。そうしないと画面に出ている結果は古いままである。

8.3 メモリとビデオメモリの解放しきい値

CPU と GPU のメモリ使用量と解放のしきい値を設定する

4 つのしきい値の範囲と既定値は パフォーマンスパラメーター：Usage カテゴリー を参照する

これはメモリ圧力下での解放のポリシーであり、日常的にフレームレートを調整するつまみではない。

• しきい値が低すぎる、または解放の割合が大きすぎる → 「解放して再読み込みしてまた解放する」という振動が起きうる
• しきい値が高すぎる → 解放が遅れ、システムメモリ / ビデオメモリの圧力が増えうる
• 長時間の動作テストでメモリ圧力または繰り返しの追い出しを確認したうえでのみ調整する

判断は CPU Occupy Percentage / GPU Occupy Percentage と対応するしきい値の関係、そして Released CPU Node Num / Released GPU Node Num が増え続けているかで行う。スクリーンショットではビデオメモリ使用量 86% がすでに 80% のしきい値を超えており、ビデオメモリの解放回数が 1943 に達している。これはビデオメモリ圧力の典型的な兆候である。

ステップ 9：複数ビューポート、コリジョン、水面

9.1 複数カメラと SceneCapture

実際にレンダリングに参加するビューが 1 つ増えるごとに、トラバース、レンダリング、ソートの作業量が増えうる。LCC2 ではさらにビューごとにソート用バッファーが増える。

項目ごとに確認する。

1. 使っていないのにフレームごとに更新されている SceneCapture がないか
2. Render Target の解像度が高すぎないか
3. 更新頻度が本当にフレームごとである必要があるか
4. ShowOnlyActors に必要な内容だけが入っているか
5. ミニマップを PointCloud またはより低い解像度に切り替えられないか
6. nDisplay、分割画面、MRQ が同時に追加のビューを作っていないか

stat xgrids の Camera Num(Render) で、実際にレンダリングしているビューの数が想定と一致しているか確認する。Camera Num は更新に参加しているカメラの数であり、両者は異なることがある。想定より多い場合は、気づかないうちにレンダリングされているビューがある。

SceneCapture をまったく使わない場合は SceneCaptureComponent Support をオフにできる。パフォーマンスパラメーター を参照する。

複数ビューポート向けに SceneCaptureComponent Support を設定する

9.2 トラバースのモード

値の範囲と既定値は パフォーマンスパラメーター：Default Traversal Type を参照する

Frustum または Circle の既定のトラバースモードを選択する

Circle は周囲のあらゆる方向のデータが必要な曲面スクリーン、nDisplay、360 度パノラマに向く。Frustum は単一ビューポートの既定の基準である。

通常の単一カメラのプロジェクトを「どの方向にも欠けが出ないように」という理由で Circle に切り替えてはならない。カメラ周囲の円形の範囲全体をトラバースの対象に入れてしまうのに対し、視錐台のモードは見えている部分だけを処理する。ワークフロー上どうしても Circle が必要な場合は、Max Distance、点数の上限、複数ビューポートの解像度をそれに合わせて絞る。

LCC2 パイプラインではこの項目を調整する必要はなく、Frustum のままにする。

9.3 コリジョンとナビゲーション

機能の説明は コリジョン と ナビゲーションシステム対応 を参照する。本節ではパフォーマンス上のトレードオフのみを扱う。

コリジョンがオフなら調整するコリジョン距離もない。有効にすると、コリジョンの読み取り、非同期の物理ベイク、NavMesh の更新が CPU コスト、メモリ、カクつきを増やしうる。こうしたコストは FPS に必ず現れるとは限らず、コリジョン関連の統計データを個別に確認する必要があることに注意する。

コリジョン距離の範囲と既定値は パフォーマンスパラメーター：Max Load Collision Distance(m) を参照する

1. 展示のみのプロジェクトではコリジョンをそのままオフにする。
2. コリジョンが必要な場合は、パラメーター左側のチェックボックスをオンにし、Max Load Collision Distance(m) を実際のインタラクションの範囲に設定する。

Max Load Collision Distance コリジョンの読み込み距離を設定する

コリジョンの読み込み距離を調整した後の動的なコリジョン範囲の変化

3. レンダリング距離とコリジョン距離を機械的に同じ値にしてはならない。遠くに見えることは、そこで物理的なコリジョンが必要であることを意味しない。
4. コリジョン距離を減らすとプレイヤーのインタラクションと AI が使える範囲が直接制限されるので、変更後はフレームレートだけを見るのではなく機能の回帰テストを行う。

ナビゲーションを使う場合は方針が逆になる。コリジョン距離はプレイヤーが到達できる領域をできるだけ覆うようにして、その領域のコリジョンを一度に読み込ませる。コリジョンはチャンク単位で動的に読み込まれ、実行時に新しいコリジョンのチャンクが入れ替わるとナビゲーションデータの再構築がトリガーされ、明らかなカクつきの原因になる。

補助となるポイント：

• NavMeshBoundsVolume でプレイヤーの活動範囲を覆い、その範囲内のコリジョンが完全に読み込まれていることを確認する
• Static のベイクを優先し、Dynamic のベイクは避ける。後者はコリジョンが変化するたびに再構築を繰り返す

9.4 Single layer water（LCC2 パイプライン のみ）

機能の説明と設定の全体は Single layer water 対応 を参照する。本節ではパフォーマンス上のトレードオフのみを扱う。

SingleLayerWater Support はプロジェクト設定のグローバルな項目だが、その実装は LCC2 の中間深度に依存するため、LCC パイプラインの Actor では効かない。

• Single layer water を使わない場合はオフのままにする
• 有効にした後は再起動が必要である
• 代償は水面のピクセルが Virtual Shadow Map による影の品質を失うことであり、純粋なパフォーマンスのトレードオフではなく機能面のトレードオフである
• 3DGS が単層水のマテリアルに誤って遮られる場合にのみ有効にする