[Public WebGL] WEBGL_multiview discussion
Wed Jan 11 08:41:44 PST 2017
I previously suggested that I’d put the proposed core spec changes in a regular pull request against the spec. However, after a bit of discussion it was requested that I’d include the proposed core spec changes in the extension document instead, since the extension is related, and it’s easier to discuss them together. I agree it’s unintended usage of the extension template, but I’m not sure what a better third alternative would be. Would others have suggestions on how to organize the proposal better?
Please read the spec carefully. It says that it is forbidden to call drawBuffer() when an FBO is bound. On the other hand drawBuffers() and framebufferTextureMultiview() only operate on FBOs. So there’s no unspecified interaction. Also, the native OVR_multiview spec says “The number of views, as specified by numViews, must be the same for all framebuffer attachments points where the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is not NONE or the framebuffer is incomplete.”. I think the native spec may have a bug when it describes the effect of draw commands, it seems as if only one texture array’s layers are being toggled, but this should be quite easy to fix.
From: Florian Bösch [mailto:[email protected]]
Sent: keskiviikkona 11. tammikuuta 2017 15.54
To: Olli Etuaho <[email protected]>
Cc: Rafael Cintron <[email protected]>; Mark Callow <[email protected]>; Maksims Mihejevs <[email protected]>; public webgl <[email protected]>
Subject: Re: [Public WebGL] WEBGL_multiview discussion
On Tue, Jan 10, 2017 at 5:20 PM, Olli Etuaho <[email protected]<mailto:[email protected]>> wrote:
1. BACK_LEFT and BACK_RIGHT are intended to be included in WebGLRenderingContextBase. Note the disclaimer at the top: “These changes are written here in the extension document in order to facilitate discussion of the proposal. They are intended to be merged to the core WebGL specification and removed from here at a later date.”
So far no extension has followed that pattern. WebGL extensions have always defined their properties on the extension object, even if some of those symbols are later put into a standard. I don't it's consistent.
2. drawBuffer is intended to be included in WebGLRenderingContextBase.
Same objection as above.
3. drawBuffer() and drawBuffers() are separate entry points, they don’t have any special relationship just because they are named similarly. The similar naming is a bit unfortunate, but it’s inherited from desktop GL.
drawBuffers enables writing to multiple surfaces. drawBuffer sets which views are rendered to. The framebufferTextureMultiviewWEBGL function sets up a texture to be attached to an attachment point and view (left or right).
Is it correct to assume if you render to multiple render targets at the same time and if those targets are set up to be stereo with framebufferTextureMultiviewWebGL (which attaches them to the framebuffer object, right?), that all attached rendertargets get stereo rendering?
What happens if one is stereo and another isn't? Is this an error, does it go silently?
There clearly are interactions between drawBuffers, drawBuffer and framebufferTextureMultiviewWebGL, but this extension doesn't lay it out.
4. See 5.
5. The current extension proposal is not compatible with WebGL 1.0, though the proposed core spec changes apply to WebGL 1.0. If a WebGL 1.0 version of the multiview extension is desired, it might make the most sense to specify that separately from the WebGL 2.0 extension. Doing that only makes sense after there’s an agreement on what goes to the core spec, though.
6. Including a very simple API usage example is a good idea, but I don’t think the extension document needs to go beyond that. The spec document is not a tutorial.
It's a complex (one of the most complex extensions) in the registry. In addition it introduces a host of behavioral changes unique to WebGL. I think it deserves a bit more examples than is usual for extensions because of that. And it should have a brief example of each major usage scenario.
7. The interaction with WebVR needs to be specified in the WebVR spec. So far this has been discussed only informally.
That's true, but since this extension interacts with WebVR it would be good if it pointed out how.
I’m working on fixing some of the smaller omissions you pointed out. The organization of the extension document is controlled by the XML transform for extensions, unfortunately that isn’t working that great with the current state of the document which includes the core spec changes.
It wasn't meant to. Extensions have never been a core/extension hybrid I think it's weird.
On the extension/core hybrid extension, I think that a much more proper way to do things was to offer the extension self-contained, and if somebody wants to write forward compatible core code, they can polyfill the feature from the extension.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl