[HN Gopher] Show HN: Spark, An advanced 3D Gaussian Splatting re...
___________________________________________________________________
Show HN: Spark, An advanced 3D Gaussian Splatting renderer for
Three.js
I'm the co-creator and maintainer of https://aframe.io/ and long
time Web 3D graphics dev. Super excited about new techniques to
author / render / represent 3D. Spark is a an open source library
to easily integrate Gaussian splats in your THREE.js scene I worked
with some friends and I hope you find useful. Looking forward to
hearing what features / rendering techniques you would love to see
next.
Author : dmarcos
Score : 193 points
Date : 2025-06-11 17:02 UTC (5 hours ago)
(HTM) web link (sparkjs.dev)
(TXT) w3m dump (sparkjs.dev)
| pvg wrote:
| Slightly more obvious repo link
| https://github.com/sparkjsdev/spark
| moron4hire wrote:
| That interactive demo on the front page running perfectly fine on
| my Pixel 7 was pretty sick!
| erulabs wrote:
| Super impressive looking demo, works well on my older iphone.
|
| As an only-dabbling-hobbiest game developer who lacks a lot of 3d
| programming knowledge, the only feedback I can offer is you might
| perhaps define what "Gaussian Splatting" is somewhere on the
| github or the website. Just the one-liner from wikipedia helps me
| get more excited about the project and potential uses: Gaussian
| splatting is a volume rendering technique that deals with the
| direct rendering of volume data without converting the data into
| surface or line primitives.
|
| Super high performance clouds and fire and smoke and such?
| Awesome!
| dmarcos wrote:
| Thanks. We have to definitely add an FAQ
| praveen9920 wrote:
| Any plans to extend support for triangle splats?
| dmarcos wrote:
| We're definitely looking at it. No specific plans yet
| westurner wrote:
| PartCAD can export CAD models to Three.js.
|
| The OCP CAD viewer extension for build123d and cadquery models,
| for example, is also built on Three.js.
| https://github.com/bernhard-42/vscode-ocp-cad-viewer
| jasonthorsness wrote:
| The food scans demo ("Interactivity" examples section) is
| incredible. Especially Mel's Steak Sandwich looking into the
| holes in the bread.
|
| The performance seems amazingly good for the apparent level of
| detail, even on my integrated graphics laptop. Where is this
| technique most commonly used today?
| dmarcos wrote:
| There's a community of people passionate about scanning all
| short stuff with handheld devices, drones... Tipatat let us
| generously use his food scans for the demo. I also enjoy
| kotohibi flower scans: https://superspl.at/user?id=kotohibi
|
| Edit: typos
| jasonthorsness wrote:
| Wow what kind of device do I need to make my own?
| dmarcos wrote:
| The food scans are just photos from a Pixel phone processed
| with postshot (https://www.jawset.com/) to generate the
| splats
| ChadNauseam wrote:
| I'm sure it's not cutting edge, but the app "scaniverse"
| generates some very nice splats just by you waving your
| phone around an object for a minute or so.
| dmarcos wrote:
| Yes there are several phone apps to generate splats. Also
| Luma 3D capture.
| creata wrote:
| And the transfer size for that level of detail isn't that bad,
| either - only around 80MB. (Not being sarcastic, it's really
| neat.)
| dmarcos wrote:
| Yeah. And some of the individual scans like Clams and Caviar
| or Pad Thai are < 2MB.
| markisus wrote:
| The demos look great! I imagine it's not pure javascript. Are you
| using webgpu?
| dmarcos wrote:
| Just WebGL2
| shadowgovt wrote:
| The WebGL API is based on the OpenGL ES standard, which
| jettisoned a lot of the procedural pipeline calls that made it
| easy to write CPU-bound 3D logic.
|
| The tradeoff is initial complexity (your "hello world" for
| WebGL showing one object will include a shader and priming data
| arrays for that shader), but as consequence of design the API
| sort of forces more computation into the GPU layer, so the fact
| JavaScript is driving it matters very little.
|
| THREE.js adds a nice layer of abstraction atop that metal.
| two_handfuls wrote:
| This looks super cool! Would this work in VR if someone opens the
| web page from a web browser? Because that would be even more
| awesome!
| dmarcos wrote:
| It does work in VR! We'll have a demo available soon.
| two_handfuls wrote:
| Oh that's fantastic!
| akomtu wrote:
| Cool stuff. Do you have examples with semi-transparent surfaces?
| Something like a toy christmas tree inside a glass sphere, with
| basic reflections and refractions calculated?
| dmarcos wrote:
| Nothing top of mind like that. Check out people's scans at
| https://superspl.at/ Anything there should also render in
| Spark.
| akomtu wrote:
| https://superspl.at/view?id=8c35f06d rendered very well. This
| Spark is surprisingly fast: a 650 MB scene got rendered at
| 120 fps.
| nobbis wrote:
| Wait, you renamed Forge (https://forge.dev) released last week by
| World Labs, a startup that raised $230M.
|
| Is this "I worked with some friends and I hope you find useful"
| or is it "So proud of the World Labs team that made this happen,
| and we are making this open source for everyone" (CEO, World
| Labs)?
|
| https://x.com/drfeifei/status/1929617676810572234
| dmarcos wrote:
| Yes. I collaborated with one of the devs at World Labs on this.
| The goal is to explore new rendering techniques and popularize
| adoption of 3D gaussian splatting. There's no product
| associated with it.
| nobbis wrote:
| Understood. Thanks for the clarification.
| dmarcos wrote:
| We renamed due to a name collision with another renderer /
| tool.
| _tqr3 wrote:
| This is great, thanks!
|
| I have spent countless hours playing with the R3F - adding vertex
| and fragment shaders, eventually giving up. The math is just
| tedious.
| dmarcos wrote:
| We have a template for R3F you might find useful:
|
| https://github.com/sparkjsdev/spark-react-r3f
| vmesel wrote:
| hey @dmarcos! Congrats on the launch!
|
| from your fellow gh accelerator friend, vinnie!
| feiss wrote:
| Super cool! Congrats on the launch :))
| ertucetin wrote:
| This is cool also BabylonJS has nice gaussian splat support as
| well:
| https://doc.babylonjs.com/features/featuresDeepDive/mesh/gau...
| echelon wrote:
| BabylonJS and the OP's own Aframe [1] seem to have similar
| licenses, similar number of Github stars and forks, although
| Aframe seems newer and more game / VR focused.
|
| How do Babylon, Aframe, Three.js, and PlayCanvas [2] compare
| from those that have used them?
|
| IIUC, PlayCanvas is the most mature, featureful, and
| performant, but it's commercial. Babylon is the featureful 3D
| engine, whereas Three.js is fairly raw. Though it has some nice
| stuff for animation, textures, etc., you're really building
| your own kit.
|
| Any good experiences (or bad) with any of these?
|
| OP, your demo is rock solid! What's the pitch for Aframe?
|
| How do you see the "gaussian splat" future panning out? Will
| these be useful for more than visualizations and "digital
| twins" (in the industrial setting)? Will we be editing them and
| animating them at any point in the near future? Or to rephrase,
| when (or will) they be useful for the creative and gaming
| fields?
|
| [1] https://github.com/aframevr/aframe
|
| [2] https://playcanvas.com/
| dmarcos wrote:
| A-Frame is an entity component system on top of THREE.js that
| uses the DOM as a declarative layer for the scene graph. It
| can be manipulated using the standard APIs and tools that Web
| developers are used to. Initial target was onboarding Web
| devs into 3D but found success beyond. The super low barrier
| of entry (hello world below) without sacrificing
| functionality made it very popular for people learning
| programming / 3D (part of the curriculum in many schools /
| universities) and in advanced scenarios (moonrider.xyz ~100k
| MAUs (300k MAUs at peak) most popular WebXR content to date
| is made with A-Frame)
|
| One of the Spark goals is exploring applications of 3D
| Gaussian Splatting. I don't have all the answers yet but
| already compelling use cases quickly developing. e.g
| photogrammetry / scanning where splats represent high
| frequency detail in an appealing and relatively compact way
| as you can see in one of the demos
| (https://sparkjs.dev/examples/interactivity/index.html).
| There are great examples of video capture already
| (https://www.4dv.ai/). Looking forward to seeing new
| applications as we figure out better compression, streaming,
| relighting, generative models, LOD...
|
| A-Frame hello world
|
| <html> <head> <script src="https://aframe.io/releases/1.7.1/a
| frame.min.js"></script> </head> <body> <a-scene> <a-box
| position="-1 0.5 -3" rotation="0 45 0"
| color="#4CC3D9"></a-box> </a-scene> </body> </html>
| Joel_Mckay wrote:
| Did a test study in BabylonJS, and generally the subset of
| compatible features is browser specific.
|
| The good:
|
| 1. Blender plugin for baked mesh animation export to stream
| asset is cool
|
| 2. the procedural texture tricks combined with displacement
| maps mean making reasonable looking in game ocean/water
| possible with some tweaking
|
| 3. adding 2D sprite swap out for distant objects is trivial
| (think Paper Mario style)
|
| The bad:
|
| 1. burns gpu vram far faster than normal engines (dynamic
| paint bloats up fast when duplicating aliases etc. )
|
| 2. JS burns CPU cycles, but the wasm support is reasonable
| for physics/collision
|
| 3. all resources are exposed to end users (expect
| unsophisticated cheaters/cloners)
|
| The ugly:
|
| 1. mobile gpu support on 90% of devices is patchwork
|
| 2. baked lighting ymmv (we tinted the gpu smoke VFX to cheat
| volumetric scattering)
|
| 3. in browser games essentially combine the worst aspects of
| browser memory waste, and security sandbox issues (audio sync
| is always bad in browser games)
|
| Anecdotally, I would only recommend the engine for server
| hosted transactional games (i.e. cards or board games could
| be a good fit.)
|
| Otherwise, if people want something that is performant, and
| doesn't look awful.... Than just use the Unreal engine, and
| hire someone that mastered efficient shader tricks. =3
| socalgal2 wrote:
| I'm still highly skeptical of gaussian splatting as anything more
| than a demo. The files are too large. The steak sandwich is 12meg
| (as just one example)
|
| There was a guassain splat based Matterport port clone at least
| year's siggraph. To view a 2 bedroom apartment required streaming
| 1.5gig
|
| Cool demo
| dmarcos wrote:
| Thanks! Notice 12MB steak sandwich is the biggest of them all.
| Rest are < 10MB and several of those very compelling in the
| 1-3MB range (e.g: Iberico Sandwich 1MB, Clams and Caviar
| 1.8MB).
|
| Fancier compression methods are coming (e.g SOGS). This is
| 30MB!
|
| https://vincentwoo.com/3d/sutro_tower/
| athriren wrote:
| thanks for that link, i found it really cool.
| oofbey wrote:
| How much of the huge file size is because you need tons of
| splats to simulate a hard surface? Conceptually the splats
| seems flawed because gaussians don't have hard edges - they
| literally go to infinity in all directions, just at
| vanishingly small densities. So practically everybody cuts
| them off at 3 sigma or something, which covers 99.7% of the
| volume. But real-world objects have hard edges, and splats
| don't.
|
| Would the format work better if you made that cut-off at
| something like 1 sigma instead? Then instead of these blurry
| blobs you'd effectively be rendering ovals with hard edges. I
| speculate out loud that maybe you could get a better render
| with fewer hard-edged ovals than tons of blurry blobs.
| ge96 wrote:
| That steak made my mouth water, mission accomplished
| refibrillator wrote:
| Last year I spent a few weeks tinkering with the forward and
| backward pass of the original 3DGS implementation. Tried to
| implement it using WebGL shaders but quickly got in over my head.
| The original rasterizer is highly parallel and has two stages.
|
| First stage is gaussian parallel. The image is logically divided
| into tiles and the gaussians are "splatted" to 2D screen space.
| The extent of each splat is used to calculate which tiles are
| touched by a given gaussian. Ultimately you get a depth sorted
| list of gaussians that need to be considered in a given tile.
|
| Second stage is pixel parallel. Each pixel is treated by a GPU
| thread which walks the list, splats the gaussians in depth order
| and performs alpha compositing.
|
| Since the author is here, perhaps you could spare us from reading
| the code and describe how your implementation works in relative
| comparison?
___________________________________________________________________
(page generated 2025-06-11 23:00 UTC)