SpriteNodeMaterial: Honor sizeAttenuation for perspective camera only

[WestLangley]

Reverts #29517.

The sizeAttenuation property only applies when rendering with a perspective camera (see docs). This has been a policy since the early days of three.js.

It probably should have been named .perspectiveSizeAttenuation for clarity.

In any event, the current goal is to match WebGLRenderer's output, and this PR does that. We can discuss API changes in another PR.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	338.9 79.1	338.9 79.1	+0 B +0 B
WebGPU	570.29 157.49	570.22 157.47	-74 B -23 B
WebGPU Nodes	568.9 157.24	568.83 157.22	-74 B -23 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	470.64 113.87	470.64 113.87	+0 B +0 B
WebGPU	643.13 173.9	643.05 173.87	-74 B -21 B
WebGPU Nodes	597.34 163.12	597.34 163.12	+0 B +0 B

[Mugen87]

We can discuss API changes in another PR.

I think we should discuss here before merging why #29517 is reverted. Just saying "it has been a policy so far" isn't sufficient to me, tbh.

Why is it an issue to have size attenuation for orthographic cameras? I understand the feature is coupled to how perspective works but for artistic purposes it's nice to have this feature for orthographic cameras as well.

@RenaudRohlinger What was your motivation to add size attenuation for orthographic cameras?

[WestLangley]

Orthographic cameras do not size attenuate by definition.

Furthermore, sizeAttenuation in three.js means the object's size is attenuated with respect to perspective camera depth. (see docs)

#29517 is using it to mean something else. Quoting the OP,

Adjusted sprite scaling for orthographic cameras when sizeAttenuation is false. ... This ensures sprites scale correctly in orthographic projections, maintaining consistent sizes on the screen regardless of the camera's zoom level.

[gkjohnson]

I agree with WestLangley - the concept or wording of "sizeAttenuation" does not make sense for an orthographic camera (I've also never been a huge fan of the API here anyway since it's not clear about the scales). #31630 is a more sensible solution to this problem, imo.

Why is it an issue to have size attenuation for orthographic cameras?

The clarity and sensibility of three.js' API has long been one of its strengths imo and the concept of size attenuation does not make sense for an orthographic projection. The previous changes strikes me as a spot fix to enable a use case without considering the understandability of the flag and instead I think that ensuring API changes are clear and understandable should be encouraged.

[WestLangley]

Yay! We have agreement! Merging, to get WebGLRenderer and WebGPURenderer to match.