Leverage lightgaussian for better performance and much smaller sizes

[LifeIsStrange]

Lightgaussian is significantly faster than the original gaussian splatting (and btw generates scenes ten times smaller)
https://lightgaussian.github.io/

[jatentaki]

What are you proposing? To use pruned and distilled scenes with the renderer? Or to implement the o tree/code book "cherry on top" they propose? The former seems orthogonal to the viewing software (this repo), the latter is quite complex to implement while there are many lower hanging fruit to collect (such as adjusting our code to use half precision in the first place)

[LifeIsStrange]

Well I was thinking about the former > To use pruned and distilled scenes with the renderer
I wonder if it is compatible out of the box
and yes the renderer seems hortogonal albeit I'm not sure wether they have new renderer related optimizations, (and they haven't yet open sourced all their code)
but I mostly wanted to give visibility to this paper as lowering asset size and improving performance is key to the democratization for web use cases.

[LifeIsStrange]

Anyway feel free to clause this issue but IMO lightgaussian is at least worth mentioning in the Readme for end users?

BTW regarding optimization low hanging fruit, splat sorting via radix sort generally take a large part of the total performance, and I wonder wether the state of the art library from AMD could be automatically ported to the web via esmcripen?
https://gpuopen.com/fidelityfx-parallel-sort/
https://github.com/emscripten-core/emscripten
edit no, while emscripten can autotranslate opengl to webgl, there does not seem to be a way to translate vulkan to webgl/webgpu so the implementation would have to be manually translated