WebGPURenderer: Tree shaking Materials - WIP

[sunag]

Introduce

The objective of the PR is to advance the tree shaking of WebGPURenderer related to Materials, any suggestions and opinions regarding the notes below are welcome.

Design

WebGPURenderer tree shaking NodeMaterials is very simple, the same does not happen with other library-based Material abstractions such as MeshStandardMaterial, these materials depend on their shader base being accessed in the Renderer.

I created jsm/renderers/webgpu/Three.js to have a version similar to the core related to WebGPURenderer and three shaking.

The code below shows the two examples related to the image mentioned above:

WebGLRenderer - Core
https://github.com/sunag/three.js/blob/dev-materials/src/materials/MeshStandardMaterial.js

WebGPURenderer - Core
https://github.com/sunag/three.js/blob/dev-materials/examples/jsm/materials/MeshStandardMaterial.js

The main difference is that we have some added setup*() calls and extends NodeMaterial.

Thoughts

• Structure Material class to support the creation of shader using TSL and preserve the previous hierarchy regarding default materials.
• We would no longer need the Node prefix in materials since it can be unified easily.

Examples

webgpu_lights_selective

/cc @mrdoob @Mugen87

[mrdoob]

Maybe we can have two different builds:

build/three.webgpu.js
build/three.webgpu.nodes.js

The first one will include classic materials and will not be fully tree-shakeable.
The second one will not include the classic materials and will be fully tree-shakeable..

That way...

People that want to start using WebGPU would just need to replace three.module.js with three.webgpu.js.

And people that want to use WebGPU and also be able to fully tree-shake will be able to do so by using three.webgpu.nodes.js and adopting NodeMaterial in their projects.

What do you think?

[Mugen87]

It seems what @mrdoob has been suggested in #28328 (comment) has been implemented by other PRs. Is this PR still required?

[sunag]

Although some ideas in this PR have been merged, the base materials were not ported to three.webgpu.nodes.js.

Today, materials like MeshStandardNodeMaterial are extended from MeshStandardMaterial through a property-copy hack, because the class shoud be extended from NodeMaterial. MeshStandardMaterial does not have a shader abstraction, only a parameters one, so a library behind it is necessary to ensure it works, which in the end is incompatible with tree-shaking.

If MeshStandardNodeMaterial is extended from MeshStandardMaterial and consequently is extended from NodeMaterial, we will be able to bring all the base materials compatible with tree-shaking, as well as remove the property-copy hack.

In this sense, we can think the same way for lights, and so on, then we will have a complete shader abstraction and we can discard renderer.library / NodeLibrary. A light, a material, or whatever can be imported via npm with full compatibility.

Example:

import { MyLight } from 'custom-light'

scene.add( new MyLight() );