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

Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture

Thanks, these simplifications look good. I fixed up a couple of tiny typos (without updating the revision number -- didn't seem worth it).


On Wed, Jun 27, 2012 at 10:02 PM, Gregg Tavares (社用) <gman@google.com> wrote:
I made a few changes. I can revert if they were wrong

Since no data is allowed to be uploaded, many comments about texSubImage2D didn't seem to make sense
so I removed them.

Updated a comment about framebufferTexture2D to also accept DEPTH_STENCIL_ATTACHMENT

Added 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 <kbr@google.com> wrote:
On Wed, Jun 6, 2012 at 11:24 AM, Kenneth Russell <kbr@google.com> wrote:
> 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 .

Apologies for taking so long to get to this.

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.