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

Re: [Public WebGL] WEBGL_multiview discussion

On Mon, Jan 2, 2017 at 6:14 PM, Olli Etuaho <oetuaho@nvidia.com> wrote: 

1. Why not just enable WEBGL_multiview extension automatically when a stereo canvas is requested? Support for stereo canvas requires core spec changes either way. The biggest hurdle for this I see is that WEBGL_multiview requires layout qualifiers, which do not exist in core WebGL 1.0 shaders, so it would be a bad fit for WebGL 1.0.

I'm not sure I understand the question. How is a stereo canvas requested?

2. Should drawing commands that don’t use multiview shaders be compatible with choosing both default framebuffer draw buffers with gl.BACK? This could be done similarly for clears as well.

Also not sure I understand this one, can you elaborate?

On Tue, Jan 3, 2017 at 2:48 AM, Mark Callow <khronos@callow.im> wrote:
Why does this extension need to be supported on WebGL 1.0? Browsers are on the verge of removing the flags that are currently hiding their WebGL 2 implementations.
 If something can be supported in WebGL1 in principle, it's worth investigating because WebGL1 will be the only choice for a long time long after WebGL2 activation by some or other UA. That's because either other UAs haven't implemented WebGL2 yet, or because the hardware does not support it, or the hardware/drivers exhibit blacklistable flags for the WebGL2 implementation (but not WebGL1).

On Tue, Jan 3, 2017 at 3:19 AM, Mark Callow <khronos@callow.im> wrote:
The question in this case is whether any of this hardware can support stereo canvases?
That's irrelevant.

The ES extension for multiview https://www.khronos.org/registry/gles/extensions/OVR/multiview.txt refers to OpenGL ES 3.0 as required. It doesn't matter what the hardware supports or not, unless an API revision of ES 3.0 is used (both on the front-end as well as on the backend, or something better), OVR_multiview cannot be exposed.

It's unfortunate that that means OVR_multiview can't go on WebGL1, but it is what it is. And unless we're willing to break with the parent standards intentionally (please don't), that's the way it is.


I have some questions regarding this extension:
  1. The extension definition does not follow the customary form of extensions so far defined that mirror underlying ES extensions. Can you elaborate why?
  2. How does an application switch between stereo and non stereo rendering? (a common thing that web pages would do depending if the user wishes to interact with a HMD or with a monitor)
  3. Does this extension integrate with WebVR in any way?