Reducing load time is already a good starter, because yes, I am covering quite some m2.
Hey @slimbuck, got any advice here? Should @Kulltur wait for official Editor support for SOGS, or go with the church tech demo approach?
In addition to that, could you give some insight into the current best practices for improving runtime performance? Any LOD strategies you’ve seen, or something similar? Could a more sparse Gaussian cloud be used for things not up close etc…
I am close to finish my Playcanvas Experience “Celestial Signs” for VIVEVERSE, and it is based on a 3DGS that’s nearly 500mb
Awesome, can’t wait to see this!
I assume that’s 500MB uncompressed.ply? If so, you should definitely consider using compressed.ply instead.
Regarding SOGS, we’re busy putting the final touches on the next engine minor release. This release will include better support for SOGS and a script can then be used to load and render in an editor project.
Because right now, it’s very laggy…
Ok this is interesting actually. I hadn’t realised how bad SOGS performance was. The reason SOGS renders slower is that the spherical harmonic data is stored as a palette of coefficients. Storing the data this way is memory efficient, but slow to render.
We should probably just bite the bullet and unpalette this data after downloading at runtime. This will mean more GPU memory usage, but it’s ultimately probably the right tradeoff.
I will have a chat with the team and perhaps we will update the SOGS loader for this engine release.
Thanks!
1 Like
Just to add, if you really need max performance, please consider training your scene without spherical harmonics. If the resulting quality is acceptable, then you will have tiny SOGS data and no performance loss.
1 Like