koobas.hobune.stream
Single Mesh vs Batching - Performance
Hello!
Does combining scene objects (that use the same material) into a single mesh is cheaper than relying on Unity's batching system (performance wise)?
So scenario is: 1 mesh - 1 material vs multiple meshes - 1 material
At first look I'd say it is, but I'm not sure, that's why I decided to ask.
Thank you!
In general there are two different batching systems in Unity:
static batching
dynamic batching
Static batching essentially is the same as combining the objects manually. This is only viable for objects that do not move. Unity automatically performs static batching when loading a scene that contains objects which are marked as static for batching. Once batched you can no longer move the objects as they are now part of a larger mesh.
For procedural generated levels you can use the StaticBatchingUtility to manually batch objects together at runtime.
Dynamic batching is different. It only applies to objects that meet several criteria:
Only small meshes are supported. That means the mesh can't have more than 900 vertex attributes. A single attribute is for example the vertex position. Others are a vertex normal, uv coordinates, color, tangent, ... So if your mesh vertices define a position, a normal and texture coordinates the mesh can only have 300 vertices. If the mesh has more attributes per vertex the number gets even smaller.
The objects shouldn't use different scaling or they might not be batched.
Objects are not being batched if you use lightmapping and the objects are located on different lightmaps.
The objects can't use multi-pass shaders as they generally don't batch.
The objects need to be "close together".
Dynamic batching is done each frame and has some performance overhead on the CPU. It's ment to batch several small objects (like many flying bullets).
The most efficient batching is static batching. It has some memory overhead due to the combined mesh instance. Dynamic batching is only useful in special cases. It's nice to have but it's difficult to rely on dynamic batching without fine tuning the objects you want to batch together.
Static batching works great. It probably has a larger memory overhead over manually creating a single mesh, but it saves you from manually combining meshes. It allows easy modular level design and good performance at runtime out of the box.
Well my level is procedurally generated and also moves (for an endless runner on mobile game, player does not move on the Z axis, but the enviroment does).
I already created an editor tool that allows me to quickly Combine meshes that use the same material together. (For example I select a whole environment section and apply the tool on it, the result will be 1 $$anonymous$$esh with however many materials there are submeshes).
Also, most of the props share the same material that uses only vertex colors (unlit), so this works great, I get ~95% less draw calls.
What I was wondering is if it was redundant, in case Batching would do this automatically for me.
From your answer I take that it's safer the way I do it. Even if I scale objects or move them are runtime, they will be combined together in a mesh so I won't have to worry about whether they are being batched or not.
Is my assessment correct?
Thank you!
Well, using the StaticBachingUtility would still allow you to move the parent object, but not individual objects after they are combined. So if you have for example several "sections" you can statically batch each section individually so each section is optimised on it's own.
There's one advantage of using static batching over manually creating a single $$anonymous$$esh. Statically batched objects are still culled individually even they are rendered as a single mesh.
That is very interesting. Didn't know about the culling part of this. I wanted to optimize the overdraw, but was unsure how to if I was going to combine meshes.
I will try this and get back to you.
Thanks!
