[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture
On Tue, Jun 5, 2012 at 3:58 PM, Gregg Tavares (社用) <firstname.lastname@example.org> wrote:
> On Tue, Jun 5, 2012 at 1:11 PM, Kenneth Russell <email@example.com> wrote:
>> On Tue, Jun 5, 2012 at 12:42 PM, Gregg Tavares (社用) <firstname.lastname@example.org>
>> > On Tue, Jun 5, 2012 at 12:37 PM, Florian Bösch <email@example.com> wrote:
>> >> On Tue, Jun 5, 2012 at 9:29 PM, Gregg Tavares (社用) <firstname.lastname@example.org>
>> >> wrote:
>> >>> In trying to implement this I'm running into issues
>> >>> #1) it looks like we'll need to restrict depth textures to level 0
>> >>> only.
>> >>> Reason: WebGL requires that we clear textures. Otherwise you could
>> >>> potential read uninitialized memory.
>> >>> We can clear a depth texture by attaching to an FBO and calling
>> >>> glClear
>> >>> but we can only attach to level 0
>> >>> in OpenGL ES 2.0 which means it's impossible to clear levels > 0.
>> >> I think that's fine, you can also only render to level 0 to other
>> >> textures
>> >> unless you have that other extension. Afaik the oes depth texture
>> >> extension
>> >> makes no mention that you should be able to render to level 1 and
>> >> upwards.
>> >>> #2) What should we do about GL_DEPTH_STENCIL format?
>> >>> WebGL requires support for GL_DEPTH_STENCIL as a renderbuffer format.
>> >>> It seems like it also needs to require support for GL_DEPTH_STENCIL as
>> >>> a
>> >>> texture format for WEBGL_depth_texture
>> >>> otherwise it's possible you can't use stencils with depth textures.
>> >>> I'm not sure what issues that brings up.
>> >> I don't think it is required that any combination of things you attach
>> >> to
>> >> an FBO does work. Some combinations will fail (they're also failing
>> >> right
>> >> now). It is required that at least some combination allows you to
>> >> render to
>> >> a stencil, depth and color buffer, but unless you try and validate the
>> >> FBO,
>> >> you're not gonna know.
>> > It's not required. The question is do we want to support stencils at all
>> > used with depth textures? IIRC Desktop GLs don't support creating a
>> > separate
>> > depth and stencil and attaching both. The only way to get both depth and
>> > stencil at the same time is to use DEPTH_STENCIL. So, if we don't add
>> > DEPTH_STENCIL support to WEBGL_depth_texture then there will effectively
>> > be
>> > no way to use a stencil with a depth texture. Of course maybe my memory
>> > is
>> > bad. I thought that's why we added DEPTH_STENCIL in the first place to
>> > WebGL
>> > but I could be remembering incorrectly.
>> I recall the reason for adding the DEPTH_STENCIL attachment point to
>> WebGL was twofold: first, this is the direction the OpenGL spec had
>> taken; and second, it was too difficult to emulate the behavior of
>> separate vs. packed depth and stencil attachments on top of the other
>> functionality. (OpenGL ES 2.0 devices supported separate
>> depth/stencil, but desktop platforms only supported packed
>> Anyway, it looks like GL_OES_packed_depth_stencil is actually the
>> extension that adds depth-stencil support to GL_OES_depth_texture.
>> In sum, it looks like a packed depth/stencil extension could be added
>> to the WebGL extension registry later, and have it modify the behavior
>> of WEBGL_depth_texture, like in the OES specs. What do you think?
> There's no reason to ever add OES_packed_depth_stencil to WebGL since WebGL
> already effectively requires it. Hence why I brought this up. Since WebGL
> already requires the same behavior as OES_packed_depth_stencil that kind of
> implies that WEBGL_depth_texture should support DEPTH_STENCIL formats.
WebGL's support for depth/stencil renderbuffers is different from what
OES_packed_depth_stencil mandates. WebGL added
DEPTH_STENCIL_ATTACHMENT; OES_packed_depth_stencil requires that the
packed depth/stencil renderbuffer be attached to both the depth and
stencil attachment points. This was a deliberate design decision in
order to allow easy implementation of WebGL on both systems supporting
only separate depth/stencil renderbuffers as well as systems
supporting only packed depth/stencil renderbuffers.
For this reason it seems to me that OES_packed_depth_stencil should
still be a separate extension even in WebGL as it stands today. Either
that, or the WebGL spec should be changed to introduce the
DEPTH24_STENCIL8 renderbuffer internal format, and the FBO attachment
rules should be updated. I'd lean toward leaving it as an extension.
>> Florian, do you know (or could you find out) how many devices support
>> OES_packed_depth_stencil? Looks like it's well supported on iOS, at
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: