Spark - Three.js向けの高機能3D Gaussian Splattingレンダラー

 (sparkjs.dev)
3 ポイント 投稿者 GN⁺ 2025-06-13 | 1件のコメント | WhatsAppで共有
  • Sparkは、Three.jsシーンで3D Gaussian Splattingをレンダリングするために作られた高機能レンダラー
  • World Labsが開発し、既存のシーン内で他のメッシュとsplatを一緒に配置できる
  • すべてのデバイスで高速レンダリングを目標とし、さまざまな環境でsplatコンテンツを扱うことに重点を置く
  • プログラム可能な動的splat効果をサポートし、静的な表示を超えてシーン内の効果を構成できる
  • ply、sogs、spz、splat、ksplatなど複数の形式をサポートし、公式ドキュメントからすぐに始められる

Three.jsシーンに統合されるsplatレンダラー

  • SparkはThree.js向けの3D Gaussian Splattingレンダラー
  • World Labsが開発
  • 既存のThree.jsシーンに統合し、他のメッシュやsplatと一緒に使用できる

レンダリング機能と対応形式

  • すべてのデバイスで高速レンダリングを提供すると案内されている
  • プログラム可能な動的splat効果をサポート
  • 対応形式は次のとおり
    • ply
    • sogs
    • spz
    • splat
    • ksplat
  • スタートガイドはGet startedで提供されている

関連記事

1件のコメント

 
GN⁺ 2025-06-13
Hacker Newsのコメント

  • デモは本当に印象的で、古い iPhone でもよく動く。
    3D プログラミングの知識があまりない趣味のゲーム開発者としては、GitHub や Web サイトのどこかにでも ガウシアン・スプラッティング が何なのかを一言でも定義してくれるとうれしい。
    Wikipedia の「ガウシアン・スプラッティングは、データを表面や線のプリミティブに変換せず、ボリュームデータを直接レンダリングするボリュームレンダリング手法」程度の説明だけでも、このプロジェクトや活用可能性への期待がずっと高まる。
    高性能な雲、火、煙のようなものが作れるなら本当にすばらしい。

    • FAQ はぜひ追加すべきだと思う。

  • 食べ物スキャンのデモ、とくに「Interactivity」の例示セクションがすごい。
    Mel's Steak Sandwich でパンの穴の内側をのぞき込む場面が特によく、見えているディテールの水準に対して、統合グラフィックスのノート PC でも性能が驚くほど良い。
    この技法が今どこで最も一般的に使われているのか気になる。

    • ハンドヘルド機器やドローンで短時間に物体をスキャンすることに熱心なコミュニティがある。
      Tipatat がデモ用の 食べ物スキャン をたっぷり提供してくれていて、kotohibi の花のスキャンも気に入っている: https://superspl.at/user?id=kotohibi
    • そのディテール量にしては転送サイズも悪くない。約 80MB しかない。
      皮肉ではなく、本当にきれいにまとまっている。

  • これもすばらしいし、BabylonJS のガウシアン・スプラッティング対応もかなり良い: https://doc.babylonjs.com/features/featuresDeepDive/mesh/gau...

    • BabylonJS と元記事の Aframe [1] はライセンス、GitHub のスター数やフォーク数が似ているように見えるが、Aframe のほうが新しく、ゲーム/VR により焦点を当てているようだ。
      Babylon、Aframe、Three.js、PlayCanvas [2] を使ったことがある人の視点でどう比較されるのか気になる。
      私の理解では、PlayCanvas は最も成熟していて機能が多く性能も良いが商用寄り、Babylon は機能豊富な 3D エンジンで、Three.js はかなり素に近い。アニメーションやテクスチャなど良い要素はあるが、結局は自分でツールセットを組み立てる感覚になる。
      これらについて良い経験や悪い経験がある人がいれば聞いてみたい。
      デモは本当に安定している。Aframe の中核的な魅力は何なのか気になる。
      ガウシアン・スプラッティング の未来がどう展開するのかも気になる。可視化や産業向けの「デジタルツイン」以上の用途が生まれるのか、近い将来に編集やアニメーション化が可能になるのか、創作やゲーム分野でいつごろ実用的になるのか知りたい。
      [1] https://github.com/aframevr/aframe
      [2] https://playcanvas.com/

  • リポジトリへのリンクが少し見やすいように、ここにも置いておく: https://github.com/sparkjsdev/spark

  • とてもすばらしい。
    現在 性能ボトルネック がどこにあるのか、特に動的シーンについて何か知見があるのか気になる。
    パーティクルシミュレーションの例はカクつくが、カメラを回転すると大幅に良くなり、静的背景が見た目以上にかなり重いようだ。
    一方で、ボトルネックとは別に、手続き的に作られた Sierpinski ピラミッドは見事だ。

    • シーン内の スプラット数 と分布が性能に影響する。
      おそらくカメラを、より少ないスプラットがある方向へ向けたのだと思う。
      一貫した性能を出すにはまだやるべきことが多く、次はおそらく LOD システム を見ていく予定だ。

  • まだガウシアン・スプラッティングがデモ以上の意味を持つのかについてはかなり懐疑的だ。
    ファイルが大きすぎる。たとえばステーキサンドイッチ 1 つで 12MB ある。
    昨年の SIGGRAPH にはガウシアン・スプラッティングベースの Matterport のクローンがあったが、2 部屋のアパートを見るのに 1.5GB をストリーミングしなければならなかった。
    デモ自体はすばらしい。

    • 12MB のステーキサンドイッチがその中でも最大級だという点も見るべきだ。
      残りは 10MB 未満で、かなり説得力のあるもののうち複数が 1〜3MB の範囲にある。たとえば Iberico Sandwich は 1MB、Clams and Caviar は 1.8MB だ。
      さらに高度な圧縮方式も出てきている。たとえば SOGS がある。これは 30MB だ。
      https://vincentwoo.com/3d/sutro_tower/
    • SOGS 圧縮 はうまく機能する。
      球面調和係数をすべて含む 100 万個のガウシアンを約 14MB に収められる。
      PlayCanvas のブログに良い記事がある: https://blog.playcanvas.com/playcanvas-adopts-sogs-for-20x-3...
    • 大きなファイルサイズの大半は 球面調和係数 の保存によるもので、これは解決可能な問題だ。

  • 仕事はすばらしいが、Nvidia RTX A3000 GPU 搭載ノート PC の Firefox では性能がかなり悪い。
    ここには 1 度のやけどを起こせるだけの シェーダーコア が十分にある。

    • それは特定のデモや例での話？

  • 携帯電話を持って歩き回りながら、芝生、茂み、土のようなものの ガウシアン・スプラット をキャプチャできるだろうか。
    そして 1 メートル四方の地面の断片や、茂みを含む 1 メートル立方の領域を選んで、芝生ブロックを繰り返し敷き、ときどき土や茂みを混ぜて「Minecraft のように見える」世界を作れるだろうか。
    数千個のブロックをレンダリングするには、かなり強力なハードウェアが必要になりそうだ。

    • そういうプロトタイプは十分作れそうだ。
      実際に見たら本当にすごいと思う。

  • 本当にすごそう。
    Web ブラウザで Web ページを開いたときに VR でも動くだろうか？ そうならさらにすごい。

    • VR でも動く。まもなくデモを公開する予定だ。