setRenderTarget warning

[gjcope]

Curious if anyone has any insight into the "invalid operation" gl warning that pops up (at least in Chrome) when doing the initial shadow render in AR. It doesn't seem to cause any issues, but I've seen it come up in other Three.js projects as well and don't have a good handle on what gl doesn't like about the render target when in XR mode.

Any thoughts?

[elalish]

I noticed this and asked the WebXR team about it back when I first implemented it, but now I can't remember the answer. Only that it was safe to ignore and difficult to remove. @klausw do you remember? Is there some reason WebXR throws warnings for offscreen rendering?

[klausw]

@elalish, I think you may have meant a different issue? There are some expected GL errors when ending an AR session, these are due to the trusted browser process owning the buffers used for cross-process image transport. When the session ends, the browser process deletes them, leaving the references used for asynchronous drawing via the Renderer process invalid. That would be hard to fix since we don't want to wait for a potentially-unresponsive Renderer process before cleaning up resources. See https://bugs.chromium.org/p/chromium/issues/detail?id=1100997 which mentions the shutdown issue (expected) along with a first-frame issue which was a bug and fixed.

As for the drawBuffers error, that appears to be https://developer.mozilla.org/en-US/docs/Web/API/WebGL2RenderingContext/drawBuffers where the Blink WebGL 2 implementation throws the error from this code location: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webgl/webgl2_rendering_context_base.cc;l=3725;drc=ba2e4cba569018f72e3e211dc5d5c4ae3f52ff62

If I'm reading it right, this code path happens when drawing to a framebuffer object, where the only legal values are GL_NONE and COLOR_ATTACHMENT[i]_EXT. Notably, GL_BACK is not valid here - the "draw to the back buffer" choice is only legal when drawing to the default framebuffer.

Can you add logging to see what value is setting? One possible hypothesis is that it might be confused by the WebXR opaque framebuffer, is it trying to use GL_BACK with that?

[elalish]

Thanks @klausw! Yes, that sounds right. We don't touch anything so low level in MV, so I'd guess this is a three.js thing regarding shadows in WebXR. I'm still 50/50 on whether it's a Chrome or three.js bug though.

[gjcope]

Thanks for the insight @elalish and @klausw!

[klausw]

I dug around a bit, and I think I found the issue.

The culprit seems to be this code: https://github.com/mrdoob/three.js/blob/bf904c74450aa8835370f229a757f20fa25c1c3b/src/renderers/WebGLRenderer.js#L1952

		if ( framebufferBound && capabilities.drawBuffers ) { ...
			if ( renderTarget ) { ...
			} else {
				if ( _currentDrawBuffers.length !== 1 || _currentDrawBuffers[ 0 ] !== _gl.BACK ) {
					_currentDrawBuffers[ 0 ] = _gl.BACK;

This assumes that if renderTarget is unset, it's supposed to use the back buffer via gl.BACK.

However, this isn't correct when in WebXR mode. In that case, state.bindFramebuffer(..., null) is special-cased to bind to the WebXR opaque framebuffer instead of the default framebuffer: https://github.com/mrdoob/three.js/blob/bf904c74450aa8835370f229a757f20fa25c1c3b/src/renderers/webgl/WebGLState.js#L443

		if ( framebuffer === null && xrFramebuffer !== null ) framebuffer = xrFramebuffer; // use active XR framebuffer if available

According to the debugger, the current logic overwrites the correct _currentDrawBuffers value of [36064] (gl.COLOR_ATTACHMENT0) with [1029] (gl.BACK), and that's not a valid value for a bound FBO.

Assuming that's correct, I think the right fix would be to skip the gl.BACK override when renderTarget is null but xrFramebuffer is set. However, I'm not sure what the best way is to make this check since xrFramebuffer is a private variable in WebGLState.

@elalish - since you're more familiar with three.js internals, would you want to take a stab at this?

[klausw]

See mrdoob/three.js#22079 , I added a comment there pointing to this discussion.

[elalish]

Awesome, thanks @klausw! I'm not sure I feel qualified to touch anything that deep in the renderer either. Thanks for connecting it to another three.js issue; I trust @mrdoob will find the right person for it.