[Public WebGL] Public review of updated WEBGL_multiview extension proposal

Florian Bösch [email protected]
Fri Aug 18 06:46:22 PDT 2017


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 <[email protected]> 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
>> <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
> 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 <[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/7e0016b1/attachment.html>


More information about the public_webgl mailing list