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

Re: [Public WebGL] Public review of updated WEBGL_multiview extension proposal



In WebGL 1.0, only opaque multiview framebuffers can be supported. Texture array multiview framebuffers are available starting from WebGL 2.0. Creating depth/stencil textures is also possible in WebGL 2.0, so the need for depth-testing is covered. I'll clarify this in the WEBGL_multiview proposal.


You may have misunderstood the native OVR_multiview spec a bit. The baseViewIndex only affects which texture layers get affected by drawing commands. There can still only be one attachment per attachment point. So if you call


int baseViewIndex = 7;

int numViews = 2;

FramebufferTextureMultiviewOVR(target, GL_COLOR_ATTACHMENT0, texture, level, baseViewIndex, numViews);

it means that texture layers 7 and 8 will be drawn to. This should be evident from the pseudocode in the spec.


-Olli


From: Florian Bösch <pyalot@gmail.com>
Sent: Friday, August 18, 2017 4:46 PM
To: Olli Etuaho
Cc: Public WebGL (public_webgl@khronos.org)
Subject: Re: [Public WebGL] Public review of updated WEBGL_multiview extension proposal
 
P.S. I'm assuming of course that it's self evident that rendering with depth-testing (and hence the presence of a depth buffer) is something that's rather often what people will want to do.

On Fri, Aug 18, 2017 at 3:41 PM, Florian Bösch <pyalot@gmail.com> wrote:
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 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 array).

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.

TL;DR:
  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 <oetuaho@nvidia.com> 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