Hey there, an enhancement request. I'm using ShaderMaterials in a few places and recently found myself in need of those tasty tasty GL extensions. However, sticking them in front of the shader string doesn't really work well, as there is additional stuff that THREE adds before those. So the ask is this: add another parameter like "defines" and "uniforms" that takes a hash of extensions or something similar, allowing enabling of extensions. Here's the sadness:
THREE.WebGLShader: gl.getShaderInfoLog() fragment WARNING: 0:16: '
' : extension directive should occur before any non-preprocessor tokens
1: precision highp float;
2: precision highp int;
3: #define SHADER_NAME ShaderMaterial
4: #define MAX_DIR_LIGHTS 1
5: #define MAX_POINT_LIGHTS 0
6: #define MAX_SPOT_LIGHTS 0
7: #define MAX_HEMI_LIGHTS 0
8: #define MAX_SHADOWS 0
9: #define GAMMA_INPUT
10: #define GAMMA_OUTPUT
11: #define GAMMA_FACTOR 2
12: #define USE_LIGHTMAP
13: uniform mat4 viewMatrix;
14: uniform vec3 cameraPosition;
15:
16: #extension GL_OES_standard_derivatives : enable
Usnul
All 12 comments
Have you tried using RawShaderMaterial?
mrdoob
on 19 Oct 2015
Yeah, i have, but I end up re-writing ShaderMaterial in that case. I write my own materials for certain things, but i want those materials to play nice with stock ones, so I end up using shader chunks from three for things like light maps, shadow maps, lights etc. It's an awkward spot, ShaderMaterial is too restrictive, and RawShaderMaterial doesn't work without bits from ShaderMaterial if you want to re-use stuff from ShaderLib.
Usnul
on 20 Oct 2015
Actually, for derivatives you can just do material.derivatives = true;.
mrdoob
on 20 Oct 2015
That's spot on, thanks for that tid bit :)
What about more generic extensions?
Usnul
on 20 Oct 2015
Like which ones?
mrdoob
on 20 Oct 2015
like ones that tree doesn't enable via other means such as this sneaky ".derivatives" :)
could be a viable path for enabling extensions overall for materials perhaps even? Would make writing non-visual programs easier perhaps?
Usnul
on 20 Oct 2015
Maybe we can add a extensions array to ShaderMaterial?
material.extensions.push( 'GL_EXT_frag_depth' );
And then we convert them to #extension GL_EXT_frag_depth : enable?
mrdoob
on 20 Oct 2015
+1 for the same reasons as @Usnul - reusing shader chunks from THREE. I currently use GL_OES_standard_derivatives and GL_EXT_frag_depth.
Looking at https://www.khronos.org/registry/webgl/extensions/ I find the following:
#extension GL_OES_standard_derivatives : enable
#extension GL_EXT_frag_depth : enable
#extension GL_EXT_draw_buffers : require
#extension GL_EXT_shader_texture_lod : enable
At the moment there are only four extensions that need to be enabled in the shader, so using individual material properties (like .derivatives) seems still reasonable to me. As far as I can tell they are all specific to the fragment shader.
arose
on 20 Oct 2015
@mrdoob
seems like a reasonable thing :)
Usnul
on 22 Oct 2015
Sounds good to me. Anyone up for doing a PR for it?
mrdoob
on 22 Oct 2015
I've been keen to contribute in some way to three.js and would be happy to
have a go at this.
On Friday, 23 October 2015, Mr.doob [email protected] wrote:
Sounds good to me. Anyone up for doing a PR for it?
—
Reply to this email directly or view it on GitHub
https://github.com/mrdoob/three.js/issues/7379#issuecomment-150354177.
liammagee
on 23 Oct 2015
Thx, I guess this can be closed now.
arose
on 4 Nov 2015
Related issues
makc
·
3Comments
jlaquinte
·
3Comments
seep
·
3Comments
Horray
·
3Comments
jack-jun
·
3Comments
Most helpful comment
Maybe we can add a
extensionsarray toShaderMaterial?And then we convert them to
#extension GL_EXT_frag_depth : enable?