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

Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture



On Wed, Jun 6, 2012 at 11:04 AM, Gregg Tavares (çç) <gman@google.com> wrote:
>
>
> On Wed, Jun 6, 2012 at 1:19 AM, Florian BÃsch <pyalot@gmail.com> wrote:
>>
>> On Wed, Jun 6, 2012 at 4:25 AM, Gregg Tavares (çç) <gman@google.com>
>> wrote:
>>>
>>> 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
>>> only.
>>
>>
>> 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
>> bandwidth.
>>
>> 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?
>
>
> 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
> software.
>
> 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 .

OK?

-Ken

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