three.js: Oculus Quest VR: texImage3D is not a function

7.1 should be released this week, btw.

I just tested the apk and I can confirm OVR_multiview2 is not exposed in the WebGL1 context, and multiview is working as expected with no antialias context (Using this PR: https://github.com/mrdoob/three.js/pull/18178). I have tried also the rest of the examples and all of them works fine on the v7.1 Thanks @Artyom17 👍

Let me check really quick, I’ll report back.

Ok… For the blitFramebuffer issue. This is a bit confusing one. The issue is that the Browser “thinks” that it is composing into a multisampled framebuffer, even, though, the context was clearly setting “antialiasing” attribute to false in webxr_vr_multiview.html. The reason why it is doing that is this line in WebXRManager.js:

session.updateRenderState( { baseLayer: new XRWebGLLayer( session, gl ) } );

Note, that no init object is used here. However, the default one will be used, and this is where it becomes interesting.

The default XRWebGLLayer’s init object has default values for all attributes (from https://www.w3.org/TR/webxr/#xrwebgllayer-interface):

dictionary XRWebGLLayerInit {
  boolean antialias = true;
  boolean depth = true;
  boolean stencil = false;
  boolean alpha = true;
  boolean ignoreDepthValues = false;
  double framebufferScaleFactor = 1.0;
};

The default value of ‘antialias’ for the layer is true! And check the step #9 here, it suppose to take the AA attribute from the init object, not from the context (“composition disabled” is set to false in this case).

What should be done here is to change that line in WebXRManager.js to something like this:

session.updateRenderState( { baseLayer: new XRWebGLLayer( session, gl, { antialias: gl.getContextAttributes().antialias } ) } );

See PR https://github.com/mrdoob/three.js/pull/18178

CC /@mrdoob @fernandojsg

@Artyom17 nice catch on the layers’ attributes! It totally makes sense. thanks for looking into this so quickly 👍

Ok, I’ve fixed the original issue with the texImage3D and other non-working samples, and yes, that was a bug (reporting OVR_multiview2 as supported for WebGL 1). This fix will be shipped in 7.1 ASAP.

However, the multiview test case still doesn’t work because seems like blitFramebuffer is called on a multisampled framebuffer. I am still investigating this part.

Here’s some version numbers from the Go, as well as confirmation that OVR_multiview2 is showing up in WebGL1… check out the very bottom.

It seems that both OCULUS_multiview and OVR_multiview2 are enabled by default on Oculus Browser, and by the log that you shared it seems that both are using multisampled fbo, when just the OCULUS_multiview should be using multisampled fbo.