@driftengine/core 3.61.0

package/dist/render/cinematicCamera.js

@@ -0,0 +1,227 @@
+import { clamp } from '../math/scalar.js';
+import { Boom } from './boom.js';
+import { Spring } from '../math/spring.js';
+import { segmentHit } from '@driftengine/physics';
+import { Camera } from './camera.js';
+import { createShotPlacement, flybyStation, placeShot } from './shotPlacement.js';
+/**
+ * How fast the rig converges within a shot, in 1/seconds. Higher is tighter.
+ *
+ * These are spring rates, not `damp` lambdas, and the two are not
+ * interchangeable at the same figure: a spring spends the start of a move
+ * accelerating instead of covering ground, so it reads gentler. Kept at the old
+ * numbers because the error they used to leave behind is gone — see below —
+ * which is a change to how the rig *looks* and wants an eye on it, not a number.
+ */
+const FOLLOW_RATE = 6;
+const AIM_RATE = 9;
+/**
+ * A ceiling on the speed the rig will ride along at, in metres per second.
+ *
+ * Not a tuning knob: a safety rail. The ride-along speed is measured from the
+ * placement's own motion, so a subject that jumps — a caller that teleported one
+ * without saying so — would otherwise hand the rig hundreds of metres a second
+ * and it would coast off with them. Far above anything a subject can really do,
+ * so it never binds in play.
+ */
+const MAX_TRACK_SPEED = 60;
+/** Keeps a boom from ending inside a wall it grazed. */
+const BOOM_RADIUS = 0.3;
+const BOOM_MIN_FRACTION = 0.12;
+/*
+ * The boom's rate limits live in `boom.ts` now, shared with the gameplay rig,
+ * which had none at all and popped by 4 m when a railing crossed it.
+ */
+export class CinematicCamera {
+    colliders;
+    camera = new Camera();
+    shot = { kind: 'chase', distance: 6, height: 2, fovDeg: 70 };
+    shotStartSec = 0;
+    nowSec = 0;
+    /**
+     * Where the camera wants to be, and where it is looking.
+     *
+     * Springs rather than first-order lags, which is the fix for *"the transitions
+     * between them that it's like straight"*. A lag's speed is proportional to the
+     * error it has already built, so the only way it can travel at the subject's
+     * speed is to accumulate `speed / lambda` metres of error and hold it: a shot
+     * asking for a 7 m boom was measured sitting at 9.219 m behind a 14 m/s
+     * character, and re-accumulating that error as a straight slide after every cut —
+     * 7.000 → 8.317 → 9.213 over the second after it, peaking on frame 2 and
+     * decaying from there. A spring carries a velocity, so it rides along with a
+     * target that is moving instead of trailing it, and it accelerates into and
+     * settles out of the moves that remain.
+     */
+    followX = new Spring();
+    followY = new Spring();
+    followZ = new Spring();
+    aimYaw = new Spring();
+    aimPitch = new Spring();
+    /** Place the rig outright on the next update, rather than moving it there. */
+    fresh = true;
+    /**
+     * Whether that placement may keep travelling at the target's speed.
+     *
+     * The difference between the two ways a rig is placed, and only the caller
+     * knows which happened. A **cut** changes the shot while the subject carries on
+     * as it was, so the speed measured across the frame is real and the new shot
+     * should open already moving with it — otherwise every cut opens with the rig
+     * accelerating from a standstill, which is the slide this replaced. A **snap**
+     * is for a subject that teleported: there is no meaningful speed across that
+     * frame, and a rig that inherited one would coast off after the character's
+     * ghost.
+     */
+    freshKeepsSpeed = false;
+    /** The arm out to the camera, and its speed limits. See `boom.ts`. */
+    boom = new Boom();
+    /** Frozen for `flyby`, which watches from where it was placed. */
+    station = [0, 0, 0];
+    pose = { x: 0, y: 0, z: 0, yaw: 0 };
+    previousPose = { x: 0, y: 0, z: 0, yaw: 0 };
+    hasPreviousPose = false;
+    placement = createShotPlacement();
+    previousPlacement = createShotPlacement();
+    constructor(colliders) {
+        this.colliders = colliders;
+    }
+    /**
+     * Switch shots, now.
+     *
+     * `atSec` is the shot's own start time, used by anything that animates within
+     * a shot — an orbit's angle, for instance — so a shot looks the same whenever
+     * in the run it is used.
+     */
+    cut(shot, atSec) {
+        this.shot = shot;
+        this.shotStartSec = atSec;
+        // The next update snaps rather than glides. This *is* the cut.
+        this.fresh = true;
+        // The subject did not stop for it, so the new shot opens already tracking.
+        this.freshKeepsSpeed = true;
+    }
+    /**
+     * Drop the smoothing history, keeping the shot.
+     *
+     * For a subject that *teleports* — a character who died and is back on a
+     * checkpoint, or a scrub bar dropped somewhere else in the run. Smoothing
+     * across that is a camera flying the length of the route with nothing in
+     * frame, measured at 124 m inside a single shot, and it looks far more like a
+     * bug than a cut does.
+     *
+     * A threshold inside `update` would be the wrong place for this. Only the
+     * caller can tell a teleport from a legitimately fast frame: a replay catching
+     * up after a freeze advances several simulation ticks in one frame, and a
+     * browser that dropped a frame advances a dozen. That is also why this is not
+     * `cut` — the two differ over whether the speed across the frame means
+     * anything, and the caller is the only one who knows.
+     */
+    snap() {
+        this.fresh = true;
+        this.freshKeepsSpeed = false;
+    }
+    /** Seconds since the current shot began. */
+    get shotAgeSec() {
+        return Math.max(0, this.nowSec - this.shotStartSec);
+    }
+    update(frameDt, subjectX, subjectY, subjectZ, subjectYaw) {
+        const dt = Math.max(0, frameDt);
+        this.nowSec += dt;
+        const shot = this.shot;
+        const age = this.shotAgeSec;
+        const pose = this.pose;
+        pose.x = subjectX;
+        pose.y = subjectY;
+        pose.z = subjectZ;
+        pose.yaw = subjectYaw;
+        // Captured on the cut, from where the subject was at the time, then held.
+        if (this.fresh && shot.kind === 'flyby')
+            flybyStation(shot, pose, this.station);
+        const want = this.placement;
+        placeShot(shot, pose, age, this.station, want);
+        /*
+         * How fast the placement itself is travelling, by placing the *same* shot
+         * where the subject was a frame ago.
+         *
+         * Measured this way rather than by differencing the last frame's answer,
+         * because the last frame's answer belongs to the previous shot and a cut is
+         * exactly when this matters most. It also comes out right for the shots whose
+         * placement does not follow the subject at all — a `flyby` station gives
+         * zero, because both frames read the same held station — and it picks up an
+         * orbit's own sweep, which is motion the rig should ride rather than chase.
+         */
+        let trackVX = 0;
+        let trackVY = 0;
+        let trackVZ = 0;
+        if (dt > 1e-6 && this.hasPreviousPose && (!this.fresh || this.freshKeepsSpeed)) {
+            const before = this.previousPlacement;
+            placeShot(shot, this.previousPose, Math.max(0, age - dt), this.station, before);
+            trackVX = trackSpeed((want.wantX - before.wantX) / dt);
+            trackVY = trackSpeed((want.wantY - before.wantY) / dt);
+            trackVZ = trackSpeed((want.wantZ - before.wantZ) / dt);
+        }
+        if (this.fresh) {
+            this.followX.reset(want.wantX, trackVX);
+            this.followY.reset(want.wantY, trackVY);
+            this.followZ.reset(want.wantZ, trackVZ);
+        }
+        else {
+            this.followX.step(want.wantX, trackVX, FOLLOW_RATE, dt);
+            this.followY.step(want.wantY, trackVY, FOLLOW_RATE, dt);
+            this.followZ.step(want.wantZ, trackVZ, FOLLOW_RATE, dt);
+        }
+        /*
+         * Collision. The boom is the line from the subject out to the camera, and
+         * it shortens against real geometry — a replay camera clipping through an
+         * island reads as broken immediately, not as a bad angle.
+         */
+        const boomX = this.followX.value - want.lookX;
+        const boomY = this.followY.value - want.lookY;
+        const boomZ = this.followZ.value - want.lookZ;
+        const clearFraction = Math.max(BOOM_MIN_FRACTION, segmentHit(want.lookX, want.lookY, want.lookZ, boomX, boomY, boomZ, this.colliders, BOOM_RADIUS));
+        if (this.fresh)
+            this.boom.reset(clearFraction);
+        else
+            this.boom.step(clearFraction, Math.hypot(boomX, boomY, boomZ), dt);
+        const fraction = this.boom.fraction;
+        const camX = want.lookX + boomX * fraction;
+        const camY = want.lookY + boomY * fraction;
+        const camZ = want.lookZ + boomZ * fraction;
+        this.camera.position[0] = camX;
+        this.camera.position[1] = camY;
+        this.camera.position[2] = camZ;
+        // Aim. Smoothed separately from position, so a pan stays steady while the
+        // rig is still converging on its placement. Its target is where the subject
+        // *is* rather than where it is heading, so there is no speed to ride along
+        // with — and now that the rig holds its framing, a held shot barely moves it.
+        const dx = want.lookX - camX;
+        const dy = want.lookY - camY;
+        const dz = want.lookZ - camZ;
+        const flat = Math.hypot(dx, dz);
+        const wantYaw = flat < 1e-4 && Math.abs(dy) < 1e-4 ? this.aimYaw.value : Math.atan2(dx, -dz);
+        const wantPitch = flat < 1e-4 ? (dy > 0 ? 1.4 : -1.4) : Math.atan2(dy, flat);
+        if (this.fresh) {
+            this.aimYaw.reset(wantYaw);
+            this.aimPitch.reset(wantPitch);
+        }
+        else {
+            this.aimYaw.stepAngle(wantYaw, 0, AIM_RATE, dt);
+            this.aimPitch.step(wantPitch, 0, AIM_RATE, dt);
+        }
+        this.camera.yaw = this.aimYaw.value;
+        this.camera.pitch = this.aimPitch.value;
+        this.camera.fovYDeg = want.fovDeg;
+        this.previousPose.x = pose.x;
+        this.previousPose.y = pose.y;
+        this.previousPose.z = pose.z;
+        this.previousPose.yaw = pose.yaw;
+        this.hasPreviousPose = true;
+        this.fresh = false;
+        this.freshKeepsSpeed = false;
+    }
+}
+/** Keep a measured ride-along speed inside what a crane could do. */
+function trackSpeed(value) {
+    if (!Number.isFinite(value))
+        return 0;
+    return clamp(value, -MAX_TRACK_SPEED, MAX_TRACK_SPEED);
+}

package/dist/render/clusteredLights.d.ts

@@ -0,0 +1,260 @@
+/**
+ * The froxel table: what it looks like in memory, and the CPU binner that fills it.
+ *
+ * **One table, two producers, one reader.** A compute shader writes this on WebGPU and this file
+ * writes it on WebGL2, and the lit pass fetches it the same way on both. That is the 2026-08-13
+ * rule applied literally — the decision is backend-neutral and only the binding is per-backend —
+ * and it is why the table is a *texture* rather than a storage buffer, which only one backend has.
+ *
+ * **The layout is chosen so the two producers can be compared, not merely trusted.** The
+ * 2026-08-17 rule says two implementations of one decision drift, and drift invisibly when the
+ * constants are identical; a CPU binner and a GPU binner are exactly that. So every choice here
+ * that could have gone either way went the way that makes a byte-for-byte comparison possible:
+ * fixed slots rather than an appended list, an integer ordering rather than a distance sort, and
+ * an overflow rule both can evaluate. `scripts/cluster-check.mjs` is the comparison.
+ */
+/** Tiles across the screen. */
+export declare const CLUSTER_X = 16;
+/** Tiles down the screen. */
+export declare const CLUSTER_Y = 9;
+/** Depth slices, partitioned exponentially. */
+export declare const CLUSTER_Z = 24;
+export declare const CLUSTER_COUNT: number;
+/**
+ * Texels a cluster occupies: one for its count, seven holding four light indices each.
+ *
+ * **Fixed rather than packed, and that is what removes the atomics.** One invocation owns one
+ * cluster and writes only its own run, so nothing is appended to a shared list, there is no
+ * counter to increment atomically and no compaction pass. That is also what lets the GPU binner
+ * write through a *write-only* storage texture, which is all core WGSL gives.
+ */
+export declare const CLUSTER_TEXELS = 5;
+/**
+ * How many lights one cluster can hold. Four index texels at four indices each.
+ *
+ * **Sixteen because that is `MAX_POINT_LIGHTS`, and the equality is the point.** The light loop's
+ * bound has to be a constant and there is only one loop, so a larger cap here would raise it for
+ * the fixed path too — a scene that never asks for froxels would carry a loop bound of 28 where it
+ * carries 16 today, which on the driver that faulted under the full shader is precisely the sort
+ * of change nobody would attribute to clustering. Equal bounds mean the fixed path is untouched.
+ *
+ * **It is not the old limit wearing a new hat.** Sixteen was a budget for the *whole scene*, chosen
+ * by distance with a contention band because somebody always had to be last. Sixteen per froxel is
+ * a different sixteen in every froxel, out of `MAX_CLUSTERED_LIGHTS` in the scene.
+ */
+export declare const MAX_LIGHTS_PER_CLUSTER: number;
+/**
+ * How many lights the clustered path carries at once.
+ *
+ * **This is the number that replaces `MAX_POINT_LIGHTS`**, and it is not bounded by the same
+ * thing: the sixteen is a uniform-array size and an iteration of the widest shader's light loop,
+ * while this is a row count in a texture nobody iterates in full. 320 lights is three rows.
+ *
+ * 320 rather than 256 because the light region has to end on a row boundary — see `TABLE_WIDTH` —
+ * and at three texels a light, 320 is the smallest count at or above 256 that does.
+ */
+export declare const MAX_CLUSTERED_LIGHTS = 320;
+/**
+ * Texels one light's record occupies: position and radius, colour and emitter size, then the
+ * weight and the shadow slot.
+ *
+ * **The shadow slot is an index into the existing sixteen-wide shadow uniforms, not a layer.**
+ * Clustering lifts how many lights *shade* a fragment; it does not lift how many shadow maps
+ * exist, and it should not — the pool is twenty-two octahedral layers at 1024, 92.3 MB, and that
+ * is a memory budget rather than a shader limit. So a clustered light either holds one of those
+ * slots or casts no shadow, exactly as a light does today, and `-1` says which.
+ *
+ * GLSL ES can index a *uniform array* with a non-constant expression; it is only sampler arrays
+ * it cannot. That is what lets a light index the shadow uniforms by a number read from a texture,
+ * and it is the same fact the octahedral array texture was built on.
+ */
+export declare const LIGHT_TEXELS = 5;
+/**
+ * Where each field of a light's record sits, as an offset in `uint`s from `lightBase`.
+ *
+ * **Written out rather than left to the two writers to agree on**, because there are two: this
+ * file's CPU binner and `clusterBinner.ts`'s WGSL kernel, and the 2026-08-17 rule is that two
+ * implementations of one decision drift invisibly when the constants are identical.
+ * `scripts/cluster-check.mjs` compares the tables byte for byte and is the backstop; this table is
+ * so that the two are written from one statement rather than compared after the fact.
+ *
+ * Slots 10 to 15 arrived with the fourth texel and the spot fields fill them exactly — direction,
+ * two cone cosines, and a profile index — with nothing spare. Slots 10 and 11 were already free
+ * inside the third texel and were being written as literal zeros.
+ *
+ * **A fifth texel arrived 2026-08-27 for the photometric azimuth**, and the reason it is affordable
+ * is a measurement rather than a shrug: the light region is `MAX_CLUSTERED_LIGHTS * LIGHT_TEXELS`
+ * texels — 20 KB at four — against a froxel region of 270 KB, so a fifth texel is **5 KB of 290,
+ * 1.7% of the table**. The obvious reading is that a fifth of four is a quarter, and that is a
+ * quarter of the *smaller* half. Slot 19 is spare.
+ *
+ * **Why the azimuth needs a vector at all**, rather than being derived from the direction: there is
+ * no continuous field of unit vectors tangent to a sphere — the hairy ball theorem — so *any*
+ * reference derived from the aim alone has a direction in which it flips, and an asymmetric fixture
+ * rotating through that direction would snap its pattern round. The two obvious constructions put
+ * that singularity where these fixtures actually point: `cross(worldUp, dir)` fails for a light
+ * aimed straight down, which is a street light.
+ */
+export declare const LIGHT_RECORD: {
+    readonly positionX: 0;
+    readonly positionY: 1;
+    readonly positionZ: 2;
+    readonly radius: 3;
+    readonly colorR: 4;
+    readonly colorG: 5;
+    readonly colorB: 6;
+    readonly sourceRadius: 7;
+    readonly weight: 8;
+    readonly shadowSlot: 9;
+    readonly directionX: 10;
+    readonly directionY: 11;
+    readonly directionZ: 12;
+    readonly cosInner: 13;
+    readonly cosOuter: 14;
+    readonly iesProfile: 15;
+    /** The fixture's azimuth zero, in world space. See the note above on why it cannot be derived. */
+    readonly iesAxisX: 16;
+    readonly iesAxisY: 17;
+    readonly iesAxisZ: 18;
+    /** A tile of the cookie atlas, or negative for none. Slot 19, the one the fifth texel spared. */
+    readonly cookie: 19;
+};
+/**
+ * The cone a light with no cone has: one that admits every direction, exactly.
+ *
+ * **`smoothstep(cosOuter, cosInner, dot(-L, dir))` must return exactly 1 for a point light**, and
+ * these two values are what make it. Every direction on the sphere has `dot >= -1`, so with the
+ * outer edge at −2 and the inner at −1 the argument is always at or past the upper edge and
+ * `smoothstep` is 1 — no branch, no special case, and the published scenes stay bit-identical by
+ * construction rather than by measurement.
+ *
+ * **Not −1 and −1**, which is the spelling that suggests itself: `smoothstep(a, a, x)` is undefined
+ * when the two edges are equal and a driver may answer either bound.
+ */
+export declare const POINT_LIGHT_COS_INNER = -1;
+export declare const POINT_LIGHT_COS_OUTER = -2;
+/** A light carrying no IES profile. Matches the shader's own test against a negative index. */
+export declare const NO_IES_PROFILE = -1;
+/** The record's `w` when a light holds no shadow slot. */
+export declare const NO_SHADOW_SLOT = -1;
+/** Texels the light records occupy, which is where the cluster runs begin. */
+export declare const LIGHT_REGION_TEXELS: number;
+/**
+ * Texels across the table.
+ *
+ * **320, so that neither region straddles a row.** 320 divides by `CLUSTER_TEXELS`, so a cluster's
+ * run of five is 64 clusters to a row and never wraps — a cluster split across two rows would need
+ * the shader to carry the wrap, and getting that wrong reads as lights belonging to the froxel
+ * next door. It divides `LIGHT_REGION_TEXELS` exactly too, so the cluster region starts at the
+ * beginning of a row.
+ */
+export declare const TABLE_WIDTH = 320;
+/** Rows: three of light records and 54 of cluster runs. 292 KB of `RGBA32UI`, allocated once. */
+export declare const TABLE_HEIGHT: number;
+/** The table, as the `Uint32Array` both a texture upload and a readback comparison want. */
+export declare function createClusterTable(): Uint32Array;
+/** The first `uint` of a cluster's run: its count. Its indices follow four to a texel. */
+export declare function clusterBase(cluster: number): number;
+/** The first `uint` of a light's record. */
+export declare function lightBase(light: number): number;
+/**
+ * Which depth slice a view-space depth falls in.
+ *
+ * Exponential rather than linear, which is what every published clustered renderer settled on: a
+ * linear partition spends most of its slices where the eye has no depth discrimination left, and
+ * puts almost every light in a scene into the first one.
+ *
+ * Clamped at both ends rather than allowed to run off. A fragment exactly on the far plane is a
+ * real fragment and must land in the last slice, not one past it.
+ */
+export declare function sliceOfViewDepth(z: number, near: number, far: number): number;
+/** The view-space depth a slice begins at. */
+export declare function sliceNearDepth(slice: number, near: number, far: number): number;
+/**
+ * The axis-aligned bounds of one cluster, in view space, as `[minX, minY, minZ, maxX, maxY, maxZ]`
+ * with z a positive depth.
+ *
+ * **The AABB of the cluster's eight corners, which is larger than the cluster.** A froxel is a
+ * truncated pyramid and its bounding box is not tight at the near end; the cost of that is a light
+ * occasionally binned into a cluster it only *nearly* touches, which shades a few fragments
+ * against a light contributing almost nothing. The alternative — testing the sphere against six
+ * planes — is exact, costs four more dot products per light per cluster, and is what to reach for
+ * if a profile ever indicts this. It is stated rather than hidden because the looseness is
+ * visible in the conformance script's borderline count and would otherwise read as a bug.
+ */
+export declare function clusterViewBounds(i: number, j: number, k: number, near: number, far: number, tanHalfFovY: number, aspect: number, out: Float32Array): void;
+/** The light arrays the binner reads, in the shape `Environment` already carries them. */
+export interface ClusterLightSet {
+    readonly count: number;
+    /** Three per light, world space. */
+    readonly positions: Float32Array;
+    /** Three per light. */
+    readonly colors: Float32Array;
+    /** One per light: the distance at which illumination falls to zero. */
+    readonly radii: Float32Array;
+    /** One per light: emitter size in metres. See `sphereLobe`. */
+    readonly sourceRadii: Float32Array;
+    /** One per light: how present it is, which is what makes a light arrive rather than appear. */
+    readonly weights: Float32Array;
+    /**
+     * Three per light: the direction a spot points, normalised. Absent means every light is a point.
+     *
+     * Optional, so a consumer that has never heard of spot lights passes exactly what it passed
+     * before and gets exactly what it got before — the collapse `POINT_LIGHT_COS_OUTER` describes.
+     */
+    readonly directions?: Float32Array;
+    /** Two per light: the cosine of the inner cone angle, then of the outer. See the constants. */
+    readonly coneCos?: Float32Array;
+    /** Three per light: a photometric profile's azimuth zero. See `PointLightSet.lightIesAxes`. */
+    readonly iesAxes?: Float32Array;
+    /** One per light: a tile of the cookie atlas, or negative. See `PointLightSet.lightCookies`. */
+    readonly cookies?: Float32Array;
+    /** One per light: an index into the IES atlas, or −1. */
+    readonly iesProfiles?: Float32Array;
+}
+/**
+ * Fill the table with this frame's light assignment, and answer how many lights it carried.
+ *
+ * **A cluster's list is written in increasing light index, and that is a decision about the gate
+ * rather than about the picture.** Sorting by distance was the first design and it is wrong for
+ * one reason that only appears at the conformance check: a float comparison cannot be relied on to
+ * rank two nearly equidistant lights the same way in JavaScript and in WGSL. Contraction,
+ * evaluation order, and a JS number that is a double until something rounds it are each enough to
+ * swap them, and the byte comparison would then fail on a scene where both binners were correct.
+ * An integer key has no such freedom.
+ *
+ * **A float decides one thing only: which lights survive an overflow.** A full cluster meeting a
+ * nearer light drops its farthest, and the survivors are re-sorted ascending before the next one
+ * arrives, so the bytes stay deterministic even though the membership was chosen by a comparison
+ * allowed to differ in its last bit. Keeping the first N encountered was the alternative and it
+ * can drop the lamp a viewer is standing under in favour of 28 distant ones, which the fidelity
+ * bar does not allow.
+ *
+ * **Positions are stored in world space and binned in view space.** The lit pass computes
+ * `uLightPos[i] - vWorldPos` and the clustered arm must reach the same arithmetic from a different
+ * place — storing view-space positions would make the two arms differ by a transform, and the
+ * zero-pixel gate between them would stop meaning anything.
+ *
+ * **Measured, because this runs on the main thread on WebGL2 and a cost nobody measured is a cost
+ * nobody can defend.** On this machine, lights of radius 8 in a 0.1 to 500 frustum:
+ *
+ *     16 lights   0.411 ms a frame
+ *     64 lights   1.037 ms a frame
+ *    256 lights   2.589 ms a frame
+ *
+ * Sixteen is today's budget and is nearly free. **256 is 16% of a 60 fps frame**, which is
+ * affordable and is not nothing — and it is the honest argument for the GPU binner rather than a
+ * stopwatch on a shader. The floor is the per-frame clear of the cluster region; the slope is the
+ * tile box, which grows with a light's screen area rather than with the light count, so a scene of
+ * small lamps costs far less than this and one of vast overlapping radii costs more.
+ *
+ * **Re-measured after the tile box moved inside the slice loop**, which is what made the two
+ * binners agree: 0.386, 0.895 and 2.001 ms before, so correctness cost between 6% and 29%. Worth
+ * recording, because the earlier numbers were for a binner that dropped lights.
+ *
+ * `shadowSlots` is how many of the shadow uniform slots are live this frame, which is what
+ * decides whether a light's record names one. See `LIGHT_TEXELS`.
+ *
+ * Fills a caller-owned table and allocates nothing.
+ */
+export declare function buildLightClusters(lights: ClusterLightSet, view: Float32Array, near: number, far: number, tanHalfFovY: number, aspect: number, table: Uint32Array, shadowSlots: number): number;