[Public WebGL] WEBGL_texture_from_depth_video extension proposal

Daniel Koch [email protected]
Tue Nov 11 14:59:57 PST 2014

On 2014-11-11 10:55 PM, "Daniel Koch" <[email protected]> wrote:

>"If a non-shadow texture call is made to a
>sampler that represents a depth texture with depth comparisons turned
>on, then results are undefined."
>I believe this just means that if you want the non-shadow comparison for a
>depth texture (i.e. the raw values) you just have to turn off the depth
>ES 3.0 spec section 3.8.15 says: "If the currently bound texture¹s base
>internal format is DEPTH_COMPONENT or DEPTH_STENCIL, then
>TEXTURE_COMPARE_MODE and TEXTURE_COMPARE_FUNC control the output of the
>texture unit as described below. Otherwise, the texture unit operates in
>the normal manner and texture comparison is bypassed."

And a few lines later:

If the value of TEXTURE_COMPARE_MODE is NONE, then
r = Dt


>On 2014-11-11 10:38 PM, "Kenneth Russell" <[email protected]> wrote:
>>On Mon, Nov 10, 2014 at 8:16 PM, Jeff Gilbert <[email protected]>
>>> Are there a large number of devices which support 16-bit depth sensing
>>>but do not support a depth_texture equivalent extension? depth_texture
>>>has overwhelming support everywhere but older Android. Any GLES3 device
>>>would have it, though.
>>Uploading a depth camera's output to an OpenGL depth texture won't
>>work. The only thing an OpenGL depth texture can be used for is a
>>depth comparison with other geometry in the scene. The GLSL ES 3.00.4
>>spec section 8.8 says "If a non-shadow texture call is made to a
>>sampler that represents a depth texture with depth comparisons turned
>>on, then results are undefined." The application will always have to
>>perform some post-processing of the depth camera's output, so it has
>>to be uploaded into a non-depth texture.
>>On Mon, Nov 10, 2014 at 10:59 PM, Florian Bösch <[email protected]> wrote:
>>> For these reasons, what's likely going to happen with these depth
>>>values in
>>> practical use, is this:
>>> upload the depth to 5-6-5
>>> decode the depth to some interpolatable format
>>> use the depth data
>>> It'd a rare usecase indeed that somebody would want to directly work
>>> the data as-is.
>>I think that's overstating the case. Sampling with NEAREST filtering
>>will probably work fine for a significant class of applications.
>>The application can render the 5_6_5 texture into an FBO with another
>>format if it wants to do a GPU-GPU conversion. I think it is not a
>>good idea to put this code into the browser because:
>> - The browser will be responsible for a plethora of format conversions
>> - All of these conversions will have to be tested
>> - Any bugs in them will have to be worked around by the application
>> - They can be implemented with the same efficiency, portably, by the
>>application in JavaScript, using WebGL
>>On Tue, Nov 11, 2014 at 5:21 AM, Mark Callow <[email protected]> wrote:
>>> Capturing depth video into a texture has basically the same needs as
>>>capturing regular video. So this extension and WEBGL_dynamic_texture
>>>should be developed together. The synchronisation features will be
>>>needed by both types of data.
>>> The Media Capture Stream must be something fairly recent as I don¹t
>>>recall seeing it when I was writing WDT but it clearly should be one of
>>>the sources that can be used with dynamic textures.
>>Let's certainly move WEBGL_dynamic_texture forward. These two
>>extensions don't need to gate each other.
>>You are currently subscribed to [email protected]
>>To unsubscribe, send an email to [email protected] with
>>the following command in the body of your email:
>>unsubscribe public_webgl

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list