Custom shader support for WebGPURenderer

[danrossi]

Description

I'm not sure where to put this. There seems to be some portability issues between WebGL and WebGPU as far as custom shaders in materials go. I found a problem rendering troika text in webgpu rendererer. Which is manipulating the shaders of MeshBasicMaterial within onBeforeCompile.

onBeforeCompile does not run with WebGPURenderer.

https://github.com/protectwise/troika/blob/main/packages/troika-three-text/src/TextDerivedMaterial.js#L75

https://danrossi.github.io/three-troika/test/webgpu_text.html

I'm trying to get my own modified bmfont shaders that were previously using RawShaderMaterial but this material isn't supported with WebGPU renderer. So all my RawShaderMaterial setups have to be changed to something else.

https://github.com/danrossi/three-bmfont-text/blob/8a82f08a3629e00ca6865f24791dd93f66705383/src/shaders/MSDFShader.js#L43

Should these be converting automatically like what is happening by default with MeshBasicMaterial or is there a requirement to build some node system after webgpu feature detection instead ? So requiring setup material setups for different renderers ?

I can see portability issues between rendererers. I noticed WebGPURenderer now falls back to WebGLRenderer internally so should hopefully accept onBeforeCompile or WebGLRenderer support the undocumented nodes system to build shaders so there is only one setup needed.

Solution

A uniform way to modify MeshBasicMaterial shader or a custom shader for both renderers. Hopefully this is not confusing.

Alternatives

na

Additional context

#protectwise/troika/issues/264

[donmccurdy]

WebGPU uses WGSL rather than GLSL, so code like what you've linked to is not going to work with WebGPURenderer. We do not, to my knowledge, plan to transpile shaders from GLSL to WGSL. A WebGPU-compatible version of troika should probably use the NodeMaterial system, either by linking a node graph declaratively or by writing code in ShaderNode (see #22603). Shaders defined in this way should be supported in both WebGL and WebGPU.

I don't know the plan for onBeforeCompile in WebGPU, but I would guess that many places it is currently used are no longer required when using node-based materials.

/cc @sunag

[Mugen87]

AFAIK, there was no plan to support onBeforeCompile() since the node material provide better ways to implement custom behavior (e.g. TSL).

There is no support for ShaderMaterial and RawShaderMaterial for WebGPURenderer so three-bmfont won't work with WebGPURenderer until they update their project.

[aardgoose]

All the node materials allow various parts of the shaders to be overridden and the base NodeMaterial allows overriding the default vertex and fragment code flows entirely, so there should not be any problem implementing equivalents. This should be a lot more reliable that using onBeforeCompile() where you rely on the shader code remaining consistent over releases.

[danrossi]

Ok sorry to waste your time. I'll look into it. So the shader in MeshBasicMaterial isn't even used or converted. So NodeMaterial can be used for WebGLRenderer also and it converts it back to the shader it needs ? I'll look into it to my bmfont fork first.

[Mugen87]

So the shader in MeshBasicMaterial isn't even used or converted.

No it isn't.

So NodeMaterial can be used for WebGLRenderer also and it converts it back to the shader it needs ?

The idea is to always use WebGPURenderer in the future. This renderer primarily targets WebGPU. If this API isn't supported, it will use WebGL 2 as a fallback. When implementing custom materials with the node material/TSL, you don't have to worry about which native backend is used.

[danrossi]

Sounds like it's being setup how I was asking. Trying to look at the node thing now for the bmfont basic shader for now for text rendering. However they still yet have a WebXR proposal for webgpu yet sadly. It's all theoretical still.