Also famous splats from the beginning are stored in .splat [hugginface link]
We load splat files in our [ own splat renderer ], but because yours is much more stable we want to switch. If you not planning to load splat files we need to implement a converter. But since you are already export splat files, I donât want to write stuff you might have already on the roadmap (again )
PS: The splat format also makes it very easy to stream the data. I saw some streaming with PLY as well but not that efficient.
Wow, thatâs seriously cool! Nice job. Wondering whether it might make sense to uncheck Device Pixel Ratio for this demo - pixel fill is going to be pretty expensive for scenes like that.
@slimbuck the PlayCanvas Gaussian splatting is so great! It is the fastest web implementation I have seen. Especially on macOS, its FPS is almost 3x~4x that of other WebGL implementations (such as Three.js or GSplat.js). I wonder how this is achieved?
I have gone through the code, and the major workflow looks similar. One of the core differences with others is that PlayCanvas uses fewer instances (128 splats for each instance). However, when I adjust the number from 128 to 1, meaning the full number of instances are used, the FPS only decreases slightly, less than 5%.
I am using non-compressed PLY data, and the FPS is calculated when the camera is static (meaning the sorting is not updating). I have also turned off antialiasing, and use max pixel ratio for all other implementations. I am really curious about what other huge optimizations you geniuses are doing to make it so fast.
I believe the big win youâre seeing is reordering the data so that splats nearby to each other in world space are nearby in memory also. This results in significant memory cache speedups on GPU at render time thanks to memory caching. (Itâs actually a little strange just how random the splats appear in PLY files generated from training).
Oh, this is an amazing job. I attempted to return directly in reorderData(), and the FPS dropped from 23 to 18.
When I compared it with other WebGL implementations on MacOS, they only achieved FPS around 6. It seems there is still something more to the reordering process.
Finally I found that the result is possibly due to a bug in Chromium on Intel MacBooks. For Chrome on the Retina screen of Intel MacBooks, rendering directly to the canvas is slower than rendering to a texture. It seems to resemble a multisample/antialiasing-related misuse, but after numerous experiments, I believe it is an internal chromium bug and have submitted an issue.
PlayCanvas always renders to a render target (RT), so its performance is better in my case.
PlayCanvas does not always render to a render target. If multisampling is disabled, we render directly to the default framebuffer. (unless the users set up to render to a RT, either manually, or by using post-effects or similar).
But in the simplest case in the Editor, when using GS you typically disable multi-sampling, and it would render directly to the default framebuffer.
Oh my bad, I meant in the SuperSplat project, the GS are by default rendered to framebuffer and then to the canvas.
For example, in my environment, I captured GL commands with Spector.js. I observed that drawElementsInstanced (the time-comsuming part) was drawn to âframebuffer 1â and then drawn to the âcanvas framebufferâ as a quad.
)
