Warnings in console on Quest when WebXR layers are enabled.

[sigmaxipi]

Describe the bug

WebGL: INVALID_OPERATION: drawBuffers: COLOR_ATTACHMENTi_EXT or NONE warning each frame when WebXR layers are enabled.

To Reproduce

Steps to reproduce the behavior:

1. Use an Oculus Quest with WebXR layers enabled
2. Attach a Chrome debugger to the Quest browser
3. Go to https://threejs.org/examples/?q=layer#webxr_vr_layers and enter VR
4. See warnings in log followed by WebGL: too many errors, no more errors will be reported to the console for this context.

Code

I'm not familiar enough with Three.js to submit a fix for this, but I tracked down the issue to WebGLRenderer.js. If you add if (!xr.isPresenting) { around the code that sets _currentDrawBuffers[ 0 ] = _gl.BACK;, the warnings go away. This call interferes with the gl.framebufferTexture2D( gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0,... ); in WebXRManager. Ideally, the check would be something like if (!xr.isPresenting || !areWebXrLayersEnabled) , but I'm not sure what cleanest way is for determining if XR layers enabled in that class.

Platform:

• Device: Quest 2
• OS: oculus/hollywood/hollywood:10/QQ3A.200805.001/17007100222900000:user/release-keys
• Browser: Mozilla/5.0 (X11; Linux x86_64; Quest 2) AppleWebKit/537.36 (KHTML, like Gecko) OculusBrowser/16.1.0.3.48.300946211 SamsungBrowser/4.0 Chrome/91.0.4472.114 Safari/537.36
• Three.js version: r130

[Mugen87]

Can you please try the dev version of three.js? Maybe this is fixed because of #22074.

[Mugen87]

Closing. We can reopen the issue if this still happens with the latest dev build.

[sigmaxipi]

This is still happening as of 10 hours ago using 8837fac

https://sxp.me/three.js/examples/webxr_vr_layers.html uses that dev build and shows warnings when you enter VR on the Quest.

[Mugen87]

Can you please test again on dev (see #22127)?

[sigmaxipi]

This is still happening but #22145 fixes the warnings.

[klausw]

I investigated this as part of google/model-viewer#2769 (reply in thread) , it also happens in <model-viewer> when rendering shadows.

If I'm understanding it right, the problem is that GL_BACK is only valid for drawBuffers when using the default framebuffer. However, state.bindFramebuffer(..., null) has an override to use the XR opaque framebuffer instead of the default framebuffer, and that's a bound FBO for which GL_BACK is not valid.

[mrdoob]

I investigated this as part of google/model-viewer#2769 (reply in thread) , it also happens in <model-viewer> when rendering shadows.

@takahirox I think this issue comes from the MRT code.

[takahirox]

We attempt to set draw buffers matching to a framebuffer when we switch render target and framebuffer in renderer.setRenderTarget()

https://github.com/mrdoob/three.js/blob/r132/src/renderers/WebGLRenderer.js#L1904-L1968

But WebXRManager directly switches framebuffer without using renderer.setRenderTarget() so appropriate draw buffers may not be set for XR.

https://github.com/mrdoob/three.js/blob/r132/src/renderers/webxr/WebXRManager.js#L624
https://github.com/mrdoob/three.js/blob/r132/src/renderers/webgl/WebGLState.js#L431-L441

I speculate this is the cause. A solution may be moving the draw buffer update code to WebGLState and attempt to set appropriate draw buffers anytime when framebuffer is switched.

[mrdoob]

@cabanier Is it possible to use renderer.setRenderTarget() in WebXRManager?

[cabanier]

I will try that

[cabanier]

@mrdoob it seems using renderer.setRenderTarget() would be a much better way to go.
For classic WebXR, we might have to update it so you can pass a framebuffer and signal that it will use multisampling.

I might wait until #22550 is merged before making this change.

[cabanier]

@mrdoob #22558 will fix this issue.
Who would be best to look at this change? I had a couple of people look at it internally but they are not as familiar with three.

[hybridherbst]

We're hitting this issue with the current release; can anyone confirm if #22558 should already be in effect?

It seems that after XR working for a while, at some point it simply stops working (always not working when the warning "three.module.js:27039 WebGL: INVALID_OPERATION: drawBuffers: COLOR_ATTACHMENTi_EXT or NONE" is logged), and then only a browser restart brings XR back (even closing the tab and reopening it doesn't always fix the issue).

Also happy to open another issue with this if it might be separate (WebXR in threejs breaking randomly when this warning shows up and then not recovering).

(in case that matters, happens in Chrome with Quest + Link)

[cabanier]

(in case that matters, happens in Chrome with Quest + Link)

Does that mean it doesn't happen on Quest?
If it only happens on Link and you can provide a reproducible case, I can forward it to the right engineering team.

[hybridherbst]

That sounds great – I'll make sure to try to have clear repro steps and post here tomorrow @cabanier. What I can already say is that it does not trivially reproduce with e.g. https://immersive-web.github.io/webxr-samples/spectator-mode.html (which would have been surprising), so might be a threejs issue with ordering etc.

Some initial info: we're seeing slightly different issues on Quest and via Quest + Link, but most of them seem related to this warning (or more general, binding of buffers).

Quest+Link:

1. sometimes when entering XR the entire world "freezes" on one frame and never gets another update
2. sometimes there's a dark-gray room with a floor pattern, either also frozen on one frame or sometimes responsive but still only that dark patterned room
3. after repeatedly entering/exiting XR (to find a state where the above doesn't happen), sometimes Chrome just silently crashes (not only the tab, the entire browser closes).

Quest Browser:
4. even before entering XR, sometimes loading a WebGL page crashes the browser and then one is stuck in the Home environment with buttons not working, only option is full device restart. The device attempts to restart automatically after ~10 minutes or so in this state, but is then stuck in a "black room" and requires a forced restart (30s power button or so)
5. when the presence sensor is hidden for just a tiny amount of time (e.g. when lifting the headset ever so slightly to put it on your forehead), tracking is lost but the WebXR context isn't exited, Quest just renders a medium gray image and only recovers after tab refresh

I think some of these might be related to the warning, at least from what we're seeing when the warning appears WebXR always breaks (in different ways). Still, these issues all don't quite belong in this thread, please let me know if there's a better place to continue this discussion.

[sigmaxipi]

This isn't happening anymore with r144, OculusBrowser/23.1.0.3.50.396244958, hollywood:10/QQ3A.200805.001