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

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



No objections from me. This looks like the right time and I appreciate
that this extension proposal has taken into account ES3 portability.

Benoit

On 12-11-02 04:07 PM, Kenneth Russell wrote:
> Are there any objections to moving the WebGL MRT extension spec from
> "proposed" to "draft" status? This would enable prefixed prototypes
> (i.e., MOZ_WEBGL_multiple_render_targets,
> WEBKIT_WEBGL_multiple_render_targets).
>
> Even though the underlying ANGLE extension still needs to be
> thoroughly reviewed by TransGaming, I don't anticipate major changes.
> It merely pulls the OpenGL ES 3.0 semantics for MRTs back to OpenGL ES
> 2.0. The only potential issue I can think of is that two extensions
> (fbo_color_attachments and draw_buffers) were merged into one, and the
> extension name exposed to GLSL was changed; if this turns out to be a
> problem for some reason, then the extension might need to be split up.
>
> -Ken
>
>
> On Wed, Oct 17, 2012 at 11:45 AM, Kenneth Russell <kbr@google.com> wrote:
>> Yes.
>>
>>
>> On Wed, Oct 17, 2012 at 11:25 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>> 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
>>>>>>> -----------------------------------------------------------
>>>>>>>
>>>
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------
>


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