Is lossless 3DGS display supported in CesiumJS?

CesiumJS
1

Hi, I have some questions about coordinate precision when displaying 3D Gaussian Splatting in CesiumJS.

I have built my own pipeline to create 3D Tiles using KHR_gaussian_splatting + KHR_gaussian_splatting_compression_spz_2, and have confirmed that rendering works correctly.

However, I have found that SPZ compression introduces rounding errors due to quantization — specifically, positions are stored as 24-bit fixed-point integers with fractionalBits=12. While I understand this is unlikely to cause visible artifacts in most cases, I am exploring options for higher-precision or lossless display for use cases such as surveying and infrastructure inspection.

I would appreciate clarification on the following points.

Question 1: Support for KHR_gaussian_splatting without SPZ compression

Does CesiumJS currently support loading a glTF tile content that uses KHR_gaussian_splatting alone, without KHR_gaussian_splatting_compression_spz_2? Or is the internal implementation built around SPZ decoding, such that a non-SPZ glTF would either fail to display or fall back to point cloud rendering?

Question 2: Support for non-default fractionalBits in SPZ

In the SPZ library, packGaussians currently hardcodes fractionalBits=12. However, the format specification stores this value in the file header, and the decoder is designed to read it dynamically. Does the CesiumJS SPZ decoder correctly handle fractionalBits values other than 12 — for example, 14 or 16?

Question 3: Recommended approach for lossless display

Is there any supported path in CesiumJS to display 3DGS data at full float32 precision, without quantization error? If no such path currently exists, are there any plans to support this in the future?

For context, our target use cases involve precision-critical applications such as surveying and infrastructure monitoring.

Thank you in advance for any guidance.

2

(I moved this to the CesiumJS section)

Quick, short answers to the questions:

1. CesiumJS does currently not support assets that only use the KHR_gaussian_splatting extension. It assumes that the assets are using the KHR_gaussian_splatting_compression_spz_2 extension. Support for the “base extension” will likely be added at some point, but I don’t know specific plans or a timeline here (maybe someone else can chime in)

2. CesiumJS uses GitHub - drumath2237/spz-loader: 🦎 .spz 3D Gaussian Splatting format data loader packages for loading the SPZ data. To my understanding, this is just a WASM wrapper around the original library. So it should be able to correctly interpret the fractional bits information. (I have not yet dedicatedly tried it out, but cannot imagine how it could not support them…)

3. See 1. :slight_smile:

3

Thank you for your response! I accidentally posted in the wrong section.

Thank you for the explanation. So, to summarize, it is currently not possible to display 3DGS data without quantization in CesiumJS. I believe there are valid use cases that require high coordinate precision, and I hope this will be supported in the future. If you have any workarounds or alternative approaches, I would appreciate you sharing them.

The fractional bits information should be interpreted correctly.

I share the same understanding on this point. However, even if we increase the number of fractional bits to ensure coordinate precision, the total coordinate size is fixed at 24 bits — meaning a larger fractionalBits value simply narrows the representable range, which doesn’t seem very practical. Am I wrong in thinking this?