[Public WebGL] readPixles() can't access float values (OES_texture_float interaction)

Chris Marrin [email protected]
Wed Sep 21 13:56:44 PDT 2011

On Sep 20, 2011, at 12:15 PM, Glenn Maynard wrote:

> On Tue, Sep 20, 2011 at 2:26 PM, Chris Marrin <[email protected]> wrote:
> I meant that there's no precedence in WebGL. Remember our extension mechanism differs from that of OpenGL. In WebGL you need to enable an extension to use it's feature(s). We should stick with that.
> I agree that this is useful in general, to make testing variables explicit, and help ensure you're not depending on a feature without realizing it's optional.  But I'm not sure it would do that here, because the implementation can still treat the renderbuffer as "incomplete" for arbitrary reasons.
> For example, you know that if OES_texture_float loads successfuly, floating-point textures (not framebuffers) are available.  Barring bugs, or exceptions to the rule (MAX_TEXTURE_SIZE and other non-extensioned variables), any code you write using floating-point textures will work on any system that exposes OES_texture_float.  There are only two states: systems with the extension and systems without; and you can test that your code works in both states simply by importing or not importing the extension.
> That doesn't work with renderbuffers.  Even if a system supports floating-point framebuffer attachments, the RB configurations which are actually framebuffer complete can vary.  The end result is that you still have to test every hardware and driver combination (in theory) to be sure your code works.  Having a separate extension doesn't seem very helpful if it doesn't solve that problem.

It is terrible if there is no guaranteed combination of FBO attachments. It will make using FBO's almost useless for this audience. I'd like to see a matrix of all the possible combinations and all of those that are supported by various hardware. I don't have time to make such a matrix, but if I did, I bet I'd see a pattern emerge that would allow us to give authors at least some guarantees. If not, I think it will be too hard for authors to use FBO's, IMHO.

> If there's a feature not supported by GLES, we should require an extension to enable it.
> There still is an extension required--it's still part of OES_texture_float.  It just doesn't split apart support for floating-point textures and floating-point framebuffer attachments.  Both should always fail if that extension isn't enabled.

I still really think we should have an extension explicitly enabling rendering to a floating point buffer. And I think we should provide the author with some guarantees about constructing an FBO. Together, I think we can make it easy for authors to use them and to have confidence that they'll work.

[email protected]

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list