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

Re: [Public WebGL] WEBGL_texture_from_depth_video extension proposal



On Tue, Nov 11, 2014 at 2:59 PM, Daniel Koch <dkoch@nvidia.com> wrote:
>
> On 2014-11-11 10:55 PM, "Daniel Koch" <dkoch@nvidia.com> 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.

Thanks for the correction.


On Tue, Nov 11, 2014 at 3:29 PM, Rob Manson <roBman@buildar.com> wrote:
> 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?

You're correct. However, my understanding is that it's a limitation
which may have to be lifted in the future anyway.

I still think it's reasonable to limit depth camera texture uploads to
just 5_6_5 textures in WebGL 1.0. WebGL 2.0 implementations are
actively being developed and spending excessive time on the 1.0 code
paths will just delay their release. Intel's already implemented the
depth stream upload path to 5_6_5 textures and shown some demos
publicly, so integrating this support will take very little time.

-Ken


> 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" <dkoch@nvidia.com> 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" <kbr@google.com> wrote:
>>>
>>>>
>>>> On Mon, Nov 10, 2014 at 8:16 PM, Jeff Gilbert <jgilbert@mozilla.com>
>>>> 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 <pyalot@gmail.com>
>>>> 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 <khronos@callow.im> 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 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
>>>> -----------------------------------------------------------
>>>>
>>>
>>
>>
>

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