[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 <[email protected]> wrote:
> On Tue, Aug 30, 2011 at 10:02 PM, Mark Callow <[email protected]> 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
> <http://developer.download.nvidia.com/tegra/docs/tegra_gles2_development.pdf>
> 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.


> David
>> Regards
>> -Mark
>> 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 ([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

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