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

Re: [Public WebGL] Proposal for depth and stencil FBO attachments

On Feb 25, 2010, at 11:28 AM, Kenneth Russell wrote:

> There is a problem implementing the current WebGL (and OpenGL ES) semantics for depth and stencil attachments to framebuffer objects on desktop OpenGL. On the desktop, the best supported functionality for adding a stencil buffer to an FBO is to use EXT_packed_depth_stencil. The renderbuffer is allocated with the GL_DEPTH_STENCIL or GL_DEPTH24_STENCIL8 format and is attached to both the GL_DEPTH_ATTACHMENT and GL_STENCIL_ATTACHMENT points of the framebuffer. Separate depth and stencil renderbuffer attachments to FBOs are not well supported.
> On OpenGL ES, the only functionality guaranteed to be supported is separate depth and stencil attachments, though there is a GL_OES_packed_depth_stencil extension.
> Because of how renderbuffers are allocated and attached to FBOs, it is very difficult to emulate the behavior of separate depth and stencil attachments when the underlying platform only supports packed depth and stencil. However, it is easy to emulate the behavior of packed depth and stencil attachments when the underlying platform only supports separate attachments. The reason is that at the point glRenderbufferStorage is called with the packed format, a hidden second renderbuffer can be generated and allocated. There is no good place to do this if the separate depth and stencil renderbuffers are exposed in the public API; glFramebufferRenderbuffer is the best interposition point, but it is a poor one.
> To make it feasible to implement stencil buffer support for FBOs on all platforms I would like to propose the following specification changes.
> 1. Add the enum DEPTH_STENCIL (0x84F9), which is accepted as the internalformat parameter of renderbufferStorage.
> 2. Add the enum DEPTH_STENCIL_ATTACHMENT (0x821A) from OpenGL 3, which is accepted as the attachment parameter of framebufferRenderbuffer.
> 4. State that it is an error to attach the same renderbuffer to both the DEPTH_ATTACHMENT and DEPTH_STENCIL_ATTACHMENT attachment points of a framebuffer object.
> 5. Add a subsection to the spec describing the difference in behavior compared to OpenGL ES 2.0.

I'm fine with changes like this. But I don't understand why we can't do it all under the covers. If you specify separate depth and stencil renderbuffers, can't we internally combine them if needed? Alternatively, if the implementation requires it, can't we ALWAYS just allocate a packed stencil/depth buffer and just ignore one of the attachment calls if both are made? For instance, when a renderbuffer is created as depth or stencil, we can defer the actual creation of the buffer. When one is attached, we can create a depth/stencil buffer and attach that. When the other is attached, we can just ignore it.

I haven't thought about all the implications, but I'd like to use an approach where we don't have to change the spec from the author's standpoint. But if necessary, the rule changes you specify seem fine.

> These changes would move the WebGL spec closer to OpenGL 3's behavior and would be implementable on both desktop GL and OpenGL ES 2.0 without OES_packed_depth_stencil. They would also have the benefit of being easily implementable on top of D3D. They are a subset of OES/EXT_packed_depth_texture and OpenGL 3 functionality.
> The only downside compared to the current API is the inability to attach a stencil buffer without a depth buffer, which I don't think is important.

But you can specify a stencil buffer without a depth buffer. Most implementations would just give you both internally, which should be transparent to the outside, right?


You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: