「Gaussian splatting」はかなりすごい
(aras-p.info)- SIGGRAPH 2023の 3D Gaussian Splatting 論文は、写真ベースのシーンを数百万個の3D Gaussianで表現し、リアルタイムにレンダリングするアプローチであり、Unityによる可視化の実験実装も公開されている
- シーンは、メッシュ・ボクセル・距離場の代わりに、位置、回転、非一様スケール、不透明度、球面調和関数係数を持つ空間内のblobの集合として表現される
- この方式は NeRFではなく、公式実装も固定機能ラスタライゼーションパイプラインではなく、100% CUDAベースのタイル式ソフトウェアレンダリングを使用している
- Unity実装は、NVIDIA RTX 3080 Tiで1200x800時に公式ビューアの7.40msより遅い23.8msを要するが、通常のHLSLで書かれているためMacでも動作する
- bicycleシーンはディスク上で 1.5GB、約600万blob、blobあたり約250バイトを占めており、性能だけでなくデータサイズとGPUメモリも重要な改善対象となっている
SIGGRAPH 2023論文とUnity実験
- SIGGRAPH 2023論文 3D Gaussian Splatting for Real-Time Radiance Field Rendering は、Kerbl、Kopanas、Leimkühler、Drettakisによる研究
- 論文サイト、ソースコード、データセットが公開されており、自分で実験や再現を試すことができる
- Unity実験は、すでに生成されたGaussian Splatの「モデル」ファイルを受け取り、リアルタイム可視化することに焦点を当てている
- 実装は aras-p/UnityGaussianSplatting で公開されており、今後さらに実験が続けられる予定
- データサイズを削減できるかも関心事であり、以前のfloat圧縮実験を活用できる可能性がある
Gaussian Splatは何で構成されるのか
- Gaussian Splattingは、3Dシーンをポリゴンメッシュ、ボクセル、距離場の代わりに 数百万個の粒子 で表現する
- 各粒子、すなわち「3D Gaussian」は次の情報を持つ
- 3D空間上の 位置
- 回転
- 非一様3Dスケール
- 不透明度
- 色情報
- 色は単色ではなく3次の Spherical Harmonics 係数で表現され、視点方向に応じて変化しうる
- レンダリング時、粒子は細長い3D球体として描かれるのではなく、スクリーン空間の 2D Gaussian として「splat」される
- 核心は、スケールと色を持つblobの集合を写真ベースのシーン表現にし、それを高速にレンダリングする方法にある
NeRFでも固定機能ラスタライゼーションでもない
- Gaussian Splattingは NeRFではない
- 「Neural」要素はないと明記されている
- 高速な理由も「GPUラスタライゼーションハードウェアを使っているから」ではない
- 公式実装はラスタライゼーションパイプラインを使っていない
- 100% CUDA で実装されている
- 公式実装の性能は固定機能ラスタライゼーションではなく、数百万個のスケール付き粒子を効率的に処理するタイルベースのソフトウェアレンダリングから来ている
- ただし、タイルベースの「GPU上のソフトウェア」ラスタライザ自体はまったく新しい概念ではない
古い技術ブロックとのつながり
- Gaussian Splatting 自体は、2001〜2002年ごろの EWA Splatting のような研究につながっている
- スケールされ方向を持つblobを空間に配置し、それが画面にどう投影されるかを計算したうえで、スクリーン空間でGaussian形状として処理する
- 1994年のゲーム Ecstatica は、楕円体ベースのレンダラを使ったユニークな例
- Spherical Harmonics は物理学で何百年も使われており、コンピュータグラフィックスでは2000年前後にRavi RamamoorthiとPeter-Pike Sloanの研究を通じて広く知られるようになった
- 1984年のKajiya & Von Herzenによる Ray tracing volume densities は、グラフィックスでの初期の利用例かもしれない
- 関連する整理は Patapom’s page で見られる
- Point-Based Rendering も古い分野
- パーティクルシステムは古くからVFXや非固体現象の表現に使われてきた
- The Use of Points as a Display Primitive は1985年の研究
- Surfels は2000年の論文
- demosceneやリアルタイムVFXツールも非伝統的なレンダリング手法を使ってきた
- Fairlight & CNCDの Agenda Circling Forth、Ceasefire (all falls down..)、Number One / Another One が例
- Notch は、点やblobベースのオブジェクトを作成・シミュレーション・表示できるリアルタイムVFXツール
- fogleman/primitive は、画像をprimitive shapeの集合として表現する2016年のツール例
- Media Moleculeの「Dreams」はsplatベースのレンダラを使用しており、発売版は複数手法の組み合わせに見える
- Alex Evansの「Learning from Failure」講演は SIGGRAPH 2015 と Umbra Ignite 2015 で確認できる
- パーティクル向け タイル式ラスタライゼーション は、少なくとも2014年のGareth Thomasによる Holy smoke! Faster Particle Rendering using Direct Compute 以来存在している
- 画面をタイルに分割し、タイル内で処理するとメモリトラフィックを削減できる
- この方式はモバイルGPU全般の動作ともつながっており、PowerVRの初期設計は1996年、Pixel Planes 5は1989年にまでさかのぼる
UnityGaussianSplattingの現状
- aras-p/UnityGaussianSplatting は、Gaussian Splatモデルの ビューワ 実装
- 現状は「動くが速くはない」に近い
- NVIDIA RTX 3080 Tiでbicycleシーンを1200x800でレンダリングすると性能差が大きい
- 公式ビューア: 7.40ms、135FPS
- Unity実装: 23.8ms、42FPS
- 約4倍遅い
- ソート方式も性能差に影響している
- Unity実装は比較的単純なGPU bitonic sortを使用
- 公式実装は OneSweepアルゴリズム に基づくCUDA radix sortを使用
- ラスタライゼーションのアプローチも異なる
- 公式実装はCUDAで書かれた タイルベース 方式
- Unity実装は通常のGPUラスタライゼーションパイプラインで各splatをスクリーン空間quadとしてレンダリングする
- Unity実装には移植性の利点がある
- コードがUnity内の通常の HLSL で書かれており、Macでも動作する
- Apple M1 Maxでは同じシーンが108ms、9FPSでレンダリングされる
- GPUメモリは現状、Unity実装のほうが少なく見える
- 公式ビューア: 4.8GB
- Unity実装: 2.2GB
- Unity Editorが使用するメモリも含んだ数値
データサイズとメモリ使用量
- Gaussian Splattingの議論はレンダリング品質と速度に集中しがちだが、データサイズ とメモリ使用量も大きな問題
- bicycleシーンはディスク上で 1.5GB を占める
- このシーンは約 600万個のblob で構成される
- 各blobは約 250バイト を使用する
- ランタイムでは、ソートやタイルベースレンダリングなどのために追加メモリが必要になる
- Dreamsの講演には、サイズ削減の参考になりそうなアイデアがある
1件のコメント
Hacker News の意見
勾配降下法と微分可能レンダリングを使っていながら、「neural」を避けたという表現は少し得意げに聞こえる
概念的には NeRF と同じように、画像をもとに 3D シーンに関する変数を近似するデータ駆動の表現を最適化するもので、違いは NeRF が光伝達関数全体である放射場（radiance field）をモデル化するのに対し、こちらは光が当たる境界条件だけをモデル化しているように見える点だと思う
対象が違うので、より単純な表現基底が妥当で、結果も良さそうに見えるが、ニューラルネットワークを避けたこと自体が称賛に値するかのように語るのは残念。ニューラルネットワークは流行だから使われているだけではなく、実際に強力な関数近似器であり、「ニューラルネットワーク」と呼ばれる構造の幅も非常に広い
ブログ記事の導入部の口調だけを見て受けた印象なので、論文自体とは違うかもしれない
そのため理解しやすく、エディタやレンダラのような他の 3D ソフトウェアにも統合しやすそうで、アニメーションも可能に見える。シーン全体を一度に表現するブラックボックスの関数近似器は、スケーラブルにもエレガントにも感じられない
ただしニューラルネットワークは、問題をうまくモデル化しても、学習済みモデルが実際にどう動作しているのか分からない場合が多く、データ要求量と反復的な再学習のため、長期的な解決策を作るには限界がある
ここでは著者たちが小さな文化戦争をあおったのではなく、親しみやすい冗談を言ったのだと好意的に受け止めたい
各レンダリングピクセルは、境界のない視点依存ガウシアンの寄与を重み付きで合計するので、NeRF は放射場をモデル化し、これは境界条件だけをモデル化するという区別は正しくない
NeRF が方向領域に低ランクの球面調和表現を使ってきた点まで考えると、ほとんど 3D+α に近く、このような低次元関数を復元するのに、なぜニューラルネットワークを選ぶのかという疑問が生じる
推論時には、ピクセルごとに視線レイに沿ってニューラルネットワークを繰り返しサンプリングしなければならないが、ライトフィールドの圧縮表現はグラフィックスで以前から扱われてきた問題なので、この部分はかなり不自然に感じる
その後 Plenoxels は NeRF から「Ne」を外し、学習と推論の性能を大きく高め、Nvidia の Instant NeRF は小さなニューラルネットワークに精巧な入力埋め込みを補間して入れる方式で、ある程度巻き返した: https://nvlabs.github.io/instant-ngp/assets/mueller2022insta...
グラフィックス工学でニューラルネットワークが広く使われた場所は、主に疎なデータの復元、とくにノイズ除去の方面で、これは高次元問題なので自然だ。それでも手作りのアルゴリズムを圧倒することはまれで、小さなニューラルネットワークを圧縮に使う方向には将来性がありそう
グラフィックスには関数近似が多く、ニューラルネットワークが入る余地はあるが、扱う関数は概してより理解可能で制御可能なので、自然言語理解のように手作業のアルゴリズム的解法を使うのがほぼ不可能な領域とは異なる
多くの会話が AI=悪、CRYPTO=悪で終わるが、反対意見が間違っているという意味ではなく、結論を先に決めて思考を止めてしまうと、自分の考えが完全に的外れかどうかに気づく方法がない、というのが問題
本当に素晴らしい仕事だと思う
記事ではポイントベースレンダリングとパーティクルシステムに触れているが、最近のゲームでは、テクスチャの断片というより点指向でありながら、物理システムのように振る舞う新しいパーティクルスタイルへ、微妙に移行している感じがある
例として Hogwarts: https://www.gamespot.com/a/uploads/original/1816/18167535/40...、Forspoken: https://oyster.ignimgs.com/mediawiki/apis.ign.com/project-at...、Starfield: https://dotesports.com/wp-content/uploads/2023/08/temple-loc...、AC6、FF16 がある
共通点は、物理を持つ色付きの透明な点パーティクルのように見えることで、特にコンソールでは CPU 負荷なしに GPU で安価な効果を出すために使っているように思える。ゲーム開発方面に詳しい人がいれば知りたい
流体シミュレーションがなければ、ポイントベースのパーティクルシステムは単なる花火のように見える。次の段階は、各パーティクルが独立して運動量や風のような物理を持ち、小さなテクスチャ付きビルボードとしてレンダリングされる方式で、比較的最近まで爆発や煙の表現に使われていた
今ではマシン性能と物理アルゴリズムが向上し、パーティクル同士が相互作用する流体シミュレーションをリアルタイムで動かせるようになっており、いま見えている効果はそちらのように見える
3D ゲーム世界では、本物の 3D プリミティブだけを扱うことに概念的・構造的な利点が多く、ポイントスプライトはほぼ無限に小さい 3D オブジェクトのように扱える
一方で 2D スプライトを 3D シーンに入れると、部分透明がある場合は奥から手前へソートする必要があり、Z バッファとうまく噛み合わず、GPU 向けのバッチ順とも衝突し、3D サーフェスにめり込んで 2D であることが露呈しやすい
こうした問題を解決しようとして、スクリーンドア透明度、Z バッファへの書き込み方法を変えるシェーダー、アルファテスト、alpha-to-coverage など、さまざまな妥協策が積み重ねられてきた
VR では、3D シーン内の 2D 画像ベースのレンダリングは単一画面よりさらに悪目立ちし、平らなビルボードであることがはるかに分かりやすい。これらの理由を合わせれば、3D シーンにおける 2D テクスチャスプライト効果から離れたい理由は十分にある
AI 側の流れの影響で、GPU が RT コアや Tensor コアなどによって「GPU の中の縮小命令セット GPU」のような方向に進んでいることも、ある程度関係しているように見える
数年前、NVIDIA 側で SE(3) カーネルを Tensor コアへ移すカーネルを書いていたが、ガウシアンスプラッティングの球面調和関数部分にも、圧縮や実行時に一部移植できそうに見えるので驚きではない: https://developer.nvidia.com/blog/accelerating-se3-transform...
ガウシアンスプラッティングは 3D 空間で常に支持領域を持つため、かなり効率的になりそうで、多少ラフに高速変換しても最終結果はかなり良いものになり得る
輝く点の美しい渦も比較的簡単に作れる。Unreal Engine にも似たものがあると思うが、直接の経験はあまりない
そこに由来するとは思わないが、自分が挙げられる最初のマイルストーンはそのデモだ
Siggraph 論文が最初に出たときは本当に期待した
この10年ほど住んできた部屋をいつか 3D で再現しようと、何百もの角度から写真を撮ってきたが、ガウシアンスプラッティングはほとんど本物のように感じられる形で再現できそうな初めての手法だ
ツールがさらに成熟したら、昔の部屋をまた歩き回って郷愁に浸れると思うと、とても楽しみだ
あまり詳しくない分野なので無知な質問かもしれないが、こういう映像は本当に格好よく見える
私の理解では、シーンや放射場は常に静的で、照明はベイクされている。動的に照明を変えたり、動きまでサポートしたりする方向に発展する可能性があるのか気になる
放射場には光の放出、反射、吸収といった概念がなく、すべてが「伝達された光」という1つの値にまとめられている。その意味で放射場は3D写真に近い
これを変えるには、逆レンダリングやフォトグラメトリで光源位置、表面、材質などを推定したうえで、再び従来のパストレーシングを使う必要がある
もう1つの方向はアニメーションではなく動画で、時間に沿って放射場を継続的にキャプチャし、フレーム間の類似性を圧縮して時間的一貫性を得る方法があり得る
複数をつなぎ合わせてアニメーションを作ることもできる: https://twitter.com/8Infinite8/status/1699460316529090568
再ライティングは、それをサポートするNeRFの変種が多くあるので、スプラットの材質パラメータを最適化することも可能に見える
例えば屋内シーンでテーブルが床に暗い影を落としている場合、NeRFはまだ光源や影を理解していないため、床が黒いのか、白い床がテーブルの影で隠れているのか、影の中に青いStanford bunnyが隠れているのかは分からない
人の顔のような小さな物体をキャプチャする3Dスキャニングリグは、照明を操作してBRDFを直接サンプリングすることで解決している。照明を操作できないならBRDFを推定することはできるだろうが、限界がある
あとからアニメーションを付けるのは簡単かもしれないが、アニメーション自体をキャプチャするには複数のカメラが必要になるか、人間だから反対側を想像して補完するニューラルネットのような推定に頼る必要がある
Intelが数年前、複数のカメラでシーンをキャプチャして後処理でカメラ位置を変えられるというプロジェクトをやっていて、アメリカンフットボール中継向けを狙っていたようだが、実際にリリースされたという話は聞いていない。Matrix式に複数のカメラが必要になる
つまり、時間帯に応じてデータがアニメーションするようにする方式だ。データ量の要求は大きくなり得るが、補間方法があるので、それほど悪くはないかもしれない
静的シーンが2GBなら、大まかな時間帯の近似は16GB未満で可能そうで、現代のGPUでレンダリングできる。その先は、H100級の性能がコンシューマー向けになるのを待ちながら、数年かけて最適化する問題だ
科学がSFの期待を超えるときはいつも面白い
この場合、すぐにCyberpunk 2077のBraindanceという概念を思い出した。他人の視覚記憶の中を、その人がシーンで知覚した範囲内で歩き回れる機能だ
元の視点と違う場所へカメラを動かすと、視界が3次元のピクセルの塊のように崩れる。ここのblobの概念に似ているが、驚くことにこの論文よりずっと洗練されていない見た目だ
https://steelseries.com/blog/how-to-braindance-cyberpunk-207...
ボリュームレンダリングにおけるスプラッティングはかなり古い手法だ。Westover, Lee Alanによる1991年7月の論文 “SPLATTING: A Parallel, Feed-Forward Volume Rendering Algorithm” がある
後者は誰も隠そうとしていないようだし、前者は正しくなさそう
その洞察がどこから来たのかは分からないが、当時はボストン近郊に住んでいて、小さな子どもたちがいた
3DGSレンダリングの最初のネイティブ最適化WebGPU実装に期待している
シーンデータをどう効率よく圧縮し、展開するのかも気になる
この質問についてのメモをZulipスレッドに少し残しておいた: https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/Gau...
最近、ガウシアン・スプラッティングの使い方を紹介する動画を見た: Getting Started With 3D Gaussian Splats for Windows (Beginner Guide) - https://www.youtube.com/watch?v=UXtuigy_wYc
運動からの構造復元の最新水準が気になる
ある空間の動画があるとき、今は実際にそれをどうやって3Dシーンに変換しているのか知りたい
この論文で説明されているシーン再構成プロセスの入力がまさにそれである
私の知る限り、SfMの基本的なアプローチはこの10年ほど大きく変わっておらず、SIFTのような画像特徴抽出、ヒューリスティックなマッチング、バンドル調整と外れ値除去に要約できる
一般的なフォトグラメトリが答えであり、NeRF式のアプローチへの関心と実用性も徐々に高まっている
ただ、動画であるという事実だけから推論できる追加の空間関係がもっと注目されていないのは驚きだ。フレーム間でカメラは特定の方法でしか動けないという制約を、カメラ姿勢推定に使えそうに思える
スプラットされたガウシアン上でmarching cubesを走らせてメッシュを取り出すという考えはあるが、まだ実際にやった例は見たことがないと思う
90年代後半に blob でボクセルの等値面をレンダリングしていた
3Dボクセル配列全体から表面ボクセルをスキャンし、局所的な密度勾配で法線を計算したうえで、240個のいずれかに量子化していた
その後、変位ベクトル表を使って表面ボクセルのチェーンを作り、ほとんどのボクセルは前のボクセルからの変位インデックスと法線ベクトルインデックスという2バイトだった
240個の法線ベクトルに対するライティングは事前計算してルックアップテーブルに入れておき、ソフトウェアがzバッファに小さな色付きの円を非常に高速に描画できた
当時の大きな不満は遠近法を使えなかったことだ。変位ベクトルをフレームごとに画面空間へ変換していたため、blobを描き、オフセットし、色を参照し、また描く、という形だった。チェーンの終端と次の絶対位置の格納を示す変位値が1つあったが、ほとんどのボクセルは2バイトだった