[Public WebGL] Public review of updated WEBGL_multiview extension proposal

Florian Bösch [email protected]
Fri Aug 18 06:41:43 PDT 2017

I'm a little confused by the example. In the example you do:

gl.bindTexture(gl.TEXTURE_2D_ARRAY, tex);
> gl.texStorage3D(gl.TEXTURE_2D_ARRAY, 1, gl.RGBA8, 512, 512, 2);
> But the specification states that:

Written against the WebGL API 1.0
> <http://www.khronos.org/registry/webgl/specs/1.0/> specification.

Which confuses me because WebGL 1.0 does not support 2D texture arrays, nor
is there an extension for it.

I also don't see how you'd attach a dual depth or stencil buffer that way
(since there is no such thing as a depth buffer array or stencil buffer

To my understanding the OVR_multiview extension regulates the presence of
multiple attachments of the same type (but for different views) with the
parameter to FramebufferTextureMultiviewOVR baseViewIndex. Though I also
fail to see how mechanism would account for multiple depth/stencil buffers
because those would be attached with the function framebufferRenderbuffer
and that function does not support multiple attachment points.


   1. How is it going to work in WebGL 1 which it claims to be written
   against using array textures which don't exist in WebGL1?
   2. How are you going to attach a multiview depthbuffer when neither the
   OVR_multiview extension nor this extension makes any provision for it?

On Fri, Aug 18, 2017 at 3:12 PM, Olli Etuaho <[email protected]> wrote:

> Hello all!
> We have a significantly updated version of the WEBGL_multiview extension
> proposal, and kindly request the community's feedback on it so we can
> incorporate the feedback and proceed to move the extension to draft:
> https://www.khronos.org/registry/webgl/extensions/
> proposals/WEBGL_multiview/​
> I hope this addresses the major concerns people had with regards to the
> extension in the previous discussion earlier during the year.
> The extension is now self-contained and is designed not to require any
> amendments to the core WebGL spec. But since enabling the implementation of
> a zero-copy multiview pipeline is still a goal, an "opaque multiview
> framebuffer" abstraction has been added to the extension proposal. This is
> a type of a multiview framebuffer that other web APIs like WebVR would be
> able to create, and that would work also with WebGL 1.0. The specific
> shape of the WebVR API to create this type of framebuffers will still need
> to be specified within the WebVR working group.
> We have also worked on implementing functionality that would be required
> by the extension in ANGLE, and the new revision of the proposal has taken
> findings from that work into account. Particularly, we've removed
> restrictions on shaders since we found out the restrictions won't be
> necessary for good performance. On the other hand, we've added some minor
> restrictions that are required by a performant implementation on top of
> OpenGL and Direct3D, like baseViewIndex having to match between different
> framebuffer attachments.
> Regards, Olli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170818/fd45ebae/attachment.html>

More information about the public_webgl mailing list