[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 Wed, Aug 31, 2011 at 3:37 PM, David Sheets <firstname.lastname@example.org> wrote:
> On Tue, Aug 30, 2011 at 10:02 PM, Mark Callow <email@example.com> wrote:
>> The fundamental issue is that rendering to an FP framebuffer takes a lot of
>> additional transistors. Because of this, I doubt if any OpenGL ES 2.0
>> implementations support rendering to an FP framebuffer. It is likely found
>> only on desktop OpenGL. This is also why OES_texture_floatadds only float
>> texture support not FP framebuffer support.
> Page 5 of the NVidia Tegra GL ES 2 docs
> indicates FP texture write support (and MRT fwiw). Adreno 220 series
> can do deferred lighting and cloth sim which would also seem to
> indicate FP texture write support.
Thanks, that's a useful pointer. Looking through the rest of the Tegra
docs, there is only a brief mention on page 15 that the support for
GL_OES_texture_half_float adds these as texture formats and FBO
formats. There's no mention of other extensions or exceptions.
For this reason I think a brief mention in the WebGL extensions that
these textures may be used as FBO attachments should suffice. If
anybody has an objection to this, please post; otherwise, I'll make
this change in the next few days.
Regarding reading back floating-point values, this functionality is
very much incompatible with the OpenGL ES 2.0 specification of
ReadPixels, and I don't think that we should add it to the WebGL spec
or as an extension at this time. Halti will clear this up, so I think
any time the working group invests should be in making the WebGL spec
track that one when it arrives.
>> On 2011/08/30 17:31, Kenneth Russell wrote:
>> 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 (, ) 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 (, , , , and I'm sure there are more) demonstrate
>> how compelling this capability is.
>>  http://www.khronos.org/registry/webgl/extensions/OES_texture_float/
>>  http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float/
>>  http://www.ibiblio.org/e-notes/webgl/gpu/contents.htm
>>  http://madebyevan.com/webgl-path-tracing/
>>  http://madebyevan.com/webgl-water/
>>  http://webglsamples.googlecode.com/hg/hdr/hdr.html
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: