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

Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture

Hi all,

another question concerning depth textures: is it still correct that readPixels is not yet implemented for FLOAT (I got an error when trying to use it and also found a corresponding bug report in the Mozilla bug tracker) and if true, when do you expect to be able to provide such an implementation?


Am 28.06.2012 07:02, schrieb Gregg Tavares (çç):
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

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>

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>
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
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

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
that may be unsupported and/or slow. Depth textures could help to
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

2) Post process blur would benefit from being possible to do with just
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
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
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
Browsers with neither depth_texture nor stencil, browsers with
depth_textures, browsers with depth_stencil and browsers with
+ depth_stencil.

I'd argue the current WebGL spec requires support for DEPTH_STENCIL so
already guaranteed to have the feature. Why fragment things more by
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.


----------------------------------------------------------- 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 -----------------------------------------------------------