Since you can replace #include <foo> replacing stuff in global might make sense, the problem is global is injected in both vert and frag so you can’t really inject attribute vec4 foo there, one idea for solving this :
This one added a lot of new chunk names so it could be more granular (like there could be a chunk named #include <user_provided_extensions>:
The code that breaks this:
@Mugen87 is this something that could be gradually shuffled around to make it more robust, or is it a dead end because of the imminent coming of NodeMaterial?
My use case was to try adding some custom fresnel in the existing MeshPhysicalMaterial.
The code expression that I was trying to implement had dependency on GL_OES_standard_derivatives.
The problem comes when looking to enable those extensions as these extensions are ( unlike ShaderMaterial ) parameter driven. I guess, it evaluates only those extension that would be required by the given built-in material before injecting as it into the shader program.
For me to overcome this. I had to come up with a trick rather than creating an entire custom shader.
What I ended up doing is adding a normalMap that would trigger enabling of derivatives extension.
And the problem was solved. Though not the ideal way.