WEBGL // UBO (Uniform Buffer Object) with `onBeforeCompile` is not working.

[dghez]

I'm trying to use UBO paired with onBeforeCompile but looks like is not possible.
I'm pretty sure my setup of the UBO is working because i'm using that on other materials, but with ShaderMaterials directly.

Here is what i'm trying:

el.material.onBeforeCompile = (shader) => {
            shader.uniformsGroups = [globalUniforms]

            shader.fragmentShader = shader.fragmentShader.replace(
                `#include <common>`, /* glsl*/ `
                  #include <common>
                  #include <globalUBO>
              `
            )
        }

But yells at me.

Any clue?

Version

0.174.0

Device

No response

Browser

No response

OS

No response

[dghez]

Apparently tho, UBO are not binded due is supported only on RawMaterial / ShaderMaterial > https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L2565

[Mugen87]

Yes, UBO support only exists for ShaderMaterial and RawShaderMaterial in WebGLRenderer. We have fully integrated UBOs into WebGPURenderer but encountered a performance issue when updating uniform values, see #30560. We would hit the same problem in WebGLRenderer so we must find a solution first before thinking about deeper integration in WebGLRenderer.

[Mugen87]

That said, there are currently no plans to further enhance the feature set of onBeforeCompile() because it's shader patching approach is quite fragile.

If you are planning to extend built-in materials, think about switching to WebGPURenderer and TSL. If you can't switch the renderer for certain reasons, keep an eye on #30185.

[dghez]

hey @Mugen87 thanks for the quick response! ❤️
Not a big deal honestly, i can always do a workaround binding single uniforms on the material but using the same object from the UBO i've created, like for example

shader.uniforms.uTime = globalUniforms.time

and call the day.

---

Regarding you two suggestions, ngl i'm planning to look into webgpu and TSL soon, although i'm still kinda scared over bring that in production for clients but sooner or later i'll jump on that train.

Thanks again sir!

[pailhead]

FWIW this may be worth taking a look at.

https://github.com/pailhead/three-refactor-chunk-material

I don't think that there is any reason why WebGLRenderer should know about any of the built-in materials. Think of it like this:

1. I can write a ShaderMaterial and WebGLRenderer will render it.
2. I can write a ShaderMaterial that behaves exactly like say MeshBasicMaterial or in your case MeshStandardMaterial
3. I don't even have to write 2, i can just assemble it the same exact way MeshStandardMaterial is assembled.

So, instead of making an instance of MeshStandardMaterial and letting WebGLRendererer basically build a ShaderMaterial for you, you can just copy the shader (template, very small file) and build it yourself. Meaning, you dont even have to do it lazily - by waiting for onBeforeCompile at some later time, you can just put whatever you want to inject with onBeforeCompile directly into the shader.

At the end of they day, if this feature works on ShaderMaterial it will work on your ShaderMaterial that is exactly the same as your extended MeshStandardMaterial thus circumnavigating this limitation.