Live data from Hacker News

Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

sparkjs.dev

41–50 of 90 posts

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#41

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

Thanks! Notice 12MB steak sandwich is the biggest of them all. Rest are Fancier compression methods are coming (e.g SOGS). This is 30MB!

https://vincentwoo.com/3d/sutro_tower/

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#42
post #41

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

Thanks! Notice 12MB steak sandwich is the biggest of them all. Rest are Fancier compression methods are coming (e.g SOGS). This is 30MB! https://vincentwoo.com/3d/sutro_tower/

thanks for that link, i found it really cool.

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#44
post #41

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

Thanks! Notice 12MB steak sandwich is the biggest of them all. Rest are Fancier compression methods are coming (e.g SOGS). This is 30MB! https://vincentwoo.com/3d/sutro_tower/

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.

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#46
post #45

We seem to have to poles: extreme realism, and extremely minimalistic pixel art. I prefer the second camp. But your project looks really important in the first camp.

Thanks! It works for both! An under-explored area is converting into splats assets created in “traditional” ways (e.g blender). Better visual results in some scenarios (high freq detail). See the furry logo in the homepage carousel.

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#47
Very very cool.

Do you have any insights into the current performance bottlenecks? Especially around dynamic scenes. That particle simulation one seems to struggle but then improves dramatically when the camera is rotated, implying the static background is much heavier than it appears.

And as a counterpoint to the bottlenecks, that Sierpinski pyramid, procedurally, is brilliant.

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#49
post #48

any chance this will support the video style 3d gaussian splats?

Yes. We have demos working already. Those 3D gaussian videos (or 4D that some people call) are really big so we're figuring out what's the best way to distribute and make it a great experience.

Re: Show HN: Spark, An advanced 3D Gaussian Splatting renderer for Three.js

#50

Very very cool. Do you have any insights into the current performance bottlenecks? Especially around dynamic scenes. That particle simulation one seems to struggle but then improves dramatically when the camera is rotated, implying the static background is much heavier than it appears. And as a counterpoint to the bottlenecks, that Sierpinski pyramid, procedurally, is brilliant.

Number of splats in the scene and distribution have an impact on performance. Probably in your case you turned the camera in a direction with less splats. There's definitely work to do to deliver consistent performance. We'll probably look into an LOD system next.
Post reply on HN