3DGS レンダリングの仕組みとビデオメモリ管理

データがどのような形でビデオメモリに入りレンダリングに参加するか、およびビデオメモリの割り当てルールと容量上限を説明する。画面パラメーターの調整は 画面調節 を、読み込み操作は クイックスタート を参照する。

用語の定義：データを分割した後の最小の読み込み単位かつレンダリング単位をノード (Node) と呼ぶ。各ノードの精度は Level で示し、Level 0 が最も精度が高く、Level が大きくなるほど精度が低くなる。この定義は パフォーマンス最適化パラメーター と一致する。

分割レンダリングと全量レンダリング

データを読み込んだ後のレンダリング方式は 2 種類ある。可視ノードを必要に応じて読み込む（分割レンダリング）か、データ全体を一度に読み込む（全量レンダリング）。既定の動作はパイプラインごとに異なる。

注：本編でいう「分割」はデータを空間ノードに分割して必要に応じて読み込むことを指し、Tiled ラスタライズ のタイルが画面ピクセルのタイルであるのとは別のものである。一方はデータがどうビデオメモリに入るかを決め、もう一方はすでにビデオメモリにあるデータをどう描画するかを決める。両者は互いに独立している。

分割レンダリング

データは空間ノードに分割され、各ノードは複数の Level を持つ。1 フレームあたりの処理の流れは次のとおり。

トラバース（カメラ位置と向きで可視ノードを絞り込み、各ノードの Level を選定）
      │
      ▼
読み込み（選択されたノードのデータをメモリに読み込む）
      │
      ▼
アップロード（データをビデオメモリに送る）
      │
      ▼
レンダリング

近くのノードは低い Level を使い、遠くのノードは高い Level を使い、不可視のノードは読み込まない。視野から外れたノードはすぐには解放されず、再度視野に入ったときにそのまま再利用できるようキャッシュに保持される。ビデオメモリが不足したときにのみ、最終レンダリング時刻などの条件に基づいて最も長く使われていないノードを破棄する。ビデオメモリの使用量は主に現在の可視範囲で決まるため、大規模なシーンにも対応できる。

2 つのパイプラインでは描画の送信方式が異なる。

分割レンダリングに固有のコスト：

• 隣接するノードに異なる Level が割り当てられることがあり、境界部分で密度や鮮明さに差が生じてノードの境界が見えることがある
• カメラの移動中に Level が切り替わり続けるため、ディテールが飛ぶように変化することがある

全量レンダリング

カメラでノードを絞り込む処理をスキップし、データ全体を一度に読み込んでビデオメモリに常駐させる。カメラを動かしてもトラバースと Level の選定をやり直さない。

利点：

• シーン全体で統一された Level を使うため、ノード間の Level 差がなく、ノードの境界が見えない
• データがビデオメモリに常駐するため、カメラ移動時に読み込み、解放、ディテールの飛びが発生しない
• フレームごとのトラバースとアップロードのコストがなくなり、フレームレートが安定する

引き換えにデータがすべてビデオメモリに常駐するため、使用量はシーン規模に比例して増える。したがって小規模なシーンにのみ適する。

全量レンダリングの判定条件

全量レンダリングを使うかは読み込み時に決まり、Use Full Load スイッチと Level 0 の splat 数で決まる。

Load(データファイル)
      │
      ▼
Level 0 の splat 数を読み取る
      │
      ▼
Use Full Load はオン？ ── いいえ ──▶ 分割レンダリング
      │ はい
      ▼
splat 数 ≤ Full Load Splat Number？ ── いいえ ──▶ 分割レンダリング
      │ はい
      ▼
   全量レンダリング

2 つのプロパティはいずれも Actor の Details パネルの Performance カテゴリーにある。

既定値は Actor の種類ごとに異なる。

LCC2 で全量レンダリングを手動で有効にする場面

LCC2 パイプラインは全量レンダリングが既定でオフになっている。次のような場面では手動で有効にできる。

• シーン規模が限られていてビデオメモリに余裕があり、画質とフレームレートの両方を安定させたい場合
• カメラが高速に移動したり頻繁にテレポートしたりして、ノードの読み込みが追いつかず、穴やディテールの飛びが発生する場合
• 製品レベルの展示、画面収録、シーケンスレンダリングなど、読み込み中の画面変化が許容されない場合
• ノードの境界部分の密度差が依然として見える場合

有効にした結果ビデオメモリが厳しくなったりフレームレートが下がったりする場合、そのシーンは全量レンダリングの適用範囲を超えているので、分割レンダリングに戻す。

注：全量レンダリングでも最大レンダリング距離の制限は受ける。カメラとデータの距離がその値を超えると表示されない。

ビデオメモリ予算と容量上限

LCC2 パイプラインは常駐する splat データを統一 Buffer に集約してレンダリングするため、1 つのモデルに読み込めるデータ量はこれらの Buffer の容量上限で決まる。

Buffer の構造と splat 1 個あたりの使用量

データは 2 つの Buffer に分けて格納される。

球面調和 Buffer はデータが実際に持つ次数に応じて割り当てられ、1 次は 12 バイト、2 次は 27 バイト、3 次は 48 バイトである。低い次数のデータは最大の次数の分を確保しないため、同じビデオメモリでより多くの splat を保持できる。

Buffer 1 つあたりのハード上限

Unreal の Buffer サイズは 32 ビット整数で記録されるため、理論上限は 4 GB である。プラグインは実際には 4095 MB（4 GB より 1 MB 少ない）を採用し、残した余裕をアップロード時のバイト計算がはみ出さないようにするために使う。この上限は Buffer ごとに個別に効き、設定で超えることはできない。

ビデオメモリ予算の設定

1 つの .lcc2 モデルが常駐できるビデオメモリは ProjectSettings > Plugins > LCC4Unreal の LCC2 GPU Memory Budget (MB) で制御する。

この予算は 2 つの Buffer の合計であり、片方だけの上限ではない。したがって 3 次の球面調和を持つデータは splat 1 個あたり 88 バイト（40 + 48）として予算に計上され、球面調和を持たないデータは 40 バイトとして計上される。

この予算はストリーミング読み込みの常駐ウィンドウを定めるものであり、ノードを入れ替えられる .lcc2 にのみ効く。単一ファイル形式（.ply / .spz / .sog）は全体が常駐する必要があり、容量の判定方法が別にある。単一ファイル形式の読み込み上限を参照する。

ソート Buffer の追加コスト

3DGS はレンダリング前に splat からカメラまでの距離でソートする必要がある。ソート結果は視点に依存するため、視点ごとに 1 組のソート Buffer が必要になる。この部分は上記の予算には含まれず、視点ごとに常駐する splat 1 個あたり 16 バイトを追加で消費する（ソートキーとインデックスを各 2 組持ち、ソート処理中の読み書きを交互に行うため）。

予算 2048 MB で球面調和を持つデータの場合、約 2440 万 splat を常駐でき、1 視点あたりのソート Buffer は約 372 MB になる。

ステレオレンダリングの左右の目、分割画面のプレイヤーごと、SceneCapture はそれぞれ 1 視点として数える。視点数が増えるとソート Buffer もそれに応じて増え、視点が減っても元には戻らない。そのためビデオメモリを計画するときは、これまでに発生した最大の視点数を基準に確保する必要がある。

単一ファイル形式の読み込み上限

単一ファイル形式とは .ply / .spz / .sog、つまりデータ全体が 1 つのファイルに保存され、ノード分割と Level の情報を持たない形式を指す。この種のデータは分割して読み込めないため、プラグインは単一のノードとして一度にデコードし、すべてビデオメモリに常駐させるしかない。そのため splat 数に明確な上限がある。.lcc と .lcc2 はエクスポート時にノード分割が済んでいるため、単一ファイル形式には該当しない。

上限の計算方法

単一ファイル形式の上限は LCC2 GPU Memory Budget に縛られない。この予算はストリーミング読み込みの常駐ウィンドウの大きさを定めるものであり、ノードを入れ替えられる .lcc2 に対してのみ意味を持つ。単一ファイルは全体が常駐しなければならない 1 つのノードであり、同じ数値を当てはめると人為的な容量の上限になってしまい、グラフィックスカードが本来収められるモデルまで弾いてしまう。そのため単一ファイルの容量はハードウェアの条件が直接決めており、予算を変えても変化しない。

読み込み前にプラグインが上限を計算し、上限を超えるデータをブロックする。上限は以下の 2 つの条件のうち小さい方になる。

ビデオメモリに計上する際は splat 1 個あたりの物理的なコストで換算し、ソート Buffer の 16 バイトも含める。グラフィックスカードのビデオメモリ情報を読み取れないプラットフォームでは、推測で数値を出さずに Buffer 1 つあたりの上限のみで計算する。

球面調和の次数は容量を直接変える。1 次のデータの球面調和の stride は 12 バイトで、3 次（48 バイト）の 4 分の 1 しかないため、同じグラフィックスカードで収められる splat 数は明らかに多くなる。プラグインはデータが持つ実際の次数で計算し、常に最大の 48 バイトで見積もることはしない。

上限を超えたときの対処

単一ファイルのデータが上限を超えると読み込みが拒否され、Output Log に実際の splat 数と現在の上限が出力され、その上限が Buffer 1 つあたりの制限によるものか、使えるビデオメモリによるものかも示される。対処方法を推奨順に示す。

1. .lcc2 に変換し、一度に常駐させるのではなくプラグインに必要に応じて読み込ませる。データの総量はこの上限の制約を受けなくなる。
2. 球面調和の次数がより低いデータ、または球面調和を持たないデータに切り替える。splat 1 個あたりのビデオメモリのコストが下がる。
3. ビデオメモリがより大きいグラフィックスカードに変える。ボトルネックが使えるビデオメモリである場合、上限を上げられる唯一のハードウェア的な手段である。

.sog や .spz に切り替えても上限は超えられない。この種の形式の圧縮はディスク上のファイルにのみ効くもので、デコード後に splat 1 個がビデオメモリで占める量はまったく同じである。

LCC2 形式はこの上限の制約を受けない

.lcc2 はデータを複数のノードに分割し、ノードごとに個別にデコードとアップロードを行う。個々のノードはいずれも上記の上限をはるかに下回るため、データの総量にハードな上限はなく、ビデオメモリ予算を大きく超えることもできる。制約を受けるのは実行時の次の 2 つの量である。

1 フレームのレンダリング量は Actor の Max Splat Num の制限も同時に受け、両者のうち小さい値が採用される。

ビデオメモリの管理とチューニング

ビデオメモリ不足時の自動解放

実行時、プラグインはグラフィックスカードの実際のビデオメモリ使用量を継続的に監視する。使用量が ProjectSettings の Max GPU Usage Percentage For Release で設定した割合を超えると、最終レンダリング時刻、アクセス頻度、データサイズ、Level を総合してソートし、最も長く使われていないノードから解放する。高い Level のノードは保護され、視点を素早く回したときに広い範囲が抜けるのを避ける。

関連する設定：

ビデオメモリ予算不足の判断と調整

予算が小さすぎる場合、データの読み込みが失敗するのではなく、入れ替えが繰り返される形で現れる。よく見られる現象は次のとおり。

• カメラを移動または回転させると画面に穴が空き、止めると徐々に埋まっていく
• 視点を行き来させると、同じ領域が鮮明になったりぼやけたりを繰り返す
• 一部の領域が常にぼやけたままで、近づいても鮮明にならない
• 視野内の情報量に応じてフレームレートが変動し、視界が開けた場所で明らかに下がる
• シーンが静止しているときは正常だが、移動するとカクつく

このうち一部領域のぼやけは、データ自体の品質不足だと誤解されやすい。低い Level のデータの読み込みが間に合わない場合、プラグインはまずビデオメモリにある高い Level のデータで埋めて画面が欠けないようにし、低い Level のデータが用意できたら差し替える。ビデオメモリ不足で低い Level のデータが繰り返し破棄されると、その領域は高い Level のまま留まり続ける。判断の目安は近づいたときに鮮明になるかどうかである。正常であれば 1 ~ 2 秒留まれば埋まるので、いつまでも変わらない場合は低い Level のデータがビデオメモリに入れないことを意味する。

確認方法：読み込み時に Output Log に出力されるモデルの予測使用量 (predicted cost) を見て、現在の予算と比較する。1 つのモデルの予測使用量が予算に近い、または予算を超えている場合、常駐領域が不足している。stat LCC で解放回数を観察してもよく、数値が増え続ける場合は頻繁に破棄が起きている。

予算を上げられるのはグラフィックスカードに余裕がある場合に限る。予算はプラグインが要求する上限にすぎず、グラフィックスカードの実際に使えるビデオメモリを超えると、ドライバーがデータをシステムメモリにスワップし、入れ替えよりも深刻にフレームレートが下がる。調整するときは次の順で判断する。

1. グラフィックスカードで使えるビデオメモリを確認する。予算にソート Buffer のコストを加えたうえで、エンジン自体と他のリソースのための余裕を残しておく。
2. 予算を段階的に上げ（2048 → 4096 → 8192）、毎回再起動して穴とフレームレートが改善するか観察する。
3. 改善がはっきりしない場合はボトルネックが予算ではないので、データ量を減らす方向に切り替える。Max Splat Num を下げる、Max Distance の制限を有効にする、または球面調和を持たないデータに切り替える。

注：予算はモデルごとに独立して計算される。シーンに複数の LCC Actor を配置すると、ビデオメモリの使用量はモデル数に応じて積み上がるため、1 つのモデルあたりの予算をそれに合わせて下げる必要がある。