Voxelization exceeds maxBufferSize when uploading a 149M-Gaussian LCC2 scene #343

Summary

Confirmed on the unmodified npm release splat-transform 3.9.0 (435b972): converting a large LCC2 scene to a whole-scene voxel asset fails while uploading the input Gaussians to a single GPU buffer. The requested buffer is 9,508,607,296 bytes, while the adapter reports maxBufferSize = 4,294,967,295.

This is an input-buffer limit, distinct from the large spatial-volume / voxel-block collection failures discussed in #253.

Environment and input

• Retested on 2026-10-02; npm package @playcanvas/splat-transform@3.9.0, dependency webgpu@0.4.0.
• macOS 27.0 (26A428), Node.js v22.22.1, arm64.
• Apple M3 Ultra, 32 logical CPU cores, 80 GPU cores, 512 GiB unified memory.
• Adapter limits: maxBufferSize = 4294967295, maxStorageBufferBindingSize = 4294967295.
• Scene: Huafa Ice and Snow World (华发冰雪世界), XGRIDS LCC2; 9 LODs, 297,170,328 scene Gaussians in total; LOD0 = 148,571,989. The separate environment has 23,974 Gaussians.
• The source LCC2 and its 1,083 referenced SOG files were already cached on the internal SSD. No additional transformations, filtering, fill, or carve options were applied. NODE_OPTIONS was unset.

Reproduction

The reproduction currently requires the large scene; the original capture is not attached. This is a production-data reproduction, not yet a publicly downloadable minimal reproducer.

npm install --prefix ./repro-toolchain --save-exact @playcanvas/splat-transform@3.9.0
mkdir -p out
node ./repro-toolchain/node_modules/@playcanvas/splat-transform/bin/cli.mjs scene.lcc2 out/lod0.voxel.json

Relevant log excerpt (local paths removed):

splat-transform v3.9.0 (435b972)
  · 149M gaussians · 0 SH bands
  ▸ Build voxels
    ▸ Building BVH
    ✗ WebGPU error: Buffer size (9508607296) exceeds the max buffer size limit (4294967295).
 - While calling [Device].CreateBuffer([BufferDescriptor """"]).
 — aborting (a corrupted GPU result must not be written)
    failed in 43.541s
  failed in 1m45.487s

The process exited with code 1, after approximately 111 seconds as observed by our 5-second sampler. There was no .voxel.json or .voxel.bin output. Sampled peak process RSS was 14.78 GiB. Many subsequent invalid-buffer WriteBuffer errors followed the first validation error.

Why voxel-size tuning does not address this failure

In v3.9.0 uploadAllGaussians, the GPU allocation is numRows * 16 * 4 bytes:

148,571,989 * 64 = 9,508,607,296 bytes

The staging upload is chunked, but it still targets one GPU buffer. This is a code-based explanation of the observed error; it is not a claim that all other limits would disappear after this allocation is fixed.

We previously hit the same requested buffer size and maxBufferSize error in 3.3.3 with both the default voxel settings and --voxel-size 0.08 --voxel-opacity 0.2. Those two parameter variants were tested in September; this 3.9.0 retest ran the default case once. An earlier 2.1.1 scene also requested a 14,208,382,720-byte input buffer against the same 4,294,967,295-byte limit.

Expected behavior / workaround

Ideally voxelization would batch or spatially partition the input so that a scene exceeding one GPU buffer can be processed. If this is outside the intended scope, an early capacity check with the estimated input limit and supported partitioning guidance would be useful, before loading the entire LOD0 and issuing repeated invalid-buffer writes.

Our workaround was to voxelize spatial tiles with 2.4.0, selecting and clipping the intersecting source SOGs. It produced 32 valid tiles; seven other planned tiles were empty after exact clipping because the conservative node bounds had intersected. This is a custom workflow and does not establish that tile boundaries and whole-scene collision behavior are fully equivalent to a native whole-scene result.