ClippingGroup stops working when adding these specific meshes

[DomenicoBruzzese]

Description

I think I'm looking at a bug with ClippingGroup, I'm running a very simple example with 3 objects:
a simple green sphere, created with threejs
a .glb model with two red meshes

If I add the sphere to a clipping group, it will always work
If I add only one of the two children of the glb model attached in the jsfiddle to the clipping group (along with the sphere) then it will work.
If I add both children of the glb model (along with the sphere) the interaction breaks for the two models, but never for the sphere. I'll attach a jsfiddle to demonstrate the issue, which is replicable on both chrome/windows/amd and chrome/mac/m4

In the screenshots, the green sphere is always correctly clipped to the plane, whereas it seems that the red meshes are being clipped against a different plane, this "ghost plane" is also inconsistent and changes with the camera view direction

loom / video

Reproduction steps

1. Open the fiddle
2. Move the camera
3. Notice how the clipping behaviour is always consistent for the green sphere, but never for the red meshes

Code

import * as THREE from 'three';
import { OrbitControls } from 'three/addons/controls/OrbitControls.js';
import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
import { ClippingGroup } from 'three/webgpu';

let camera, scene, renderer, controls, clock;

let clippingPlane = new THREE.Plane(new THREE.Vector3(1, 0, 0), 0);
let globalClippingGroup = new ClippingGroup();
let planeHelper;

async function init() {
    // Renderer
    renderer = new THREE.WebGPURenderer({ antialias: true });
    renderer.setPixelRatio(window.devicePixelRatio);
    renderer.setSize(window.innerWidth, window.innerHeight);
    document.body.appendChild(renderer.domElement);

    // Scene and Camera
    scene = new THREE.Scene();
    camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 1000);
    camera.position.set(-50, 50, 50);
    
    clock = new THREE.Clock();

    // Orbit Controls
    controls = new OrbitControls(camera, renderer.domElement);
    controls.enableDamping = true;
    
    window.addEventListener('resize', onWindowResize);

    // Visualize clipping plane
    planeHelper = new THREE.PlaneHelper(clippingPlane, 50, 0x00ff00);
    scene.add(planeHelper);

    // Load GLB model from public folder
    const gltfLoader = new GLTFLoader();
    gltfLoader.load(
    	'https://domenicobrz.github.io/temp/clipping-group-issue/cross-section-copies.glb',
    	(gltf) => {
            
    		const model = gltf.scene || (gltf.scenes && gltf.scenes[0]);
    		if (model) {
    			model.position.set(0, 0, 0);

                let mesh0 = model.children[0];
                let mesh1 = model.children[1];

                globalClippingGroup.add(mesh0);
                globalClippingGroup.add(mesh1);

                globalClippingGroup.clippingPlanes = [clippingPlane];
                globalClippingGroup.clipIntersection = true;

                console.log(globalClippingGroup);

                let sphereMesh = new THREE.Mesh(new THREE.SphereGeometry(5, 32, 32), new THREE.MeshBasicMaterial({ color: 0x00ff00 }));
                sphereMesh.position.set(0, 10, 0);
                globalClippingGroup.add(sphereMesh);

    			scene.add(globalClippingGroup);
    		}
    	},
    	undefined,
    	(error) => {
    		console.error('Error loading GLB:', error);
    	}
    );

    animate();
}

function onWindowResize() {
    camera.aspect = window.innerWidth / window.innerHeight;
    camera.updateProjectionMatrix();
    renderer.setSize(window.innerWidth, window.innerHeight);
}

async function animate() {
    requestAnimationFrame(animate);
    if (controls) controls.update();
    renderer.render(scene, camera);
}

init();

Live example

jsfiddle:
https://jsfiddle.net/spd5mfvz/3/

Screenshots

Version

latest

Device

Desktop

Browser

Chrome

OS

MacOS

[DomenicoBruzzese]

Small addition: on my phone, a 2019 Mi9 t pro w/ a snapdragon gpu, the example in the jsfiddle runs well with no issues. However I can't inspect wether the renderer picked up the WebGLRenderer instead of WebGPU

[Mugen87]

I bet it was WebGL. We can force a WebGL backend usage with a renderer parameter.

Can you test whether the updated fiddle runs as expected? https://jsfiddle.net/0dhm8v4b/

This fiddle always uses WebGL 2, no matter if WebGPU is supported or not.

[DomenicoBruzzese]

With forceWebGL: true it works both on my mac and windows machine, as well as my phone

It likely picked webGL and I imagine the assumption now is that it has something to do with the webgpu implementation.

Another note, when editing ClippingNode.js:

setupDefault( intersectionPlanes, unionPlanes ) {
 
      ...     
 
                         if ( numIntersectionPlanes > 0 ) {

				const clippingPlanes = uniformArray( intersectionPlanes );
				const clipped = bool( true ).toVar( 'clipped' );

				Loop( numIntersectionPlanes, ( { i } ) => {

					const plane = clippingPlanes.element( i );
					clipped.assign( positionView.dot( plane.xyz ).greaterThan( plane.w ).and( clipped ) );

				} );

				clipped.discard();

			}

and using hard-coded plane values like: vec4(1, 0, 0, 0)
the demo runs as expected

I tried to console log:
const clippingPlanes = uniformArray( intersectionPlanes );

to check if different planes where assigned to different meshes, but it always returned the same values. I couldn't quite get how uniform nodes are updated to console.log how the node was changing while moving the camera

[Mugen87]

This might be a caching bug in the WebGPU backend. It only seems to happen if your meshes share the same material. It seems fixed by forcing two different materials. Can you confirm?

Test URL: https://jsfiddle.net/cwd8myp5/1/

[DomenicoBruzzese]

Your example works, however using material.clone() instead of assigning a completely new material doesn't

[Mugen87]

It doesn't because a cloned material still produces the cache hit that currently corrupts the rendering. We have to understand now why the cache hit occurs.

[DomenicoBruzzese]

It doesn't because a cloned material still produces the cache hit that currently corrupts the rendering. We have to understand now why the cache hit occurs.

just saw you already found the issue, thank you so much for the help!