[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)



On Tue, Aug 30, 2011 at 4:25 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
> Many implementations will use those internal formats if the types
> UNSIGNED_SHORT_{4_4_4_4,5_5_5_1,5_6_5} are used when providing the texture
> data. But yes, it is definitely not clear.  We are trying to clean it up for
> Halti which will support sized internal formats.

This sounds good. Support for sized internal formats will clean up a
big discrepancy between OpenGL and OpenGL ES.

> What do you mean by RGBA? The implementation might be converting the texture
> to 4444 or 5651 on loading.

I meant type=GL_UNSIGNED_BYTE and format and internal format=GL_RGBA
passed to glTexImage2D.

> If it is really RGBA8 those implementations probably support the
> OES_rgb8_rgba8 extension which means the implementation can render to RGBA8
> and may even have a default RGBA8 framebuffer.  Therefore rendering to an
> RGBA8 texture requires nothing the implementation cannot already do. But
> strictly speaking they would seem to be in violation of Section 4.4.5.

It seems that these implementations are providing 8 bits per color
channel in this case. I'm not sure, but it's likely that these
implementations do support OES_rgb8_rgba8.

> [BTW, the quote below came from version 2.0.24. The latest version 2.0.25
> says:
>
> Formats not listed in table 4.5, including compressed internal formats. are
> not
> color-, depth-, or stencil-renderable, no matter which components they
> contain.
>
> Table 4.5 lists only the same 3 internal formats as the quote from 2.0.24 as
> color-renderable.]

Understood -- I was actually looking at the 2.0.25 spec.

To resolve the issue of rendering to floating-point textures, I
propose defining a pair of OpenGL ES 2.0 extensions
("OES_render_texture_float" / "OES_render_texture_half_float"?) which
define support for FLOAT and HALF_FLOAT_OES texture attachments to
FBOs. Does that sound like a reasonable path to take at this point in
time? I think that adding the minimal amount of spec text and
functionality would be the best direction to take. For example, it
doesn't seem necessary to provide control over clamping behavior.

Another option would be to extend the WebGL extensions exposing
OES_texture_float and OES_texture_half_float ([1], [2]) with enough
language to allow, but not require, an implementation to support these
texture types as FBO color attachments.

I think that we should preserve the capability to render to
floating-point textures from WebGL wherever possible. Existing use
cases ([3], [4], [5], [6], and I'm sure there are more) demonstrate
how compelling this capability is.

[1] http://www.khronos.org/registry/webgl/extensions/OES_texture_float/
[2] http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/
[3] http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm
[4] http://madebyevan.com/webgl-path-tracing/
[5] http://madebyevan.com/webgl-water/
[6] http://webglsamples.googlecode.com/hg/hdr/hdr.html

-Ken

> Regards
>
> -Mark
>
> On 2011/08/30 15:37, Kenneth Russell wrote:
>
> 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?
>
> -Ken
>
> On Tue, Aug 30, 2011 at 12:03 PM, Mark Callow <callow_mark@hicorp.co.jp>
> 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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------