Material: Move WebGLRenderer.refreshUniforms() to Material.onRefreshUniforms()

[sunag]

The mainly idea is get more control about the uniforms update in materials, mainly related with core materials. using an interface native in material: Material.onRefreshUniforms.

Benefits:

• More control for customize uniforms Material.onRefreshUniforms
• Reduce the number of if else related with the code.
• Better OOP code design

Call example:
MeshPhysicalMaterial->onRefreshUniforms() -> MeshStandardMaterial->onRefreshUniforms() -> Material->onRefreshUniforms()

[WestLangley]

Yay! Make the renderer material-agnostic.

User-created materials should be able to to use this feature, too.

[mrdoob]

I'm not a big fan of leaking WebGL into the scene graph...
Would this code apply to WebGPURenderer in the future for example?

[sunag]

I'm not a big fan of leaking WebGL into the scene graph...

Hmm, I think that this approach is similar at onBeforeCompile with uniforms?
Maybe it can be moved to UniformLib...
About NodeMaterial, it is almost that a WebGL scene graph?

Anyway there are other approaches in mind that I would like to try before it can be merger...

Would this code apply to WebGPURenderer in the future for example?

I think that yes, for this is necessary index the uniform properties on WebGPURenderer.

[Mugen87]

I'm not a big fan of leaking WebGL into the scene graph...

I can only agree. Better to encapsulate WebGL related logic in the renderer classes.

[sunag]

I can only agree. Better to encapsulate WebGL related logic in the renderer classes.

For exception of properties parameter, the logic is the same of .onBeforeCompile that returns uniforms in parameters for example. I can remove the properties param and I think that it will be better too.

I think that WebGLRenderer should focus only on the rendering process and not process a number finite of Material like Phong and Standard because this in my conception, uniforms values should be a concern of Material classes, Renderer classes is the execution process, like a renderer material-agnostic. WebGLRenderer should so provide an API with features like .onBeforeCompile, onRefreshUniforms for creating any type of material in the quality of the natives materials. We can use differente approaches for this result, I think that extended the GLSL language or modification the shader structure are some other alternatives compared with .onBeforeCompile and others. Anyway we should decouple WebGLRenderer native (Physical, Phong, etc) material treatments if we want more control and customization of natives materials.

[mrdoob]

.onBeforeCompile does indeed leak WebGL in a way but, as far as I'm aware, nothing in src/ uses that method. But I guess NodeMaterial relies on this, so I can see where the logic is coming from.

[sunag]

We can consider a different approach to this case?

Maybe Uniform.onUpdate()?

var UniformsLib = {

	common: {

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

		onUpdate: function( uniforms, material ) {
		
			uniforms.diffuse.value.copy( material.color );
		
		}
		
	}
	
}

[sunag]

I think that we can focus in this PR: #18175
The logic for use in NodeMaterial is explained in this PR too: #18162