[Public WebGL] readPixles() can't access float values (OES_texture_float interaction)
Thu Sep 15 12:37:24 PDT 2011
On Thu, Sep 15, 2011 at 2:34 PM, Mark Callow <[email protected]>wrote:
> What other platforms do you have in mind?
Native development, middleware engines and anything else that can provide a
more reasonable feature lag. If people can't accomplish what they want with
the Web platform, they'll use something else.
I also just don't see the advantage--so long as optional features are
> always implemented as extensions, to prevent unintentional testing
> variables; as long as they're only added when they have a stable OpenGL
> interface to follow; which have been shown to be of value (hopefully implied
> by the previous).
> As currently specified this particular feature can easily be used without
> the developer realizing that it is an optional feature lacking wide support.
Sure--that's a bug, in my opinion, though possibly one it's too late to
fix. I mentioned this and cut it out because it seemed tangental, but I
think that as many optional features and implementation variations as
possible should be represented by a mandatory extension check. For example,
it would have been good for the feature of rendering to a FP buffer to be
exposed with "OES_texture_float_rendering". (This doesn't mean each needs
its own spec; a single extension spec could define several extension
strings, where it's editorially sensible. This is unlike OpenGL, due to
WebGL's new policy of required extension queries.) I wouldn't personally
object to this being done now for this feature, but it would obviously break
On the same token, it would be nice to have, for example, a
"OES_profile_desktop_2011" extension, specifying values for
MAX_TEXTURE_SIZE, MAX_TEXTURE_IMAGE_UNITS, and so on. If no profile
extensions are enabled, all of these values would be clamped to the
lowest-common-denominator; similarly, "profile_mobile" or
"profile_advanced". As is, the same problem exists here--developers can
unknowingly write software that depends, for example, on more TUs than some
This means that as much of the variation between systems as possible is
represented by explicit extension strings.
(Some variables are probably very hard to impossible to specify precisely,
eg. fragment program size limitations.)
The OES_texture_float extension and the original WebGL version thereof do
> not add support for floating point rendering. It is an accident that some
> WebGL implementations chose to do so. There is no OES or ARB extension that
> is the equivalent of the current WebGL texture float extension so one cannot
> say it is mature and proven.
Rendering to floating-point textures with OpenGL is clearly a mature API,
with proven functionality; that's the metric I was offering for considering
exposing something to WebGL.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl