Top
Best
New

Posted by ibobev 8 hours ago

Gaussian Point Splatting(momentsingraphics.de)
143 points | 50 commentspage 2
lucamark 7 hours ago|
This feels like Monte Carlo rendering applied to rasterization. I'm wondering if it's a brand-new or a well established methodology
pixelesque 7 hours ago||
It's not new - that was sort of my point with my other comment.

At least if it's progressive (so refines and resolves over time), this has been done with pointclouds in the VFX industry in GPU shaders for years in terms of stochastically drawing different points so eventually the whole point set gets rasterised to a fidelity threshold.

lucamark 7 hours ago||
ookay, thanks for the clarification! So, the interesting part here seems to be the 3DGS-specific opacity correction and GPU workload mapping. Am I wrong?
pixelesque 7 hours ago||
Possibly yeah.

Or the per-pixel coord atomic I guess?

lucamark 7 hours ago||
Right, that part seems to be based on Schütz et al. 2021 https://arxiv.org/abs/2104.07526
avaer 7 hours ago|||
Monte Carlo in 3dgs is established enough that Spark [1] has been doing it for a while in the browser.

https://github.com/sparkjsdev/spark

cyber_kinetist 6 hours ago||
Cannot find anything related to Monte Carlo methods in the source code. I thought Spark implemented a conventional 3DGS pipeline with LoD optimizations (And it seems they do the sorting on the CPU using Rust/WebAssembly because of WebGL limitations)
convolvatron 3 hours ago||
that goes all the way back to the Kajiya rendering equation https://en.wikipedia.org/wiki/Rendering_equation
MattCruikshank 5 hours ago||
My dumb idea... do outdoor scans, and then convert the contents into 1m^2 blocks... And then, just dumbly stitch them together.

Kind of like Minecraft... but with user-generated gaussian-splat blocks.

jamilton 26 minutes ago|
1m^3, right? I can picture what you mean, but I'm not sure it works technically, since I think the splats for a given region are not actually bound to the region they represent. Like, for example, reflections work by having the reflection being physically behind the reflective surface. And they're all transparent, so it'd blend together.
MattCruikshank 8 minutes ago||
Sure, you could think in terms of 1m^3.

Yes, you're right that composing the best picture for an eye point could (and does) use splats from all over the scene.

But I think if you limit to splats that are (entirely, mostly, partially?) inside the 1m^3 block, you'll do pretty well. And you're absolutely right that reflective surfaces would probably be the first to suffer.

Well, it's worse than that. Because if you make a 1m^3 pond cube, and then I go putting trees around it, a naive rendering would still show YOUR reflections in the pond, rather than rendering from that pond's point of view, etc, like traditional rendering.

One of Gaussian Splats strengths, that it doesn't care... becomes a problem for me.

praveen9920 8 hours ago||
Sorting the gaussians is the compute heavy part in gaussian splatting. So, Im guessing this will give only marginal improvement in terms rendering speed.
xyzsparetimexyz 7 hours ago|
I'm not sure it does a sort. Each group of threads only handles a select number of gaussians
zokier 7 hours ago||
Yea, I think avoiding sorting is kinda the whole point here
cubefox 7 hours ago||
Their point splatting method is orthogonal to level-of-detail rendering (they reference a few papers which try to do this), so both point splatting and LoD could be combined in the future for an even greater performance gain during rendering. They already implement occlusion and frustum culling.

Point splatting does introduce a lot of noise though, and their denoiser introduces ghosting, but they say a more sophisticated denoiser would give considerably better quality.

pixelesque 8 hours ago||
> millions of threads

Really?! What OSs can handle that many native threads?

Also, this seems quite similar to stochastic progressive drawing of pointclouds for realtime that has been done for > 15 years in the VFX industry with GPU shaders in a tiled/bucketed fashion, unless this isn't progressive maybe? (The fact it's been accepted for Siggraph likely indicates it's slightly different).

Calavar 8 hours ago|
I believe they mean GPU threads. Plenty of cuda files in their repository.
pixelesque 7 hours ago||
Fair enough, but that's then only absolutely max 1024 threads per SM, which wouldn't get anywhere near 1 million, given 5090 only has 192 SMs...

Future proofing I guess...

cyber_kinetist 7 hours ago|||
You can launch much more logical threads than the available physical threads. The GPU scheduler will automatically dispatch the work to the SMs.
ks6g10 4 hours ago||||
Just like 2 threads can execute on the same core at the "same" time, i.e. no synchronization, the same is true for GPU threads/ thread groups.
zipy124 7 hours ago|||
I guess they never say that they execute at the same time technically haha
DamnInteresting 4 hours ago|
Video overview of the technology: https://www.youtube.com/watch?v=X8yRlA7jqEQ

Ordinarily I don't prefer video, but the visuals are helpful here.

Also, an online interactive, but it seems to only work in Chrome: https://superspl.at/scene/ff1d0393