WebGLRenderer: Check if uniforms exist

[sunag]

This PR checks if material uniforms together with material properties in case this logic is broken through NodeMaterial. This is a serious integration part of NodeMaterial in the core, until now seems the best approach for this.

This consists of no case conflicts if the properties of natives materials like MeshStandardMaterial use the property color with a Node value instead of Color.

This PR is entirely linked with this approach ( #18162 ):

var material = new THREE.MeshStandardMaterial();

material.color = new Nodes.CheckerNode();

[sunag]

@mrdoob @WestLangley @Mugen87 Some suggestion? I am not sure if I was able to explain clearly the proposal: #18162

[WestLangley]

I am not sure of the best solution to the issue described here, however if we are going to be making changes, a related issue that we may want to revisit is the following: Each uniform is a object, and it used to have a .type property. That property is no longer present, so the .value property may no longer be needed, either.

diffuse: { value: new Color( 0xeeeeee ) },
opacity: { value: 1.0 },

[sunag]

That property is no longer present, so the .value property may no longer be needed, either.

Interesting... I think that it contains .needsUpdate property in uniform too.

My main issue is the refresh uniforms maybe we can redesign to something like this:

UniformsLib.common = new Uniforms(

	diffuse: { value: new Color( 0xeeeeee ) },
	opacity: { value: 1.0 },

	map: { value: null },
	uvTransform: { value: new Matrix3() },
	uv2Transform: { value: new Matrix3() },

	alphaMap: { value: null }

).onRefresh( function( uniforms, material ) { 

	uniforms.diffuse.value.copy( material.color );
	uniforms.opacity.value = material.opacity;

	uniforms.map.value = material.map;
...

} );

Thus assigns the responsibility from refresh uniforms to the uniforms class, thus making WebGLRenderer more independent.

[WestLangley]

Yep, that's what you suggested in #18068 (comment).

This is a serious integration part of NodeMaterial in the core

Understood. You are going to have to get buy-in from @mrdoob. He seems to have strong feelings on the best way to make WebGLRenderer more material-agnostic -- if at all.

[sunag]

I think that we will no longer have this problem since that the new node material work with Node name in final of the property like material.colorNode.