[Public WebGL] Public review of updated WEBGL_multiview extension proposal
Mon Aug 21 08:02:22 PDT 2017
Yes, it's intended to work with both depth textures and multiple render targets. All color attachments that are attached with framebufferTextureMultiviewWebGL will be rendered to.
I do agree that WebGL 1.0 support is useful, though WebGL 2.0 support will surely ramp up given time. The main use case of the extension is VR, and especially on devices which are VR capable I'd expect widespread support for WebGL 2.0 already. We did consider some other alternatives for WebGL 1.0 compatibility for the proposal, but they all seemed fairly hacky. I don't think we want to expose rendering two viewports side by side in a 2D texture for example.
From: Florian Bösch <[email protected]>
Sent: Monday, August 21, 2017 2:16 PM
To: Olli Etuaho
Cc: Public WebGL ([email protected])
Subject: Re: [Public WebGL] Public review of updated WEBGL_multiview extension proposal
On Mon, Aug 21, 2017 at 10:02 AM, Olli Etuaho <[email protected]<mailto:[email protected]>> wrote:
In WebGL 1.0, only opaque multiview framebuffers can be supported. Texture array multiview framebuffers are available starting from WebGL 2.0.
Bit of a bummer since WebGL 2.0 has flatlined at ~30% and isn't growing and WebGL 1.0 for now is the only feasible platform. The prevalence of the OVR_multiview extensions on mobiles also seems particularly poor.
You may have misunderstood the native OVR_multiview spec a bit. The baseViewIndex only affects which texture layers get affected by drawing commands. There can still only be one attachment per attachment point. So if you call
int baseViewIndex = 7;
int numViews = 2;
FramebufferTextureMultiviewOVR(target, GL_COLOR_ATTACHMENT0, texture, level, baseViewIndex, numViews);
it means that texture layers 7 and 8 will be drawn to. This should be evident from the pseudocode in the spec.
Some additional questions:
* Does it work with depth textures?
* Does it work with multi render targets?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl