getBoundingBox() returns a growing, non-deterministic box for Streamed-LOD (.rad) SplatMesh

[shota-hamamatsu]

Summary

For a SplatMesh loaded from a Streamed-LOD (.rad) source via paged: true, getBoundingBox() does not return a deterministic, file-derived bounding box:

1. Immediately after construction (even after await mesh.initialized resolves), it returns a Box3 with min = (Infinity, Infinity, Infinity) and max = (-Infinity, -Infinity, -Infinity).
2. Once rendering starts, it begins returning a finite box, but that box only reflects whichever LOD chunks have been fetched and decoded so far. As streaming progresses over more frames, more chunks become resident and the box keeps growing — it's a snapshot of "currently loaded" data, not the full dataset. There's no clear point at which the box is guaranteed to represent the complete, true extent of the file.

There doesn't currently seem to be a way to obtain one fixed bounding box for the full splat set, independent of how much of the stream has loaded.

Expected Behavior

A way to obtain a single, deterministic bounding box covering the full splat set for a Streamed-LOD SplatMesh, independent of how much of the stream has loaded so far.

Actual Behavior

• Right after load: an Infinity-filled box.
• During/after streaming: a finite box whose size grows over time as more chunks load, with no signal for when (or whether) it has reached the true full extent.

[mrxz]

[...] it's a snapshot of "currently loaded" data, not the full dataset. There's no clear point at which the box is guaranteed to represent the complete, true extent of the file.

That's indeed the current trade-off made for the getBoundingBox method when using streamed LOD. Since the splats are loaded on demand and paged in and out, there's no guarantee that "the complete, true extent of the file" is ever reached at runtime. This also means that a proper bounding box can't be given based on the loaded data alone.

In terms of metadata the RAD format does not keep track of the chunk bounds, so this information is simply not present. That said the first chunk is supposed to cover/approximate the entire source file before the subsequent chunks target spatial subdivisions. Calling getBoundingBox(false) once the first chunk is loaded should give a rough approximate as it takes the size of the splats into account. That said, it won't be deterministic nor stable for the same above reason.

It might be possible to introduce a (pre-computed) bounding box in the RAD Metadata header, but this is going to be an AABB which depending on the transform applied to the SplatMesh can also fail to properly represent the actual bounding box.