[Public WebGL] More WebGL extensions

Kenneth Russell [email protected]
Wed May 18 16:45:38 PDT 2011


No -- other work has taken priority for the WebGL WG in recent weeks.

-Ken

On Wed, May 18, 2011 at 2:35 PM, Brian Cornell <[email protected]> wrote:
> Has any more thought or action been put into an extension for supporting
> multisampled renderbuffers? This would be a very useful feature as currently
> there is no way to render full quality off-screen.
> -Brian
>
> On Thu, Mar 31, 2011 at 12:48 PM, Chris Marrin <[email protected]> wrote:
>>
>>
>> On Mar 31, 2011, at 12:33 PM, Kenneth Russell wrote:
>>
>> > On Thu, Mar 31, 2011 at 12:20 PM, Chris Marrin <[email protected]>
>> > wrote:
>> >>
>> >> On Mar 31, 2011, at 12:00 PM, Kenneth Russell wrote:
>> >>
>> >>>>> ...Also, we would need to specify interactions with
>> >>>>> OES_texture_float.
>> >>>>> Multisampled floating-point render targets would be extremely useful
>> >>>>> for high quality HDR rendering.
>> >>>>
>> >>>> Sure, but that should be yet another extension, since it is possible
>> >>>> to support one without the other.
>> >>>
>> >>> I don't think a third extension is needed. All that's needed is to
>> >>> specify that if both the OES_texture_float and this multisampling
>> >>> extension are enabled, then multisampling is enabled for
>> >>> floating-point renderbuffers (if the implementation supports it -- and
>> >>> the framebuffer's status will be FRAMEBUFFER_UNSUPPORTED otherwise).
>> >>
>> >> I don't know the reality in the drivers, but my concern is that there
>> >> may be some drivers that support OES_texture_float and some form of
>> >> framebuffer multisampling, but can't do multisampling with floating point
>> >> texture buffers. The author needs to know such a situation exists to know
>> >> how to allocate the supporting renderbuffers in the framebuffer.
>> >>
>> >> But that may be a moot point. Maybe you always get one with the other?
>> >
>> > Oops, my fault. I was confusing support for floating-point textures
>> > and floating-point renderbuffers. Multisampled FBOs require the use of
>> > renderbuffers, not textures, for the color attachment. Enabling
>> > OES_texture_float wouldn't affect the behavior of this multisampling
>> > extension.
>>
>> Ah, right. The model would have to be render into a multisample FBO with a
>> multisample renderbuffer then use a multisample blit (or
>> glResolveMultisampleFramebufferAPPLE for iOS) to get the result into a
>> normal, non-multisampled texture.
>> >
>> > If we wanted that behavior, you're right, we'd need to spec another
>> > extension adding floating-point renderbuffers. I don't know whether
>> > there are any OES extensions for that functionality today.
>>
>> Yeah, I haven't seen such a thing yet. But it's interesting that
>> multisampling essentially results in higher precision pixel values. An
>> interesting intermediate implementation could blit an integer multisample
>> renderbuffer into a floating point texture. But that's probably not valuable
>> enough for anyone to implement.
>>
>> -----
>> ~Chris
>> [email protected]
>>
>>
>>
>>
>> -----------------------------------------------------------
>> 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
-----------------------------------------------------------




More information about the public_webgl mailing list