BatchedMesh: Fix renderer.info.render when using multidraw.

[agargaro]

Related issue: #29531

Description

info.update() increases the draw calls by 1 for each call, and here it is called more than once.
In addition, the number of triangles is not calculated correctly.

Edit: moved to draft to do more checking

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	688.13 170.5	688.08 170.59	-50 B +89 B
WebGPU	806.87 217.32	806.84 217.32	-25 B -2 B
WebGPU Nodes	806.37 217.19	806.35 217.18	-25 B -1 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	462.85 111.79	462.8 111.78	-50 B -6 B
WebGPU	535.67 144.58	535.64 144.58	-25 B -1 B
WebGPU Nodes	491.75 134.31	491.73 134.31	-25 B -1 B

[agargaro]

@CodyJasonBennett @Mugen87
Is the fix okay?

[Mugen87]

It looks good to me. This should also be checked by @gkjohnson 🙌 .

[gkjohnson]

The WebGLBufferRenderer implementation should be updated to match WebGLIndexedBufferRenderer (the current PR modifies the WebGPURenderer WebGL fallback version only):

three.js/src/renderers/webgl/WebGLBufferRenderer.js

Lines 72 to 76 in 1841e38

	for ( let i = 0; i < primcount.length; i ++ ) {
	info.update( elementCount, mode, primcount[ i ] );
	}

And I'm less familiar with the WebGPURenderer but it looks like the primitives aren't correctly counted in that case, either:

three.js/src/renderers/webgpu/WebGPUBackend.js

Lines 952 to 959 in 1841e38

	for ( let i = 0; i < drawCount; i ++ ) {
	const count = drawInstances ? drawInstances[ i ] : 1;
	const firstInstance = count > 1 ? 0 : i;
	passEncoderGPU.drawIndexed( counts[ i ], count, starts[ i ] / bytesPerElement, 0, firstInstance );
	}

[gkjohnson]

And I'm less familiar with the WebGPURenderer but it looks like the primitives aren't correctly counted in that case, either:

Looking at this a bit more it looks like WebGPURenderer has a fairly limited implementation of BatchedMesh (it's issuing new draw calls for each sub geometry and doesn't support non-indexed geometry) so this may just be an artifact of the still in-progress WebGPU implementation. It looks like InstancedMesh is also not supported, yet. Though I may be misunderstanding something.

[agargaro]

The WebGLBufferRenderer implementation should be updated to match WebGLIndexedBufferRenderer (the current PR modifies the WebGPURenderer WebGL fallback version only):

three.js/src/renderers/webgl/WebGLBufferRenderer.js

Lines 72 to 76 in 1841e38

	for ( let i = 0; i < primcount.length; i ++ ) {
	info.update( elementCount, mode, primcount[ i ] );
	}

fixed, thanks

And I'm less familiar with the WebGPURenderer but it looks like the primitives aren't correctly counted in that case, either:

three.js/src/renderers/webgpu/WebGPUBackend.js

Lines 952 to 959 in 1841e38

	for ( let i = 0; i < drawCount; i ++ ) {
	const count = drawInstances ? drawInstances[ i ] : 1;
	const firstInstance = count > 1 ? 0 : i;
	passEncoderGPU.drawIndexed( counts[ i ], count, starts[ i ] / bytesPerElement, 0, firstInstance );
	}

is this relative to #29488? info.update() is not called at all

[gkjohnson]

is this relative to #29488? info.update() is not called at all

Seems likely - but again support for BatchedMesh in the WebGPU backend seems incomplete at the moment. If you can test it then it seems worth adding either way.

[RenaudRohlinger]

Support for BatchedMesh in the WebGPU backend will be finalized with the completion of the indirect draw API (WIP: #29372). We'll also need to determine how to handle the statistics for indirect draw calls in renderer.info. Once we identify an appropriate way to represent these stats, we can make decisions on how to calculate the infos of the BatchedMesh in WebGPU I guess.

Also related discussion: #29197 (comment)