BatchedMesh support for multiDraw*Instanced rendering

[andredsm]

Description

Hi guys,

Regarding BatchedMesh, it was using the multiDraw[Arrays|Elements]Instanced in its earlier versions, but for some reason, this feature was deprecated. The current implementation emulates instancing by repeating the multidraw[Array|Elements] API parameters. Nonetheless, this approach is slower when compared to its instantiated flavor.

To demonstrate this, I've scratched a simple example comparing the performance of multidrawElements, multidrawElementsInstanced, and the regular drawElementsInstanced API. I am using the raw webgl api in all rendering methods to avoid introducing some overhead from the ThreeJS implementation, such as indirection in BatchedMesh rendering. When we switch the rendering API, I only change the rendering API.

My setup:

• Processor: AMD Ryzen 9 7940HS , 4001 Mhz, 8 Core(s), 16 Logical Processor(s)
• RAM: 32 GB
• iGPU: Radeon 780M Graphics. Driver 7.06.02.123
• dGPU: NVIDIA GeForce RTX 4080. Driver 576.88, Jul 2025.

Example: https://codepen.io/andredsm/full/zxrOjrx

In my environment, when comparing multidrawElements vs multidrawElementsInstantiated, the second approach's speedup is ~1.5x in iGPU, while in dGPU is around 2x. The performance is the same when comparing the multidrawElementsInstantiated vs drawElementsInstantiated because my scene has only a single geometry. When the scene has several different geometries instantiated, the multidrawElementsInstantiated produces better results.

I know Firefox lacks support for multidraw*Instantiated API. Still, it would be beneficial if ThreeJS provided this rendering mechanism and a fallback for Firefox users, as the current BatchedMesh already does for regular multidraw calls.

Solution

When using multidraw + instancing, the BatchedMesh should use the multidraw*Instantiated rendering API. In case this API is not available, the rendering could be done using the current approach.

Alternatives

I considered using InstancedMesh for rendering several instanced geometries, but in cases where we have several different geometries, the engine issues 1 draw call/geometry.

Additional context

No response

[RenaudRohlinger]

Well, support for renderMultiDrawInstances is planned to be removed. It was used before, but I believe it was deprecated due to some Firefox fallback issue, and it will be deleted from the codebase in about four months:

WebGLRenderer: renderMultiDrawInstances has been deprecated and will be removed in r184. Append to renderMultiDraw arguments and use indirection.

three.js/src/renderers/WebGLRenderer.js

Lines 1219 to 1220 in 05742fe

	warnOnce( 'WebGLRenderer: renderMultiDrawInstances has been deprecated and will be removed in r184. Append to renderMultiDraw arguments and use indirection.' );
	renderer.renderMultiDrawInstances( object._multiDrawStarts, object._multiDrawCounts, object._multiDrawCount, object._multiDrawInstances );

I also used it for an advanced use case, and I share the opinion that removing access to a native WebGL feature from the renderer is somewhat unfortunate. However, trying to build a BatchedMesh version that supports proper instancing would mean losing perMeshFrustum and a few of the valuable features in the current BatchedMesh implementation.

I don’t think we should invest too much time in such an advanced WebGL use case. Instead, we should wait for a hero to implement a WebGPU BatchedMesh using renderbundle, compute shading and indirect draw calls, which will be much more performant overall.

[bandinopla]

I get your point about the current BatchedMesh implementation not using multiDrawElementsInstanced and therefore not always being faster than keeping multiple InstancedMesh. But that’s exactly why I think my example PR is still useful.

What I’m showing is not that this specific implementation magically outperforms every case, but that combining many InstancedMesh into a single BatchedMesh is a valid and logically consistent optimization strategy in scenarios where draw call overhead is the bottleneck. The fact that Three.js right now doesn’t fully exploit the available GPU APIs isn’t a reason to dismiss the example, it’s a reason to evolve the implementation so it can!

In other words, the concept stands, even if the current internals don’t yet let it shine. My PR was meant to demonstrate how to combine them, and provide a concrete starting point. Future improvements like proper support for multiDrawElementsInstanced could make this approach significantly better in practice.

So I’d argue the example is still worth including since it shows users what’s possible and opens the door for improving the backend without needing to re-explain the idea every time.

[andredsm]

@RenaudRohlinger Regarding Firefox support, I think we could provide a fallback, maybe rendering instances as the current implementation does. About the per-instance operations, I think it would not be that hard to enable by using the same techniques, such as indirection. Based on the code snippet you mentioned, I think the previous implementation already did that.

[andredsm]

@bandinopla I agree with you. I think your example/PR is still worth it. I just wanted to warn about this edge case because it was something I have experienced when combining multiple InstancedMesh into BatchedMesh ☺️

[bandinopla]

@bandinopla I agree with you. I think your example/PR is still worth it. I just wanted to warn about this edge case because it was something I have experienced when combining multiple InstancedMesh into BatchedMesh ☺️

You digged deeper and saw the implementation. Logically It makes sense that combining instanced meshes into a BatchedMesh should result in better performance, but down to the implementation, you did spotted an interesting issue.

Combining the InstanceMeshes into a single BatchMesh does produce a single draw call vs one per geometry otherwise if using multiple instance meshes. So in terms of draw calls, it does reduce them to just 1.

Now, if that is faster or not, in frame render times, that's a deeper issue down to the implementation details you mentioned.

[gkjohnson]

The performance of the multiDrawArrays function is discussed in #31239 (comment).

The reality is that there's no apparent reason why multiDrawArrays should be slow and in particular so much slower than the instanced variant. This performance difference isn't present in the WebGPU version of the functionality, either, which suggests there is some bug in the underlying graphics wrapper for WebGL used by browsers.

From the above-linked issue, there has been a Chromium issue submitted here to fix this bottleneck (which you should +1 if you'd like the see it addressed). I otherwise don't think there's much effort that should be put into this until the issue with the multidraw behavior is more understood, and it's currently marked as being in the version 141 milestone which I assume means we should at least have some more information in the coming months.