The .drft container · function
coarseFirstOrder
The order to write a capture's splats in, so that every prefix of the file is a complete sparse capture rather than a finished corner of one.
Explained in The .drft container.
function coarseFirstOrder(positions: Float32Array, count: number): Uint32Arrayimport { coarseFirstOrder } from '@driftengine/drft';Parameters
| Parameter | Type | Description |
|---|---|---|
positions | Float32Array | |
count | number |
In depth
This is the reason the container is worth having at all. Everything above it is a splat
viewer; a load that opens on a recognisable place and densifies is what a viewer streaming from
a plain file cannot do by accident. It is the same trick coarseLevel.ts plays for meshes,
where a decimated whole body reads as a car and one finished wheel does not.
Two steps, and both are needed:
- Sort by Morton code, so index order becomes spatial order. Without this the sequence
below decimates whatever order the trainer happened to leave — which is usually fine and is
a slab of one axis when it is not, and the difference is invisible until somebody opens a
capture that was written out in scan order.
coarseFirst.test.tsbuilds exactly that case. - Walk that order bit-reversed, which is the van der Corput sequence and is what makes each block a sparse capture rather than only the first. Reversing the bits of a counter visits 0, half way, quarter, three quarters, and so on, so consecutive slots are maximally far apart in the spatial order and every block is an even scattering over the whole thing.
What it costs is a sort at bake time — O(n log n) once, on a machine with a keyboard — and
nothing at all at load. What would make it wrong is a capture meant to be read in its
authored order, which this format has no notion of: a .drft splat chunk is a set, and a
consumer that needed the original indices would need them stored.