[Public WebGL] More WebGL extensions

Brian Cornell [email protected]
Wed May 18 14:35:04 PDT 2011


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
> -----------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110518/77864f09/attachment.html>


More information about the public_webgl mailing list