Streaming a place that changes: sort order, node visibility, and the cost of a second of motion

Start from where the static side actually is, because the numbers set the budget everything else has to fit inside.

Our own renderer draws a frame in 8.5 ms against 12.1 for the engine path on a GTX 1050, and 56 against 74 on an integrated UHD 620. Broken down with GPU timestamps on la-sarraz with 5.87 million splats shown: projection 2.15 ms, sort 1.06 ms, draw 5.2 ms on the 1050, and 14.8, 5.7 and 43.8 on the UHD 620. The integrated part is the one that matters, because it is the machine most people have.

On top of that, a visibility bake measured on 2026-10-04. The question was how much occlusion culling is worth once frustum culling has already run, which is the honest way to ask it, since frustum culling is free and already there. Margin over frustum-only, as a median across sampled viewpoints: aix 93.7 per cent, lourmarin 93.1, la-filature 85.8, la-sarraz 79.2, ludlow 58.4. At the tenth percentile, which is the bad case rather than the typical one: 44.8, 34.1, 29.9, 21.4 and 0.0. The bitset that carries this ships at 6 to 85 kB gzipped.

Ludlow scoring zero at the tenth percentile is the method showing its limit rather than an error. Ludlow is cut into 102 nodes, which makes each box big enough that some part of it is visible from almost anywhere, and a box that is partly visible has to be drawn. The power of the bake scales with how finely the place is divided. That is a knob, and it is the next thing to turn.

To be clear about status: the bake and its contract tests exist and the runtime is not wired to them yet. The numbers above are what the data says is available, not what the frame rate currently shows.

Now add time to the scene and three separate things get harder.

Sort. A splat scene draws in one global back-to-front order, and an object moving through the street has to take its place in that order every frame. Re-sorting everything because one bin moved is not affordable: the sort is already 1.06 ms on a 1050 and 5.7 on a UHD 620, and that is for a set that is holding still. The shape of the answer is to keep the static order and splice, since a moving object occupies a small contiguous span of depth and the street around it has not changed.

Storage. The literature here is encouraging without being a solution. QuARC-GS reports per-frame storage up to eleven times smaller, Struct-GStream goes after low-bitrate online free-viewpoint video, and the M3ISR benchmark now carries a 4DGS streaming track at all. The useful observation is that all of it is aimed at free-viewpoint video of a whole scene, which is a much larger problem than a two-second clip of one object inside an otherwise static street. Being a smaller problem is the only advantage I have here and it is worth spending.

Residency. A static place is fetched once and kept in a warm cache on disk. A clip matters only in the instant it is triggered, and a trigger is a collision, which gives no warning. So it is a prefetch problem keyed on proximity rather than a streaming problem keyed on the camera: the clip has to be resident before the player is close enough to cause it, or the first kick plays nothing.

Measured where it says measured. The rest is direction.