Split InputNode into ConstNode and UniformNode

[LeviPesin]

Related issue: #23646

Description

Split InputNode into ConstNode and UniformNode.

Breaking changes:

• InputNode had been rewrited and now should not be used directly - ConstNode and UniformNode should be used instead.
• IntNode, FloatNode, BoolNode, UintNode, Vector2Node, Vector3Node, Vector4Node, Matrix2Node, Matrix3Node, and Matrix4Node had been removed - ConstNode and UniformNode should be used instead.
• BufferNode and TextureNode had been moved from inputs/ to accessors/.
• ArrayInputNode was renamed to ArrayUniformNode.

[LeviPesin]

@sunag I think this is better than #23660...

[LeviPesin]

I think the NodeEditor also requires a fix for InputNode, but I think I will do it tomorrow.

[LeviPesin]

@sunag now this PR passes all the tests but not all examples are working - e.g. https://raw.githack.com/LeviPesin/three.js-1/split-input-node/examples/webgl_materials_standard_nodes.html (gun does not show even without serialization code). Not sure what is the problem with it...

[sunag]

const value = new THREE.Vector3();

// current

const vec3 = new Nodes.Vector3Node( value  );
const vec3Const = new Nodes.Vector3Node( value  ).setConst( true );

// proposed by @LeviPesin

const vec3 = new Nodes.UniformNode( 'vec3', value  );
const vec3Const = new Nodes.ConstNode( 'vec3', value  );

// proposed by @LeviPesin with my cleanup

const vec3 = new Nodes.UniformNode( value );
const vec3Const = new Nodes.ConstNode( value );

@mrdoob do you have any thoughts on this?

[LeviPesin]

If you remove the type argument, then it would be impossible to e.g. distinguish between float 1.0 and int 1. The best thing would be to just use a function from the ShaderNode - Nodes.float( 1.0 ), Nodes.int( 1 ), Nodes.vec3( value ), etc.

[sunag]

I don't think in remove it entirely. It can be auto-detected and used as second parameter if needed.

[sunag]

Nodes.float( 1.0 ), Nodes.int( 1 ), Nodes.vec3( value )

For me, this breaks the current class style.

I think it would be a valid update to do in this PR is:

UniformNode( value, type = null )

[LeviPesin]

I still think that for the class approach it is better to always specify the type. But the ShaderNode approach is much better than the class one, I think - it is much easier to write and understand.

[sunag]

I still think that for the class approach it is better to always specify the type.

This is unnecessary most of the time, I don't see why. If the users puts a Vector3 as a value, the type must be the same, unless he uses the second argument.

[LeviPesin]

If user e.g. puts a Vector3(1, 1, 1) as a value, it could be vec3, ivec3, or uvec3.

[sunag]

If user e.g. puts a Vector3(1, 1, 1) as a value, it could be vec3, ivec3, or uvec3.

These are exceptions, it is unusual to use ivec3 even in GLSL, but for this can be use the second argument. I think that we have to prioritize common use. Vector3 is a floating vector as default.

[LeviPesin]

OK, so you are suggesting new UniformNode( value, type ) where if type is undefined it will be assumed float, vec2, vec3, vec4, mat3, mat4, or color based on the value?

[sunag]

OK, so you are suggesting new UniformNode( value, type ) where if type is undefined it will be assumed float, vec2, vec3, vec4, mat3, mat4, or color based on the value?

Exactly, and bool too.

[LeviPesin]

@sunag I've managed to fix serialization/deserialization in the https://raw.githack.com/LeviPesin/three.js-1/split-input-node/examples/webgl_materials_standard_nodes.html, but for some reason NodeObjectLoader.parse.onLoad is called twice there (as it also was before this PR), but now the first call throws an error for some reason... Could you please look into it and fix it?

[mrdoob]

@mrdoob do you have any thoughts on this?

This one looks good to me:

const value = new THREE.Vector3();

const vec3 = new Nodes.UniformNode( value );
const vec3Const = new Nodes.ConstNode( value );

OK, so you are suggesting new UniformNode( value, type ) where if type is undefined it will be assumed float, vec2, vec3, vec4, mat3, mat4, or color based on the value?

That sounds good too!

[sunag]

@sunag I've managed to fix serialization/deserialization in the https://raw.githack.com/LeviPesin/three.js-1/split-input-node/examples/webgl_materials_standard_nodes.html, but for some reason NodeObjectLoader.parse.onLoad is called twice there (as it also was before this PR), but now the first call throws an error for some reason... Could you please look into it and fix it?

Ok, I will test this.

[LeviPesin]

@sunag Your last commit breaks serialization/deserialization. You can write data.nodeType = this.getNodeType() instead but it can possibly break if a child of InputNode redefines .getNodeType(). That is why I created a new function ._getNodeType().

[LeviPesin]

Or you can inline the body of _getNodeType into both getNodeType and serialize.

[sunag]

@LeviPesin I commit a possible fix but didn't test it. I will make a revision of this later.

[LeviPesin]

I think it works. Then you can also remove .slice(4) from getValueFromType.

[LeviPesin]

@sunag Is there any progress on fixing that example?

[sunag]

@sunag Is there any progress on fixing that example?

It's been revised and fixed! There were other broken examples too.

[sunag]

@mrdoob Can we merge?

[mrdoob]

Thanks!

[wmcmurray]

A slight mention of this breaking change in the 138 → 139 Migration Guide would have been helpful 🙂
@Mugen87 ? 🙏🏼

[Mugen87]

We have not documented breaking changes of the node material so far because of its novel character. A lot of things have changed in the recent past. But it seems the node material is now mature enough to change this policy.