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

Re: [Public WebGL] WEBGL_texture_from_depth_video extension proposal



It seems like it would already require a bunch of code, to me. I'm not sure how using packed 565 instead of something else requires less code.

The current proposal is an ugly hack, and I'd like to be sure there's no better way before considering implementing it.
"We already have this working in prototype" is not a convincing argument for the quality of a spec.

If all of the target devices support depth textures, but not GLES3, the spec should use depth textures.

In GLES3, we get R16UI, though it isn't normalized. It has the same capabilities as DEPTH_COMPONENT16, anyways. (sampleable and renderable, but not filterable) It seems like you'd want normalization for something like this, but maybe not? If renderability isn't important, R32F could give normalization with sufficient precision.

Regardless of all of this, like GL extensions do, it would be better if this extension proposal had a brief discussion of reasoning for why it makes the tradeoffs it does. 

-Jeff

----- Original Message -----
From: "Rob Manson" <roBman@buildAR.com>
To: "Kenneth Russell" <kbr@google.com>
Cc: "Daniel Koch" <dkoch@nvidia.com>, "Jeff Gilbert" <jgilbert@mozilla.com>, "Florian Bösch" <pyalot@gmail.com>, "public webgl" <public_webgl@khronos.org>, "Ningxin Hu" <ningxin.hu@intel.com>
Sent: Tuesday, November 11, 2014 4:11:06 PM
Subject: Re: [Public WebGL] WEBGL_texture_from_depth_video extension proposal

+1 for this and to us not creating more work for implementers.


On 12/11/14 10:46 AM, Kenneth Russell wrote:
> 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.


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