Enable raw shader code for ShaderMaterial

[BKcore]

I'm suggesting a quick addition to THREE.WebGLRenderer.buildProgram() and THREE.ShaderMaterial in 2 steps:

• Adding a (bool)disableShaderPrefix attribute in ShaderMaterial
• Adding a simple test in WebGLRenderer.buildProgram():6624 to skip shader prefixing (https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L6624)

This really tiny change would allow true custom fragment and vertex shaders to be used, without the fear of some automatic and hidden attributes/uniforms/defines addition by the Renderer.

As for backward compatibility, it's not a problem since we could just set disableShaderPrefix to false by default, making that change a choice to the user by setting that attribute to true after creating the material.

Sometimes, I need true flexibility when writing custom materials, and with all the code added by the Renderer to my shaders, it's sometimes a pain to debug.

What do you think?

[mrdoob]

Maybe THREE.RawShaderMaterial?

[BKcore]

Sounds good too. Although the difference between ShaderMaterial and RawShaderMaterial could be obscure to the neophyte.
Maybe useRawShader instead of disableShaderPrefix as attribute since negative api attributes are ugly.
Creating a new material for such a small change might be overkill. Although I haven't been following your recent api choices, so I can't say which way seems better fitted.

[zz85]

+1 to this functionality. this is an issue I've also faced.

I think mrdoob is coming from where a new material is easier API-wise compared to a flag.

Or perhaps let RawShaderMaterial extend ShaderMaterial with raw shader flag enabled? (or the other way)?

Although I always wonder if there's a better way three.js can generate configurable shader code..

[mastershadow]

+1 for me too

[zz85]

upping this thread, since i'm playing around with shaders a little.. any recent thoughts to this?

[mrdoob]

Haven't spend any brain cycles into this myself. Open to more API ideas though.

[zz85]

The simplest solution for now would be as @BKcore says - check for a flag. Then if we wish to try the THREE.RawShaderMaterial, would could just extend ShaderMaterial after.

I should probably try to do this soon and see whats happens.

[mrdoob]

Well... that took a while...
Thanks guys! :)

[zz85]

nice @mrdoob. i was thinking of this the other day I was looking at WebGLProgram. Glad you did it yourself :)

[mrdoob]

Step by step...

Next thing is, maybe, to do a Geometry to BufferGeometry step and remove all the Geometry specific code from WebGLRenderer.