[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 5:31 PM, Kenneth Russell <[email protected]> wrote:
> 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.

I heartily agree. This functionality is already in use in deployed and
under-development commercial shader suites. If the WG decides to
explicitly disallow this functionality with only OES_texture_float,
developers need an immediate work-around to keep sites functional for
users with capable GPUs.

David

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

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