I'm working on a PBR Material, extensions.shaderTextureLOD=true works fine on r117, but r118 and later fragment shader fails compilation.
ERROR: 0:253: 'textureCubeLodEXT' : no matching overloaded function found
ERROR: 0:253: '=' : dimension mismatch
ERROR: 0:253: '=' : cannot convert from 'const mediump float' to 'mediump 4-component vector of float'
253: vec4 rgba = textureCubeLodEXT(texture, dir, lod);
This happens because starting with r118, three.js uses by default a WebGL 2 rendering context and assumes GLSL 3.0 by default.
The above line of code is not GLSL 3.0 conform. It has to look like so:
vec4 rgba = textureLod(texture, dir, lod);
It is not necessary to set shaderTextureLOD to true since the extension's features can be used by default with WebGL 2.
Instead of upgrading your shader code, you can also use WebGL1Renderer which was introduced with r118, too. This renderer enforces a WebGL 1 rendering context.
We do have this:
But the OP is probably using RawShaderMaterial?
Yes, there were similar issues at the forum and stackoverflow in context of the texture() function. Although there were also issues with ShaderMaterial when using the reserved texture keyword as a variable name.
Hmm... I think we should be able to prepend a string to the shader?
Pseudo-code:
```js
if ( material.isRawShaderMaterial ) {
const version = isWebGL2 ? '#version 300 es' : '#version 100 es';
fragment = version +'\n' + fragment;
}
Hmm, we have some similar code already... 馃
I guess prepending such a string to RawShaderMaterial might break code since users already had to define the GLSL version when using WebGL 2. So if the engine starts doing this, it will be done twice which will require a migration task.
Besides, there might be user who want to use GLSL 1 with WebGL 2 (for whatever reasons). The above code would not allow this setup anymore.
Yes, I'm using the RawShaderMaterial. I think it's time to move forward to update my knowledge. Thank you very much.
@Mugen87 Agreed.
On that note, I do not think we need this code at all?
/cc @fernandojsg
Not sure why this check is there since the version directive has to be the first statement of the shader code. When using ShaderMaterial, this never can be true since the renderer always prepends prefix code.
I would we be good to know if there was a specific reasons why this code was added.
Not sure why this check is there since the
versiondirective has to be the first statement of the shader code. When usingShaderMaterial, this never can be true since the renderer always prepends prefix code.
Yes, that's what I though. Thanks for double checking!
I think I'm going to remove that code for now...
Most helpful comment
Yes, that's what I though. Thanks for double checking!
I think I'm going to remove that code for now...