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

Re: [Public WebGL] Please review WebGL multiple render target extension proposal



Right, so the idea's to introduce FP-textures properly a second time around which would modify the framebuffer/mrt extensions clamping behavior?

On Wed, Oct 17, 2012 at 8:14 PM, Kenneth Russell <kbr@google.com> wrote:
Ah, sorry, pulled the trigger too quickly on that email. I see the
section you're pointing out.

It's been pointed out most vehemently by Mark Callow that I in
particular glossed over the subtleties of floating-point render
targets when adding optional support for them in the WebGL exposure of
OES_texture_float. There is an ongoing discussion about the
correctness of the OES_texture_float conformance test as well
(http://www.khronos.org/bugzilla/show_bug.cgi?id=729).

Another OpenGL ES extension proposal should be coming soon which
supports floating-point render targets more thoroughly than WebGL's
exposure of OES_texture_float, and I think that rather than try to
patch up the existing specs we should just wait for that one to come
along and then point to it. From the standpoint of the MRT extension,
OES_texture_float should be considered to affect individual color
attachments in the same way that it affects the previous single color
attachment to FBOs. I wouldn't want to do a half-baked job again
trying to add FP render target support to this MRT extension so again
let's wait for the new extension.

The vast majority of ES 2.0 hardware will not support floating-point
render targets, but my hope is that some or most ES 3.0 hardware will.

-Ken


On Wed, Oct 17, 2012 at 11:04 AM, Kenneth Russell <kbr@google.com> wrote:
> This is pretty much an orthogonal question to the MRT proposal. Please
> start a new thread for it.
>
> -Ken
>
>
> On Wed, Oct 17, 2012 at 2:11 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> I think that's fine. I've got one question though. I know that when I attach
>> a floating point texture, that the output values are not clamped to 0-1. I
>> also know that the OpenGL ES 2.0 specification states the clamping as
>> behavior (which is also mentioned in this extension). I'm not sure, but I
>> think the desktop versions of OpenGL don't specify the clamping at the
>> shader output level (there's some function to control clamping).
>>
>> I'm a bit worried that this might be a behavioral difference between
>> Mobiles/Desktops that could shoot you in the foot if/when you find a mobile
>> with floating point texture render target support. Anybody know if mobiles
>> do the clamping regardless of target format?
>>
>> On Wed, Oct 17, 2012 at 3:51 AM, Kenneth Russell <kbr@google.com> wrote:
>>>
>>>
>>> Please review an extension proposal adding multiple render target
>>> functionality to WebGL:
>>>
>>>
>>> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiple_render_targets/
>>>
>>> It mirrors a proposed extension for ANGLE which adds this
>>> functionality to OpenGL ES 2.0:
>>>
>>>
>>> https://angleproject.googlecode.com/svn/trunk/extensions/ANGLE_multiple_render_targets.txt
>>>
>>> Please provide your feedback on both.
>>>
>>> Apologies for how long it took to produce these extensions. They
>>> couldn't be drafted until OpenGL ES 3.0 was released, because in order
>>> to avoid compatibility issues in the future, it was necessary to
>>> derive their contents from the ES 3.0 specification. The draft ANGLE
>>> extension modifies the same areas of the OpenGL ES 2.0 specification
>>> modified by the GL_NV_fbo_color_attachments and GL_NV_draw_buffers
>>> extensions, but draws the majority of its text and semantics from the
>>> ES 3.0 spec.
>>>
>>> -Ken
>>>
>>> -----------------------------------------------------------
>>> 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
>>> -----------------------------------------------------------
>>>
>>