WebGLNodes: Uniform instance node example

[sunag]

Related issue: #21305

Description

Example of how change the uniforms values per object preserving the same material and nodes.

[Mugen87]

Um, it's not ideal that WebGLState.useProgram() is used in the example code. The method is considered to be private and should not be used outside of the renderer.

I guess we need a different approach in the future to trigger a refresh of the material's uniforms. For now, it's okay.

[mrdoob]

Hmm, THREE.MeshStandardMaterial doesn't have this property... 🤔

[sunag]

In new NodeMaterial system all albedo(.map) and .color properties is used as Material.colorNode like:

three.js/examples/webgl_materials_standard_nodes.html

Lines 99 to 105 in f07a31a

	material.colorNode = new OperatorNode( '*', new TextureNode( diffuseMap ), new Vector3Node( material.color ) );
	// roughness is in G channel, metalness is in B channel
	material.roughnessNode = new SwitchNode( mpMapNode, 'g' );
	material.metalnessNode = new SwitchNode( mpMapNode, 'b' );
	material.normalNode = new NormalMapNode( new TextureNode( normalMap ) );

[mrdoob]

Shouldn't it be const material = new MeshStandardNodeMaterial(); then?

[sunag]

I think that yes, It would be better for serialization to extend. Currenty this pattern works for any material that use color and map like: MeshBasicMaterial, MeshPhongMaterial MeshPhysicalMaterial... would we then have to extended all the materials? The new NodeMaterial system not need more special materials like StandardNodeMaterial.

[sunag]

I can do this in an other PR.

[Mugen87]

The new NodeMaterial system not need more special materials like StandardNodeMaterial.

Yeah, that was the original design idea. Meaning just monkey-patch the existing material classes with new node properties like colorNode. The default material properties like color are going to internally mapped to nodes for backwards compatibility reasons. Meaning an existing material definition from WebGL also works with WebGPU. However, users can start with node features by just adding node properties to the material.

I guess this a good opportunity to clarify whether we want to use this approach or introduce separate node material classes again (like with the previous node system).

[mrdoob]

Yeah, that was the original design idea. Meaning just monkey-patch the existing material classes with new node properties like colorNode. The default material properties like color are going to internally mapped to nodes for backwards compatibility reasons.

Hmm, I think that's a bit confusing at this point...
We can try doing that later but I think I would keep the materials separate for now.

[mrdoob]

Thanks!