Class Frustum

The six clip planes of a view-projection matrix (§87) — the primitive a frustum cull tests against.

viewProjection.copy(camera.projectionMatrix).multiply(camera.viewMatrix);
frustum.setFromViewProjection(viewProjection);
if (frustum.intersectsSphere(center, radius)) draw(item);
Copy

§87 lists the spatial structures a culler may sit on — AABB tree, quadtree, octree, BVH, grid, the physics broad phase — and is silent about the test at the bottom of all of them, which is this: a bounding volume against the six half-spaces that bound what a camera can see. This class is that test and nothing else. It builds no index, holds no scene, and caches nothing, so it is equally the leaf of a future BVH walk and the whole of the linear scan @fourjs/render's per-view list does today.

Why a sphere is the only volume it accepts

A sphere is invariant under rotation, so a world-space bounding sphere is one point transform and one scalar — where a world-space AABB has to be re-derived from the local box every time the node turns. That makes the per-item cost of culling a constant that does not depend on the item's orientation, which is what lets the cull run over every item of every view every frame. The price is that a sphere around a long thin box is loose, so this test keeps some items a box test would have rejected. It never rejects one a box test would have kept: a false keep costs a draw, a false reject costs a missing object, and only one of those is a bug.

@fourjs/render's computeWorldBoundingSphere is the producer; it derives the sphere from §53's cached local AABB.

Storage

Six planes in one Float64Array(24), four numbers each — (nx, ny, nz, d), the plane n · p + d = 0 with n a unit normal pointing into the frustum, so n · p + d is a signed distance in world units and can be compared against a radius directly. The order is left, right, bottom, top, near, far; nothing outside this class depends on it, and the flat array is what keeps a build allocation-free (§7b, plan D7).

Determinism (§33)

same-runtime, and no better: normalizing a plane needs Math.sqrt, whose result is exactly specified by IEEE-754 but which sits in the same Math family §33's same-platform tier tells simulation paths to avoid. That is not a problem here and is worth stating precisely rather than quietly: nothing this class computes reaches a solver, a checksum, or a snapshot. A cull decision changes which draws are submitted, never a number the simulation carries forward, so a replay recorded on one engine reproduces bit-exactly on another even if the two disagree about whether one marginal item was drawn.

Validation (§85, §61)

Nothing here throws — @fourjs/math validates nothing (the rule Matrix4.setPerspective states), and this class is read inside a frame, where §61 forbids throwing outright. Instead every degenerate input fails towards drawing: a plane whose normal has no length (a singular or non-projection matrix) is written as the everything-inside plane, and a NaN centre or radius makes Frustum.intersectsSphere answer true. A frustum nobody configured therefore culls nothing, which is the only safe direction for a filter that removes draws.