WebGPURenderer: implement ClippingGroup object

[aardgoose]

Fixed #28838.

As suggested in original renderer

three.js/src/renderers/WebGLRenderer.js

Line 1777 in aedb9c7

// we might want to call this function with some ClippingGroup

Adds support for ClippingGroup objects. Clipping planes are additive with nested groups as demonstrated in example.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	692.35 171.47	692.35 171.47	+0 B +0 B
WebGPU	822.19 221.91	821.87 221.85	-324 B -60 B
WebGPU Nodes	821.48 221.76	820.99 221.64	-495 B -116 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	464.89 112.3	464.89 112.3	+0 B +0 B
WebGPU	542.77 146.84	542.27 146.74	-505 B -107 B
WebGPU Nodes	498.71 136.59	498.21 136.47	-505 B -117 B

[Mugen87]

When I read the code correctly, this PR removes Renderer.clippingPlanes.

Is it also possible to remove the support for Material.clippingPlanes? When I understand the implementation correctly, ClippingGroup can handle both local and global clipping.

[aardgoose]

@Mugen87 I have already removed material clipping planes in my copy. I'll push it here soon. It gets simplifies the Renderer somewhat.

[aardgoose]

@Mugen87 @sunag

ClippingGroup() can now replicate the functionality of the existing API without the problems encountered with postprocessing passes etc #28838, the existing example has been updated to use this. The only clipping property now on the material object is 'alphaToCoverage' which is common to other materials.

the planes used for union testing and intersection testing are accumulated separately when inherited.

@sunag To retain the current behaviour where changing 'alphaToCoverage' results in a material rebuild, I have added boolean properties to the RenderObject.getMaterialCacheKey(), I don't know if this is the correct solution here?

[sunag]

To retain the current behaviour where changing 'alphaToCoverage' results in a material rebuild, I have added boolean properties to the RenderObject.getMaterialCacheKey(), I don't know if this is the correct solution here?

I'll check this weekend, sorry for the delay.

[aardgoose]

To retain the current behaviour where changing 'alphaToCoverage' results in a material rebuild, I have added boolean properties to the RenderObject.getMaterialCacheKey(), I don't know if this is the correct solution here?

I'll check this weekend, sorry for the delay.

The question is redundant now, fixed by a upstream PR from @Mugen87

[Mugen87]

@aardgoose Do you have the resources to rebase the PR? If not, I'm going to give it a try in the upcoming days.

We really should merge the PR asap to eventually fix global clipping planes. The implementation can still be refactored after the merge if required.

[aardgoose]

Yes, I'll take a look, then I can revisit hardware clipping which is apparently coming in WebGPU in the next chrome version.

[Mugen87]

Great! Can't wait to have access to ClippingGroup. It makes things so much nicer.

[Mugen87]

LensflareMesh directly calls renderObject() and can't access clippingContext meaning it can't pass it to renderObject(). I've fixed the resulting runtime error by defining a default parameter.

If we add clippingContext to onBeforeRender(), we could ensure lensflares support clipping as well. Alternatively, we could also use the "current clipping context" for nested renderings if it isn't overwritten with a parameter when calling renderObject().