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

Re: [Public WebGL] WEBGL_multiview discussion



On Tue, Jan 10, 2017 at 5:20 PM, Olli Etuaho <oetuaho@nvidia.com> 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.