Batching multimeshes

[oeleo1]

I have been pondering lately on the idea of multimesh batching and would like to see what others might think of it.

Background

The rendering team, @lawnjelly in particular, has done the bulk of the work for batching the most common primitives and there is a sound batching framework in place in Godot's core. But multimeshes are not adressed, they are handled individually and obviously they break batching. Yet, every CPUParticles/2D node becomes a multimesh during rendering, as well as MultiMeshInstance/2D nodes. A common use case for example is attaching a few growing sparkles here and there, then adding lots of nodes with such sparkles. This produces long sequences of MM batches during frame analysis. A typical output looks like this:

	...
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 7)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	joined_item 1 refs,  ( prevent_vertex_baking, prevent_item_joining,  )
		(z 8)
			batch D 0-1 MM 
	...

The nodes have been placed on the same z-index on purpose to allow for better batching of individual node subtrees involving Sprite nodes and similar, including CPUParticles/2D.

The idea

The idea is to reduce the number of draw calls for multimesh instances of the same type. This comes down to batching multimeshes, or to be more precise to fold multimeshes. This means merging legacy multimesh instances in a batched multimesh instance which will be handled by the renderer in only 1 call. In practice this boils down to merging their data buffers in the batcher. The buffer copying may be reduced or not depending on the number of currently visible instances.

I am sure the idea has been played with by others as well, especially for 3D. For example, see this link for an interesting app level experiment.

While batching different types of multimeshes is probably doable, it would be much more complicated as a generic mechanism since the involved meshes and materials may be different. Hence, the idea here is to limit multimesh batching only to meshes of the same type: same mesh, same material, same multimesh format (color, transform, custom data). This is much more reasonable, it can be handled by the batcher, and it solves the common scenario quoted above of having the same CPUParticles/2D spread all over the place.

I expect that the savings in terms of draw calls will vary depending on the project since folding multimeshes comes at the expense of allocating more memory to merge their buffers. Which is why it would be a good idea, should this be played with, to add it as a batching option with a cap on the size of multimesh instances (for example, batch only multimeshes smaller than some number, say 256, instances).

At this point I don't have a good sense of the usefullness of the idea so sharing it will hopefully collect more opinions on its relevance. As to what the impact will be, I guess noone knows unless it is prototyped and tested. Which I may try to do anyway in a great moment of inspiration in order to cut off these long MM draw call sequences.

Thanks.