I made a few changes. I can revert if they were wrongSince no data is allowed to be uploaded, many comments about texSubImage2D didn't seem to make senseso I removed them.
Updated a comment about framebufferTexture2D to also accept DEPTH_STENCIL_ATTACHMENTAdded an issue note about the fact that the alpha value of a depth texture is implementation dependent.Please review and post if you see any issues.On Wed, Jun 20, 2012 at 6:02 PM, Kenneth Russell <email@example.com> wrote:
Apologies for taking so long to get to this.On Wed, Jun 6, 2012 at 11:24 AM, Kenneth Russell <firstname.lastname@example.org> wrote:
> On Wed, Jun 6, 2012 at 11:04 AM, Gregg Tavares (çç) <email@example.com> wrote:
>> On Wed, Jun 6, 2012 at 1:19 AM, Florian BÃsch <firstname.lastname@example.org> wrote:
>>> On Wed, Jun 6, 2012 at 4:25 AM, Gregg Tavares (çç) <email@example.com>
>>>> Fine, then I ask others reading this list? are depth textures useful
>>>> without stencils? If you can't use a stencil buffer while using a depth
>>>> texture will that limit what you can do? It would certainly make the last 2
>>>> games I personally shipped impossible but hey, that's just one anecdote. If
>>>> no one else cares then I'm fine with WEBGL_depth_texture supporting depth
>>> I see these use-cases for depth textures:
>>> 1) Deferred shading requires at least 2 passes (albedo and byte packed
>>> depth/normal). If a floating point texture is used to capture depth/normal,
>>> that may be unsupported and/or slow. Depth textures could help to improve
>>> the precision attained for depth information while freeing more bytes on the
>>> color attachment to use for other things and not consume 4x the amount of
>>> 2) Post process blur would benefit from being possible to do with just one
>>> pass instead of two.
>>> 3) Particle fading for sprites near to scene surfaces would become
>>> possible with just one pass instead of two
>>> 4) Depth estimation of objects for reasons of subsurface scattering or
>>> translucency will require fewer passes.
>>> None of the above relies on stenciling.
>>> What use-cases are you thinking of that would be impossible without
>> Stenciling was used in LocoRoco to keep the faces in the characters since
>> they are based on spring physics it would seriously hard to clip in
>> Stenciling was used in Afro Samurai to provide any shape (ie,
>> non-rectangular) animated comic book like panels.
>> There's also the issue of fragmentation. We can add DEPTH_STENCIL now since
>> it can be emulated with DEPTH + STENCIL, same as it's emulated in the
>> current WebGL spec. Or we can leave it out and then have 4 more variations.
>> Browsers with neither depth_texture nor stencil, browsers with
>> depth_textures, browsers with depth_stencil and browsers with depth_texture
>> + depth_stencil.
>> I'd argue the current WebGL spec requires support for DEPTH_STENCIL so we're
>> already guaranteed to have the feature. Why fragment things more by leaving
>> it off here?
> I see your points. Florian's found that all mobile hardware supporting
> OES_depth_texture also supports OES_packed_depth_stencil, and on the
> desktop, the functionality will already be supported.
> ANGLE_depth_texture already supports depth/stencil textures.
> I'll update the WEBGL_depth_texture extension to add the enum
> UNSIGNED_INT_24_8_WEBGL. Textures allocated with this type and
> DEPTH_STENCIL format will only be legal to use as the
> DEPTH_STENCIL_ATTACHMENT to an FBO. The same restrictions will apply
> as in http://www.khronos.org/registry/webgl/specs/latest/#6.5 .
Since there weren't any objections, the WEBGL_depth_texture extension
draft has been updated with these changes:
Shift-reload if you see a stale copy.
The edits were fairly large. Please review and post if you see any issues.