[Public WebGL] EXT_shader_texture_lod in WebGL2?
Fri Jan 20 10:24:13 PST 2017
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 <[email protected]> wrote:
> 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
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl