Splats · function
splatBoundsVisible
Is any part of the box [boundsMin, boundsMax] inside the frustum?
Explained in Gaussian splats.
function splatBoundsVisible(view: ArrayLike<number>, projection: ArrayLike<number>, model: ArrayLike<number>, boundsMin: ArrayLike<number>, boundsMax: ArrayLike<number>): booleanimport { splatBoundsVisible } from '@driftengine/splats';Parameters
| Parameter | Type | Description |
|---|---|---|
view | ArrayLike<number> | |
projection | ArrayLike<number> | |
model | ArrayLike<number> | |
boundsMin | ArrayLike<number> | |
boundsMax | ArrayLike<number> |
In depth
The box is in the capture's own space, which is why this takes the model matrix rather than
a world-space box: SplatData computes its bounds while the packing loop is open, in whatever
frame the capture was authored in, and moving the box every frame would be work to reach the
same answer as moving the planes.
Answered before the sort, not after, and that is where the saving is. Drawing a capture that is out of frame costs one draw call the rasteriser throws away; sorting it costs a linear pass over every splat it has, in a worker, for a picture nobody sees. Culling after the sort would save the cheap half.
Conservative: a box that touches the frustum is visible. The test is whether some plane has the whole box behind it, which is exact for rejection and admits a few boxes near a corner that are outside every plane pairwise but inside none singly. What that costs is a sort for a capture just off the corner of the frame; what would make it wrong is the opposite error, which loses a picture — so the asymmetry is deliberate.
projection is the caller's own, before the backend's clip correction: the planes below are
the OpenGL convention that mat4.perspective produces, and a corrected matrix has moved z into
[0, 1] and flipped y, so the near plane extracted from one would be wrong.