WebGPURenderer: Introduce NodeMaterialObserver and updates

[sunag]

Related issue: #29077 (comment), #29299

NodeMaterialObserver is responsible for checking if there are any changes in the materials, and if so, moving forward with the process of updating the nodes and bindings at the GPU level.

NodeMaterialObserver is an intermediate component between node updates that can be extended or manipulated using NodeMaterial.setupObserver().

List

• Added NodeMaterialObserver
• Move lights to renderGroup
• Move camera to renderGroup
• Move fog to renderGroup
• Remove Proxies in updateBeforeNodes and updateAfterNodes
• TSL Added Lights.js
• RenderObjects: Reuse chainArray
• Move tone mapping exposure to renderGroup

Performance

webgpu_performance_renderbundle

bundle = r168	bundle += viewMatrices GPU	bundle += node observer
5.67ms	3.27ms	0.96ms

default = r168	default += viewMatrices GPU	default += node observer
12.10ms	8.85ms	6.59ms

webgpu_performance

Screenshot	Description
	WebGPU ~1026fps - mesh.static = true + non-string initial cacheKey in RenderObject - maybe we can some hash algorithm like crc32/64 for comparison in the rendering cycle - not available in this PR
	WebGPU ~870fps - mesh.static = true
	WebGPU ~717fps
	* WebGL ~640fps - reference
	WebGPU previous r168 ~299fps

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	685.83 169.75	685.83 169.75	+0 B +0 B
WebGPU	828.45 222.25	832.11 222.98	+3.66 kB +729 B
WebGPU Nodes	828.03 222.16	831.62 222.86	+3.59 kB +699 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	462.42 111.53	462.42 111.53	+0 B +0 B
WebGPU	526.43 141.9	529.89 142.75	+3.46 kB +844 B
WebGPU Nodes	483.08 131.72	486.54 132.61	+3.46 kB +890 B

[cmhhelgeson]

I'm still trying to familiarize myself with the deeper workings of the API rather than just adding onto it, but is the monitor meant to simply just analyze whether the node material's properties match the data returned by getXData calls, then setting the needsRefresh flag as needed based on the result of that query? Then, within the main render loop, the nodes and bindings are only ( according to my guess) only updated in 3 scenarios

1. In Renderer's createObject function
2. Within _renderbundle and _renderObject direct only when the node monitor set's the Nodes objects needsRefresh flag to true.
3. When a node is first initialized, which automatically will set the needsRefresh flag for it to be updated within the aforementioned _renderBundle and _renderObjectDirect functions.

[sunag]

@cmhhelgeson Yes, your analysis is correct :)

[cmhhelgeson]

If setupMonitor let's us manipulate the monitor's properties, would it make sense to have one of setupMonitor's arguments be a list of properties that are either included or excluded in the needsRefresh call, essentially making those properties static even if the program itself is not? Or would that not really provide any meaningful performance benefits given the small list of properties?

Or maybe it would make sense to add to a monitor's refreshUniforms property as a program is being created so a monitor only deals with uniforms relevant to its sample?

Perhaps it doesn't matter either way, since the monitor already seems to ignore properties that aren't there.

[sunag]

The large list will be ignored in the frame cycle, leaving only the properties present in the material, so we wouldn't need to add many functions here.

I think interesting add refreshUniform as a property of the NodeMaterialMonitor, that way users could edit it.

The idea of ​​setupMonitor() is to encourage users to extend the NodeMaterialMonitor class and do their own specific optimization.

[sunag]

This is the first time we have improved performance for many common objects without refraction, as we already had better performance in refraction, now without using special native WebGPU features.

[mrdoob]

Monitor sounds strange to me... NodeMaterialManager or NodeMaterialObserver may be more fitting?

[mrdoob]

/cc @0b5vr

[mrdoob]

Or even NodeMaterialOptimizer, whichever sounds better to you 👌

[sunag]

What do you think of NodeMaterialWatcher? I'm not sure if it's better than NodeMaterialObserver.

In my head material optimizer would enter the compilation process, shaders, etc. The main objective of the class would be to check data changes and release the update of nodes and bindings.

[sunag]

Some others options could be NodeMaterialUpdater, NodeMaterialListener...

[cmhhelgeson]

I think NodeMaterialObserver is good. Updater suggests a class that's performing more robust modifications on the materials.

[RenaudRohlinger]

Awesome!!

By the way, @sunag this PR seems to break the WebGL version of webgpu_performance_renderbundle.