WebGLbackend: autoClear bug

[zonkypop]

Description

When using the WebGL fallback renderer, autoClear seems to be causing issues:

This can be reproduced by adding:

function animate() {
				renderer.autoClear = true;
				renderer.render(scene, camera);

				const geometry = new THREE.SphereGeometry(5, 64, 32);

				const material = new THREE.MeshBasicMaterial({
					color: 0xffffff,
				});

				mesh = new THREE.Mesh(geometry, material);

				renderer.autoClear = false;
				renderer.render(mesh, camera);
			}

in the https://threejs.org/examples/?q=light%20probe#webgpu_lightprobe example and using forceWebGL: true for the renderer.

Setting antialias: false will make it not look mangled but there are still issues with it not clearing (update: I think those issues were unrelated).

I'm not getting the same issue when using WebGPU or the WebGL example.

Version

174dev

Device

Desktop

Browser

Chrome

OS

Linux

[Mugen87]

Can you please demonstrate the issue with a fiddle? You can use the following one that holds the code of webgpu_lightprobe but with your modification. The only bit I have changed is to create the mesh for the second render just once.

https://jsfiddle.net/j8qk0us5/1/

Both backends render the same for me, tested on latest Chrome on macOS 15.3.1.

[zonkypop]

Oh that is strange, I can't reproduce it on Linux with AMD integrated graphics, or macOS.

Here's the fiddle: https://jsfiddle.net/zonkypop/jyuchq4p/2/

But it does look mangled with an RTX 3090 on Linux on Chrome (tested 131, 133). It needs: antialias: true for it to happen, and looks fine without antialiasing.

It looks fine on Firefox with the same machine.

I'll have a poke around today and see if I can find any clues.

[zonkypop]

I'm able to reproduce it in on Windows 11 with a RTX 3070 as well, but only Chrome, not Firefox. So might be Chrome+Nvidia related.

[Mugen87]

So the combination is WebGLBackend + MSAA + Nvidia card + Chrome, right? The OS does not seem to matter.

[zonkypop]

So the combination is WebGLBackend + MSAA + Nvidia card + Chrome, right? The OS does not seem to matter.

Yes seems to be, the bug's there for Linux and Windows

[zonkypop]

A workaround is adding useFrameBufferTarget to:

render( scene, camera, useFrameBufferTarget ) {

		if ( this._initialized === false ) {

			console.warn( 'THREE.Renderer: .render() called before the backend is initialized. Try using .renderAsync() instead.' );

			return this.renderAsync( scene, camera, useFrameBufferTarget );

		}

		this._renderScene( scene, camera, useFrameBufferTarget );

	}

and calling: renderer.render( scene, camera, false )

To disable the final quad pass, which fixes the issue. This introduces other problems like needing color conversion in the shader and no post processing though.

[Mugen87]

Can you please share a GPU report from one of the affected systems by typing chrome://gpu/ into the address bar and then hit Download Report to File?

[Mugen87]

Can you also test if this example works on the affected devices?

https://threejs.org/examples/webgl_multisampled_renderbuffers

[zonkypop]

Here's the report for the Linux machine:

about-gpu-2025-02-23T22-36-39-962Z.txt

https://threejs.org/examples/webgl_multisampled_renderbuffers seems to look fine

[Mugen87]

Can you try one thing and remove the following invalidate* calls from below section?

three.js/src/renderers/webgl-fallback/WebGLBackend.js

Lines 556 to 574 in 5323b5e

	for ( let i = 0; i < textures.length; i ++ ) {
	// TODO Add support for MRT
	if ( renderContext.scissor ) {
	const { x, y, width, height } = renderContext.scissorValue;
	const viewY = renderContext.height - height - y;
	gl.blitFramebuffer( x, viewY, x + width, viewY + height, x, viewY, x + width, viewY + height, mask, gl.NEAREST );
	gl.invalidateSubFramebuffer( gl.READ_FRAMEBUFFER, renderTargetContextData.invalidationArray, x, viewY, width, height );
	} else {
	gl.blitFramebuffer( 0, 0, renderContext.width, renderContext.height, 0, 0, renderContext.width, renderContext.height, mask, gl.NEAREST );
	gl.invalidateFramebuffer( gl.READ_FRAMEBUFFER, renderTargetContextData.invalidationArray );
	}

[zonkypop]

Can you try one thing and remove the following invalidate* calls from below section?

🥳 Wahay, that seems to have fixed it for both Linux and Windows!