Large SPZ decodes can hit the current WASM memory ceiling; should spz-loader consider a 4GB wasm32 build or memory64?

[danielzhong]

Description

We ran into a decoder crash in CesiumJS when loading large SPZ Gaussian splat datasets with high spherical harmonics degree.

In the failing case, the spz-loader WASM module aborted with:

Aborted(). Build with -sASSERTIONS for more info.

The dataset was approximately 4.9 million splats with SH degree 3. Based on our estimate, decoding required roughly 2.2 GB of peak memory, which appears to exceed the current WASM memory ceiling for the existing build.

On the Cesium side, we added a pre-flight estimate so we can fail gracefully before calling the decoder, instead of crashing the WASM module. But that only adds a guardrail on the client side.

This made us wonder whether spz-loader could support larger datasets directly.

Would you consider one of these directions?

• raising the current wasm32 build limit, for example with -s MAXIMUM_MEMORY=4GB
• exploring a separate memory64 build

Reference: CesiumGS/cesium#13283