Nodes: Add more exports to ShaderNode

[LeviPesin]

Fixes #23564

Description

This PR adds more exports to the ShaderNode.

Breaking changes:

• Renamed MathNode.RAD and MathNode.DEG to MathNode.RADIANS and MathNode.DEGREES.
• Removed join() function from the ShaderNode (use vec2/vec3/vec4/etc instead),
• viewMatrix now should be used as viewMatrix().

@sunag Not sure about how arrayUniform() should work, what do you suggest?

[LeviPesin]

So, there are two problems with the circular inclusion:

1. "Top-level problem". If a file B imports something from file A, while file A imports e.g. a class B from B, A must not use B on the top-level. It can be solved by changing nodeImmutables of some classes (ReflectNode, CubeTextureNode, etc) to nodeProxyies (but then reflectVector() and reflectCube() must be used instead of reflectVector and reflectCube, which is not very good), but...
2. ...it will not solve the problem because of the "non-lazy evaluations top-level problem". Because JavaScript does not support lazy evaluations in any form, if we write nodeProxy( ReflectNode ), it will try to evaluate ReflectNode before executing the functions, again running into the top-level problem. The only solution to this is to inline the nodeProxy code (or use eval).

Obviously these problems can be circumvented by creating one more ShaderNode file containing e.g. core, math, and basic accessors... But it is not a very reliable solution (I can easily imagine a node importing a node importing a node, so on, all of which should be exported by the ShaderNode).

[sunag]

@LeviPesin I think that we can have a ShaderNodeBaseElements.js for bringing all GLSL functions and ShaderNodeElements.js for all others Three.js features like reflectCube and reflectVec.

[LeviPesin]

Yes, I now also think it would be better and easier (but still can cause some troubles)... OK, will do that tomorrow.

[LeviPesin]

Done.

[sunag]

@sunag What do you think about arrayUniform()? What should be its signature?

I think that: uniforms( nodes ).

[LeviPesin]

I am asking because I am not sure if something like [ vec3(), mat4() ] would even work... Actually, what is the usecase for ArrayUniformNode? There are no examples of using it.

[sunag]

I am asking because I am not sure if something like [ vec3(), mat4() ] would even work... Actually, what is the usecase for ArrayUniformNode? There are no examples of using it.

I see... the type of array should be optional in this case, but we can be added this in the second argument like:
uniforms( nodes, type = null )

[LeviPesin]

Still not sure about the usecases...

[LeviPesin]

@sunag Maybe it would be better to merge this PR and decide later whether and how arrayUniform should be implemented?

[sunag]

Seems that this PR broke webgpu_compute example.

[sunag]

Try test with:

uniform( new THREE.Vector2() );

[LeviPesin]

Should be fixed now.

[sunag]

Seems that this PR broke webgpu_compute example.

See this: d4cbbee maybe you need revert it too

[LeviPesin]

So, I found a workaround, but it feels quite hacky... It seems that I do not quite understand how the system of the TempNodes work...

[sunag]

For this case is better use context:

context( add( particle, velocity ), { temp: false } )

[sunag]

Thanks @LeviPesin!