Three.js: r115 -> r118 breaks extensions derivatives

Created on 29 Jun 2020  路  5Comments  路  Source: mrdoob/three.js

Description of the problem

Just upgraded my project from r115 to r118 (mainly to exploit the VAO support).
My shaders fails compiling due the use of dFdx|dFdy.

The GL_OES_standard_derivatives doesn't seems to be loaded, even though I have:

  extensions: {
    derivatives: true,
  },

Is the syntax changed or something?

Three.js version
  • [ ] Dev
  • [x] r118
  • [ ] ...
Browser
  • [x] All of them
  • [ ] Chrome
  • [ ] Firefox
  • [ ] Internet Explorer
OS
  • [x] All of them
  • [ ] Windows
  • [ ] macOS
  • [ ] Linux
  • [ ] Android
  • [ ] iOS
Hardware Requirements (graphics card, VR Device, ...)

Most helpful comment

Since GitHub was down for some time, we discussed this issue via Twitter PMs.

Fiddle demonstrating the issue: https://jsfiddle.net/yph50ntu/
Fixed fiddle: https://jsfiddle.net/s8um05ev/2/

Since r118, three.js uses a WebGL2 rendering context by default. The engine tries to convert existing GLSL 1.0 code to GLSL 3.0 as good as possible but only for built-in materials or custom shader code base on ShaderMaterial. There is no such conversion for RawShaderMaterial.

So the solution was to just convert your shader code to GLSL 3.0. Another possibility is the usage of WebGL1Renderer which would solve your issue without refactoring of shader code.

Keep in mind that extensions like GL_OES_standard_derivatives are enabled in WebGL 2/GLSL 3.0 by default so it's not necessary anymore to enable it manually.

All 5 comments

SAOPass enables derivates too and everything seems to work fine. Can you please demonstrate the issue with a live example?

Since GitHub was down for some time, we discussed this issue via Twitter PMs.

Fiddle demonstrating the issue: https://jsfiddle.net/yph50ntu/
Fixed fiddle: https://jsfiddle.net/s8um05ev/2/

Since r118, three.js uses a WebGL2 rendering context by default. The engine tries to convert existing GLSL 1.0 code to GLSL 3.0 as good as possible but only for built-in materials or custom shader code base on ShaderMaterial. There is no such conversion for RawShaderMaterial.

So the solution was to just convert your shader code to GLSL 3.0. Another possibility is the usage of WebGL1Renderer which would solve your issue without refactoring of shader code.

Keep in mind that extensions like GL_OES_standard_derivatives are enabled in WebGL 2/GLSL 3.0 by default so it's not necessary anymore to enable it manually.

@Mugen87 , it makes sense, but i would imagine that your fixed fiddle won't work in case WebGLRenderer fallbacks for WebGL1, right? (for example on Safari)

So, the correct best-practice would be to submit the right set of shaders (vert + frag) when using RawShaderMaterial/ShaderMaterial depending if using webgl1 vs webgl2?

If there a way to know if WebGLRenderer is using WebGL2 context or fallback to 1?

If there a way to know if WebGLRenderer is using WebGL2 context or fallback to 1?

You can check WebGL 2 support via WebGL.isWebGL2Available() before creating the renderer.

So, the correct best-practice would be to submit the right set of shaders (vert + frag) when using RawShaderMaterial/ShaderMaterial depending if using webgl1 vs webgl2?

Yes at least for RawShaderMaterial since there is no GLSL 1.0 to 3.0 conversion. three.js somewhat expects GLSL 3.0 compatible code when using WebGL 2 although this coupling is technically not necessary (meaning you can use GLSL 1.0 with WebGL 2). But the engine does not execute certain logic (e.g. enabling extensions like GL_OES_standard_derivatives) with a WebGL 2 rendering context.

In your particular case, I suggest to use WebGL1Renderer. For existing projects it makes only sense to invest the migration effort if you want to utilize a WebGL 2 exclusive feature like multisampled render targets. Otherwise you don't benefit from any migration effort right now. VAO also works with WebGL 1.

@Mugen87 , thanks makes sense.
In my case I will just force WebGL1.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Bandit picture Bandit  路  3Comments

makc picture makc  路  3Comments

boyravikumar picture boyravikumar  路  3Comments

clawconduce picture clawconduce  路  3Comments

konijn picture konijn  路  3Comments