selectPointLights

function selectPointLights(sources: readonly PointLightSource[], x: number, y: number, z: number, out: PointLightBuffer, timeSeconds?: number, viewRange?: number, castX?: number, castY?: number, castZ?: number): void

import { selectPointLights } from '@driftengine/core';

Parameters

In depth

Two points, because the two lists answer two questions. x, y, z is where the frame is being shaded from — the camera — and it orders and culls the shaded list. castX, castY, castZ is where whatever might cast is standing, and it orders and culls the shadow pool. AGENTS.md had already decided which point the pool belongs to: "a character's shadow only has to exist near the light they are standing at" — they, not the viewer.

They were one argument until 2026-08-25, and a third-person camera is exactly where that hurts: it sits behind its subject, so a fire the subject is standing next to got no map at all whenever the camera was further from it than the fire's radius. The scene stayed perfectly lit, which is why nobody could tell it from a bake that never ran.

What it gives up: three more numbers on an already-long parameter list, spelled as numbers rather than a vector to match the point above it. What would make it wrong: a consumer with several casters far apart, which one point cannot describe — the pool would then want a set of reference points and a rank over the nearest of them, which is a bigger change than this one and is not what any consumer here has.

The default is the shading point, so an existing caller selects bit-identically: castX = x makes the distance the same arithmetic on the same operands, not merely a close number.