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

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

Something still seems unclear. That table only discusses
renderbuffers' internal formats. It can't be the case that those rules
apply when attaching textures to an FBO, because it's impossible in
OpenGL ES 2.0 to allocate a texture with any of those internal
formats. However, rendering to an FBO with an RGBA texture as its
color attachment seems to work on the majority of OpenGL ES 2.0
implementations. (Otherwise, there would be no point in exposing the
FramebufferTexture2D API in GLES 2.0.) Further, visual inspection on
these implementations indicates that these textures have greater than
4- or 5-bit resolution, so it seems to be the case that internally the
textures are using 8 bits of precision. Wouldn't that violate the
rules in that table?

How is this behavior explained in the OpenGL ES 2.0 spec?


On Tue, Aug 30, 2011 at 12:03 PM, Mark Callow <[email protected]> wrote:
> The spec. is not unclear. The extension spec. does not amend Section 4.4.5
> of the core OpenGL ES 2.0 spec. which includes
> The following internal formats are color-renderable: RGB565, RGBA4, and RGB5
> A1. No other formats, including compressed internal formats, are
> color-renderable.
> and similar limitations on which formats are depth- and stencil-renderable.
> If WebGL's version of OES_float_texture is allowing floating point textures
> to be renderable, then it is a different extension and it needs to document
> all the relevant interactions. If it is intended to be the same as
> OES_float_texture then allowing the float texture to be color-renderable is
> a bug.
> Regards
> -Mark
> On 11/08/30 11:32, Benoit Jacob wrote:
> Thanks. If the spec is too unclear for you to support attaching float
> textures to FBOs, then maybe we should explicitly disallow that in WebGL,
> for portability's sake.

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