KHR_gaussian_splatting#2490
Conversation
Co-authored-by: Adam Morris <adam@kernelpanicstudios.com>
Co-authored-by: Adam Morris <adam@kernelpanicstudios.com>
…e extension rather than building on KHR_gaussian_splatting
…DME.md Co-authored-by: Sean Lilley <lilleyse@gmail.com>
…DME.md Co-authored-by: Sean Lilley <lilleyse@gmail.com>
…DME.md Co-authored-by: Sean Lilley <lilleyse@gmail.com>
…DME.md Co-authored-by: Sean Lilley <lilleyse@gmail.com>
Co-authored-by: Sean Lilley <lilleyse@gmail.com>
Co-authored-by: Sean Lilley <lilleyse@gmail.com>
|
It appears that this extension is tied to the Niantic Spatial library. Is it necessary to specify a version or other unique identifier to ensure that the desired algorithm and calling sequence is used? Also note that the license for the Niantic Spatial library is MIT. |
Good question. The SPZ library packs along a version number within the binary data that we store in the buffer, so it's unnecessary to have a version number stored in the glTF metadata. |
|
I've added some clarity to the Spherical Harmonic section and removed the shader examples. To ensure we are covering everything, I've also included details about the Condon-Shortly phase which newcomers to Spherical Harmonics may not know about. |
|
(Minor glitches in the last table, just mentioning). Is the plan to add some reference shader later? It's probably not necessary from a normative point of view, but could be helpful if someone wants to implement things from scratch. If so, it could make sense to align whatever is supposed to be added here with what is done in the glTF-Sample-Viewer. (That is: It would be nice if the shaders here could (basically) "be" the ones that are used in the sample viewer, give or take some minor details) |
No, we discussed this earlier. We can't include a shader normatively anyhow, and the truth is that shader implementations are going to have enough engine and use-case specific needs that an example will probably be misleading. There are quite a lot of really solid production examples of 3D Gaussian Splatting shaders that are open source, so for the purposes of the shaders it's best if people use those as examples. |
|
I am also going to update the PR post at the top just so it's clear where we're at. It's way overdue. I have this in progress right now but wanted to just give a heads up since I don't think I'll have it done for another hour or so due to meetings. |
|
@lexaknyazev What is the plan for merging this? At this point everything is resolved, and I think we're good to go. |
|
@lexaknyazev Should be good to go. |
@weegeekps Maybe I am wrong. On page 28ff, the formulas are resolved and for the higher degrees it looks different:: |
|
Apologies for missing the packing order piece for SH. That's fixed now.
Those equations on page 28 are not fully reduced. They're equal with what we have. |
Can u cross check l=3 and m=0? Otherwise then I am okay. |
They're equal. |
20 participants
Update: I've split out KHR_gaussian_splatting_spz_2 into it's own PR. There's been many changes since I wrote the summary, and while I'm leaving it at the moment. It will be updated soon.
This extension proposal,
KHR_spz_gaussian_splats_compression, allows for efficient storage of 3D Gaussian splats data within glTF using the SPZ compression library from Niantic Spatial. The extension is applied to a primitive. The SPZ binary blob is stored as a buffer within the glTF file, and implementations can use the SPZ library to either decompress and then map the compressed Gaussians into placeholder attributes on the primitive or directly decompress into their rendering pipeline if preferred. Content creators have the flexibility to choose to use no Spherical Harmonics, or up to all 3 degrees of spherical harmonics depending on their use case.We are currently working on an implementation in the CesiumJS engine based on this draft that we hope to have released soon.