Src: Nomenclature clean up

[WestLangley]

Changed 'reverse' -> 'reversed', plus some subjective changes for clarity

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	338.62 79.03	338.73 79.06	+108 B +30 B
WebGPU	566.96 156.76	566.96 156.76	+0 B +0 B
WebGPU Nodes	565.56 156.51	565.56 156.51	+0 B +0 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	470.05 113.73	470.15 113.76	+108 B +31 B
WebGPU	638.44 172.77	638.44 172.77	+0 B +0 B
WebGPU Nodes	593.09 162.03	593.09 162.03	+0 B +0 B

[mrdoob]

Is this easier to read?

USE_LOGARITHMIC_DEPTHBUFFER
USE_REVERSED_DEPTHBUFFER

[WestLangley]

Is this easier to read?

Maybe, but I don't think "depthbuffer" is a word.

[mrdoob]

Up to you 👌

[WestLangley]

It's a toss-up, but I think this is OK.

[WestLangley]

new build needed, please.

[Mugen87]

950dbb5 🚀

[vanruesc]

@Mugen87 This change broke user code and should at least be mentioned in the release notes / migration guide 🙏

Related: pmndrs/postprocessing#731

[Mugen87]

Updated: https://github.com/mrdoob/three.js/wiki/Migration-Guide#179--180

[vanruesc]

Thank you!

[WestLangley]

We only put API changes in the Migration Guide -- not internal changes. The API change was noted in the prior release, r179.

If the user is hacking the library, he is responsible for reading what he is hacking.

[vanruesc]

The library actively provides these macros to ShaderMaterial and users rely on this functionality. This behaviour is also (partially) documented. It's great that these flags are provided to custom materials because managing all of that manually for every custom material would be tedious and inefficient.

I don't see why relying on these predefined macros would be considered hacking.

The API change was noted in the prior release

I'd respect the decision to remove the notes from the migration guide, but I think it's very helpful information.

[Mugen87]

Yeah, the shader lib is not really internal. At least since the introduction of onBeforeCompile() the engine encourages users to overwrite/modify shader chunks to inject custom logic in built-in materials. Every time we change defines, update shader code or just rename shader chunks, user level code can break. IMO. it's correct to mentioned the renaming in the migration guide.