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@example.com]
On Tue, Jan 10, 2017 at 5:20 PM, Olli Etuaho <firstname.lastname@example.org> wrote:
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.
Same objection as above.
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.
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.
That's true, but since this extension interacts with WebVR it would be good if it pointed out how.
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.