The purpose of Dynamic Batching is to bundle together large groups of simple meshes and push them through the rendering system as if it was a single mesh. Only meshes that are currently visible in the Camera view are candidates for Dynamic Batching, which means that most of the batching work is accomplished at runtime, rather than pre-calculated. This means that the objects that are batched together will vary from frame to frame. Hence, the name "Dynamic" Batching.
If we return to the Player Settings page and enable Dynamic Batching, we should see that the number of batches drops from nine down to six. Dynamic Batching is automatically recognizing that our objects share Material and mesh information and can combine them into a single batch for processing. This is a decent CPU cost-savings technique and reduces the likelihood that our game with be CPU-bound, since it frees up more time for other tasks, such as AI and Physics processing.
At the risk of sounding ungrateful, we should ask ourselves why we only save three Draw Calls, and not six. We would hope that the system is smart enough to group all of the cubes together in one batch and all of the spheres in another, taking only two Draw Calls to render them all (plus one Draw Call for the background).
The complete list of the requirements needed to successfully dynamically batch a mesh can be found in the Unity documentation at http://docs.unity3d.com/Manual/DrawCallBatching.html.
- All mesh instances must use the same Material reference
- Only particle systems and mesh renderers are dynamically batched. Skinned mesh renderers (for animated characters) and all other renderable component types cannot be batched
- The total number of vertex attributes used by the Shader must be no greater than 900
- Either all mesh instances should use a uniform scale or all meshes should use a nonuniform scale, but not a mixture of the two
- Mesh instances should refer to the same Lightmap file
- The Material's Shader should not depend on multiple passes
- Mesh instances must not receive real-time Shadows
There are also a couple of undocumented requirements that have been revealed during some Unite Conference panels:
- There is a limit of 300 meshes per batch
- There must be no more than 32,000 mesh indices in the entire batch
However, a couple of these requirements are not completely intuitive or clear from the description, which merits some additional explanation.
A vertex attribute is a property contained within a mesh file on a per vertex basis. This includes, but is not limited to, a vertex's position, a normal vector (most often used in lighting calculations), and UV coordinates (used to define how a texture wraps around the mesh). Only meshes with less than 900 total vertex attributes used by the Shader can be included in Dynamic Batching.
Using more attribute data per vertex within the accompanying Shader will consume more from our 900-attribute budget and hence reduce the number of vertices the mesh is allowed to have before it can no longer be used in Dynamic Batching. For example, a simple Shader which only uses three attributes per vertex, such as some of the legacy diffuse Shaders, can support Dynamic Batching using meshes with up to 300 vertices. But a more complex Shader, requiring five attributes per vertex, can only support Dynamic Batching with meshes up to 180 vertices.
This restriction is why our Scene only saves three Draw Calls with Dynamic Batching enabled, despite having all objects share the same Material reference. The cube that is autogenerated by Unity contains 8 vertices each with position, normal, and UV data, for 24 attributes in total. This is far less than the 900-vertex attribute limit when all of this data is used by the Shader. However, an autogenerated sphere contains 515 vertices, which clearly cannot be dynamically batched if we count a position, normal, and UV coordinate for each vertex. This explains our six Draw Calls: one for the background, one for a batched group of cubes, and four for the spheres that are not being dynamically batched, which must be rendered with separate Draw Calls.
The documentation suggests that, generally, objects should either share a uniform scale or each have a unique nonuniform scale in order to be included in dynamic batching. But, in reality, the behavior of this restriction changes slightly depending on which version of Unity we are running due to some changes to the Dynamic Batching system in Unity 5.
In both versions of Unity, if all instances of a mesh have a uniform scale, then they can be grouped together in the same dynamic batch. In Unity 5, it will dynamically batch all nonuniformly scaled instances of the mesh with the original batch, no matter their scale. However, in Unity 4, nonuniformly scaled objects, using the same mesh and Material, will be grouped together into separate batches.
This assumes we're working with positive scales. The scale restriction gets a little unintuitive when we're dealing with negative scales. In Unity 4, negative scales do not affect Dynamic Batching and all of the same rules apply as before. But, in Unity 5, if the mesh has one or three negative values in its scale vector, then it will not be included in the batch. If it contains two negative values, then it can be batched along with all of the other instances. It does not even matter which of the three values are negative, only that there are zero or two of them.
Presumably, this is a bi-product of the algorithm used to detect valid batchable groups, since mirroring a mesh in two dimensions is mathematically equivalent to rotating the mesh about both of the same axes 180 degrees. Thus, the behavior we observe is just the Dynamic Batching system automatically transforming the object for us.
So, it is worth keeping in mind that Dynamic Batching is a little more efficient in Unity 5, but it has some trade-offs. If we wish to use negative scales as a shortcut to mirror a mesh, then it will be incapable of being Dynamically Batched.
There were clearly some significant improvements made to the Dynamic Batching system in Unity 5, allowing it to be more versatile to a variety of situations. However, no matter which version of Unity we are using, Dynamic Batching is very useful when we wish to render very large groups of simple meshes.
The design of the system makes it ideal to use when all of the meshes we're Dynamically Batching are simple and nearly identical in appearance. Possible situations to apply Dynamic Batching could be as follows:
- A large forest filled with rocks, trees, and bushes
- A building, factory, or space station with many common elements (computers, pipes, and so on) throughout the Scene
- A game featuring many dynamic, nonanimated objects with simple geometry and particle effects (a game such as Geometry Wars springs to mind)
The potential benefits of Dynamic Batching are significant enough to set aside some time to investigate if and where we can make use of it in our Scene. There are not too many occasions where Dynamic Batching would actually degrade performance.
The most common mistake with Dynamic Batching is to set up a Scene that generates lots of batches, which each contain only a handful of meshes. In these cases, the overhead cost of detecting and generating the batches might cost more than the time it saves just making a separate Draw Call for each mesh.
In addition, we're far more likely to inflict performance losses on our application by simply assuming Dynamic Batching is taking place, when we've actually forgotten one of the essential requirements. Every situation is unique, so it is worth experimenting with our Materials, meshes, and Shaders to determine what can and cannot be dynamically batched.