|
Trying to answer the questions here: The extension document includes proposed changes to the core WebGL 1.0 spec to enable creation of stereo default framebuffers. This is required to introduce an opaque stereo
framebuffer concept which can be implemented under the hood in various ways, such as side-by-side images inside a single texture, as a texture array, or as a native stereo framebuffer. This makes it possible to avoid extra copies in the display pipeline. Basically
the API user would set context creation parameter “stereo: true” and then get a stereo default framebuffer back. Support can be checked by querying the actual context creation parameters. We want stereo canvases in WebGL 1.0 so that existing WebVR applications that are built on WebGL 1.0 will be able to easily migrate to using them. It also makes the spec simpler.
I would expect practically all WebVR capable hardware to eventually support WebGL 2.0, though. In the current proposal using shaders that don’t declare numViews can’t be used to render to multiple views with a single draw command. Whether multiple views can be cleared
with a single clear() command is not clearly defined in the native OVR_multiview spec either, and needs to be either fixed there or defined in the WebGL version of the extension spec. The question is whether these things should be possible, maybe even in the
core spec when using a stereo framebuffer. We’re trying to keep the WebGL extension spec close to OVR_multiview, but unfortunately OVR_multiview is quite vague in many respects and needs to be tightened for WebGL. Also
the WebGL spec needs to be reasonably implementable on top of different APIs like DirectX as well, which requires some changes like the support for opaque stereo framebuffers. -Olli From: Florian Bösch [mailto:pyalot@gmail.com]
On Mon, Jan 2, 2017 at 6:14 PM, Olli Etuaho <oetuaho@nvidia.com> wrote:
I'm not sure I understand the question. How is a stereo canvas requested?
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:
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:
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:
|