[Public WebGL] WEBGL_texture_from_depth_video extension proposal

Rob Manson [email protected]
Tue Nov 11 15:29:29 PST 2014


Hi Daniel (and Jeff),

isn't the key blocking point that WEBGL_depth_texture doesn't support 
uploading via texImage2D/texSubImage2D? See this comment in the Overview 
of the extension doc[1].

   "ANGLE_depth_texture does not support loading image data via the
    TexImage or TexSubImage commands. Depth and depth/stencil textures
    created via this extension can only have their contents specified by
    rendering to them."

Or am I misunderstanding something?

roBman

[1] https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/


On 12/11/14 9:59 AM, Daniel Koch wrote:
>
> 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
>> comparison.
>>
>> 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
> Etc.
>
> 				
> 			
> 		
> 	
>
>
>>
>>
>> -Daniel
>>
>> 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]>
>>> wrote:
>>>> 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
>>>> with
>>>> 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
>>> anyway
>>> - 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.
>>>
>>> -Ken
>>>
>>> -----------------------------------------------------------
>>> 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