|
I am very supportive of the Multiview extension. I think it will definitely help WebVR scenarios.
One aspect of the API that could use improvement is the following statement:
“The error INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and CopyTexSubImage*, if the number of views in the current read framebuffer is greater
than 1.” ReadPixels and CopyTexImage* are frequently used in test code to ensure correct rendering. Without these APIs, writing these types of tests will be challenging. Perhaps a future (or current?) version of the extension could add overloads
to these functions that contain an additional ‘view’ integer parameter that specifies the view on which to perform the operation.
--Rafael From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org]
On Behalf Of Olli Etuaho 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 |