[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] EXT_shader_texture_lod in WebGL2?



Underlying ES3 drivers don't expose the EXT_shader_texture_lod, so currently you are not getting EXT_shader_texture_lod on most mobile platforms in WebGL1 because we don't expose this if WebGL1 is implemented on top of ES3 drivers.

There are other incompatibilities between WebGL1/WebGL2 shaders, like texture2D -> texture, etc.  You will need to rewrite or prep-process your old shaders anyway. I don't see a strong reason to expose older semantics for texture lod in WebGL2.

On Fri, Jan 20, 2017 at 7:46 AM, Jukka Jylänki <jujjyl@gmail.com> wrote:
Hi,

I'm working on upgrading an engine to use WebGL 2 from WebGL 1, and I find that EXT_shader_texture_lod has been added to the core WebGL 2 spec.

In WebGL 2, one can write #version 100 and #version 300 es shaders, with the idea that in WebGL2, one could reuse GLSL 1.0/GLES2 shaders without having to mass re-write all of them to GLSL 3.00/GLES3 when migrating.

This is great for backwards compatibility, however I find that neither Firefox or Chrome implementations of WebGL 2 expose EXT_shader_texture_lod anymore. This means that if one does run #version 100 shaders in a WebGL 2 context, they lose the ability to do textureCubeLodEXT() and so forth, which forces one to go and mass convert all shaders to GLSL 3.00/GLES3. If one wants to simultaneously target both WebGL1 and WebGL2, i.e. gracefully falling back to WebGL1 on older browsers, this means that one needs to author two versions of each shader that needs this extension, which is a lot of hassle to manage.

Could implementations still carry EXT_shader_texture_lod around in WebGL 2 so that #version 100 shaders with that extension would still keep working? I know WebGL is neither backwards or forwards compatible, but it would be great to minimize these types of breaking changes where possible, so that engines that co-target both versions on the fly would have easier time.

Though I do admit I'm not completely sure how this looks like in different vendors' native GLES3 implementations, and if they have this mechanism available as well for this extension.

Does anyone know if there was any fundamental reason to not advertise EXT_shader_texture_lod anymore in WebGL 2, or was it just a "oh, that's in core now so no need to have it present anymore" type of thought?

Thanks!
   Jukka