PointLight/SpotLight: Deprecate distance parameter, auto-compute from intensity and decay.

[mrdoob]

Description

The distance parameter was redundant - it can be derived from the physically-based intensity and decay values. This simplifies the API and ensures consistency between visual range and actual light falloff.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	355.12 84.44	355.12 84.44	+0 B +0 B
WebGPU	616.54 171.12	616.54 171.12	+0 B +0 B
WebGPU Nodes	615.14 170.85	615.14 170.85	+0 B +0 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	487.3 119.32	487.3 119.32	+0 B +0 B
WebGPU	687.29 186.66	687.72 186.75	+426 B +90 B
WebGPU Nodes	637.13 173.88	637.56 173.97	+426 B +88 B

[mrdoob]

Improved PointLightHelper while I was at it.

Screen.Recording.2025-12-13.at.17.16.29.mov

[mrdoob]

Seems like distance was yet another parameter that was affecting PBR accuracy.
The fall-off in RoomEnvironment was not correct and that "leaked" into all the examples that used it.

[donmccurdy]

Note that this will mean dropping support for the range property in glTF's KHR_lights_punctual. From the spec, its purpose was:

Hint defining a distance cutoff at which the light's intensity may be considered to have reached zero. ... When undefined, range is assumed to be infinite.

This can be useful to cull geometry that a light may not visibly affect, potentially having a significant positive impact on rendering performance. It is required that, when given a non-zero value, rendering engines ignore the light beyond this range.

That said, I don't know if it's applied in this way by three.js users. If we prefer to not support this field in the glTF extension spec, that's OK with me.