Preface
Unity can merge some objects at runtime, thus rendering them with a draw call. This operation, we call "batch processing", can achieve better rendering performance.
The effect achieved by the built-in batch processing mechanism in Unity is significantly stronger than the batch processing effect of using geometric modeling tools, because the batch operation of the Unity engine is carried out after the visual cropping operation of the object, and the geometric information processed is much less.
Material
Only objects with the same material can be batched, so you need to reuse as many materials as possible in the program. If your two materials are just different in textures, you can use texture plastering to form the two textures into a large texture, so that you can use this single material to replace the previous two materials.
If you want to access the reused material properties through a script, it is worth noting that the change will cause a copy of the material, so you should use it to ensure the shared state of the material.
Dynamic batch processing
If dynamic objects share the same material, Unity will automatically batch these objects. Dynamic batch operations are automatically completed and do not require you to perform additional operations.
When Dynamic Batching is enabled, Unity will attempt to automatically batch move objects into a Draw Call. To make objects can be batched dynamically, they should share the same material, but there are some other constraints:
Batching dynamic objects requires a certain overhead on each vertex, so dynamic batching only supports mesh objects with less than 900 vertices; if your shader uses three attributes: vertex position, normal and UV value, then you can only batch objects with less than 300 vertices; if your shader needs to use vertex position, normal, UV0, UV1 and tangent vector, then you can only batch objects with less than 180 vertices.
Try not to use scale. Two objects with scale scales (1, 1, 1) and (2, 2, 2) respectively will not be batched; objects with uniform scale scale will not be batched with objects with non-uniform scale scales. Two objects using scale scales (1,1,1) and (1,2,1) will not be batched, but two objects using scale scales (1,2,1) and (1,3,1) will be batched.
Objects with lightmap have other renderer parameters, such as lightmap index or lightmap offset and zoom. Generally speaking, the game object for a dynamic lightmap should point to the exact same lightmap location.
Multi-channel shaders can hinder batch processing operations. For example, almost all shaders in unity support multiple light sources in forward rendering and effectively open multiple channels for them, which requires additional renderings, so the "extra per-pixel light" is not batched.
Static batch processing
To better use static batching, you need to point out clearly which objects are stationary and never move, rotate, and scale in the game. To accomplish this, you just need to check the Static check box in the detector. As long as these objects do not move and have the same material. Therefore, static batching is more efficient than dynamic batching, and you should try to use it as low as it requires less CPU overhead.
Using static batch operations requires additional memory overhead to store merged geometric data. Before static batching, if some objects share the same geometric data, the engine creates a backup of geometric data for each object in editing and running states. This is not always a good idea, as sometimes, a little rendering performance will have to be sacrificed to prevent static batching of some objects, thus maintaining less memory overhead. For example, setting the Tuxedon mid-tree to Static will cause serious memory overhead. This is the love and killing of space and time.
Finally, if the scene comes with static objects, batches will be merged, which everyone knows; if the static objects are dynamically loaded by the prefabricated body after the scene is loaded, the batches will not be automatically merged. You need to adjust the interface of manually merging the batches after loading and merge.
Supplement: Rendering Optimization in Unity3D - Batch Processing Technology
In Unity3D, the commonly used optimization technique for reducing Draw calls is batch processing technology. The principle of batch processing is to reduce the number of Draw calls required per frame. In order to render an object to the screen, the CPU needs to check which light sources affect the object, bind the shader and set its parameters, and then send the rendering command to the GPU. These operations can be very time-consuming when a large number of objects are included in the scene. For example, if we need to render a thousand triangles, it takes much more time to render them as a thousand individual meshes than to render a mesh with one thousand triangles. In these two cases, there is actually not much difference in performance consumption of GPU, but the number of CPU draw calls will become a performance bottleneck. Therefore, the idea of batch processing is very simple, which is to process as many objects as possible every time the draw call is called.
Objects using the same material can be batched because for objects using the same material, the difference between them is only in the difference in vertex data. We can merge these vertex data together and send them to the GPU together, so that a batch processing can be completed.
There are two types of batch processing supported in Unity, one is dynamic batch processing and the other is static batch processing. For dynamic batch processing, the advantage is that all processing is automatically completed by Unity, and we do not need to do any operation. Moreover, objects can be moved. The disadvantage is that there are many restrictions. This mechanism may be broken by accident, resulting in Unity being unable to dynamically batch some objects using the same material. For static batch processing, its advantage is that its degree of freedom is very high and its limitation is that it may occupy more memory, and all objects after static batch processing cannot be moved (even trying to change the position of the object in the script is invalid).
Dynamic batch processing technology in Unity3D
The principle of dynamic batch processing is to merge the model grid that can be batched in each frame, then pass the merged model data to the GPU, and then render it using the same material. Besides the convenience of implementation, another benefit of dynamic batching is that the batched objects can still be moved, because Unity re-merges the mesh once every frame.
Although Unity's dynamic batching does not require us to do any extra work, only models and materials that meet the conditions can be dynamically batched. (It should be noted that as the Unity version changes, these conditions also change a little) These conditional limitations are:
1. The vertex attribute scale of the grid that can perform dynamic batching must be less than 900. For example, if the shader needs to use the three vertex attributes: vertex position, normal and texture coordinates, then in order to make the model dynamically batched, its vertex number cannot exceed 300. It should be noted that this number may change in the future, so do not rely on this data.
2. Generally speaking, all objects need to use the same scaling scale (can be (1, 1, 1), (1, 2, 3), (1.5, 1.4, 1.3), etc., but must all be the same). An exception is that if all objects are different non-uniform scaling, they can also be batched dynamically. But in Unity5, this restriction on model scaling no longer exists.
3. Careful treatment is required for objects that use lightmap textures. These objects require additional rendering parameters, such as indexes and offsets on lightmap textures, and scaling information, etc. Therefore, in order for these objects to be batched dynamically, we need to ensure that they point to the same position in the lightmap texture.
4. Shaders with multiple Pass channels will interrupt batch processing. In forward rendering, we sometimes need to use extra pass to add more lighting to the model, but this way the model is not batched dynamically.
Static batch processing technology in Unity3D
The principle of static batch processing is to merge models that require static batch processing into a new mesh structure only at the beginning of the run, which means that these models cannot be moved at runtime. But since it only requires one merge operation, it is more efficient than dynamic batch processing. But the disadvantage of static batching is that it needs to occupy more memory to store the merged geometry. At this time, if some objects share the same mesh before static batching, then each object in memory will correspond to a copy of the mesh, that is, a mesh will become multiple meshes and then sent to the GPU. If there are many objects in this type that use the same mesh, then this will become a performance bottleneck. For example, if you use static batching in a forest that uses 1000 identical tree models, you will use 1000 times more memory, which will have a serious memory impact. The solution at this time is to either endure this method of sacrificing memory for performance, or not using static batching, but using dynamic batching techniques (but be careful to control the number of vertex attributes of the model), or write your own batching methods.
The method of using static batching in Unity is to select the object that needs static batching in the scene and check the Batching static property in the upper right corner of its Inspector panel. In internal implementations, Unity first transforms these static objects into world space, and then builds a larger vertex and index cache for them, for objects using the same material. Unity only needs to call a drawcall to draw all objects. For objects using different materials, static batching can also improve rendering performance. Although these objects still require multiple draw calls, static batching can reduce state switching between these draw calls, which are often time-consuming operations.
We can observe the changes in VBO total (Vertex Buffer Object) before and after applying static batch processing in Unity's analyzer. When some objects share the same mesh, we can see that after these objects use static batch processing technology, the number of VBO totals has increased, which is precisely because static batch processing will occupy more memory. As mentioned above, static batching requires more memory to store the merged geometry. If some objects share the same mesh, then each object in memory will correspond to a copy of that mesh.
If the scene contains other light sources except parallel lights and additional Passes are defined in the Shader to process them, these additional Pass parts will not be batched, but the Base Pass parts that process parallel lights will still be statically batched.
Use of shared materials in Unity3D
Whether it is dynamic batch processing or static batch processing, the same material is required to be shared between models. But different models will always need to have different rendering properties, such as using different textures, colors, etc. At this time, we need some strategies to merge materials as much as possible.
If only the textures used are different between the two materials, we can merge these textures into a larger texture, which is called an atlas. Once the same texture is used, we can use the same material and then use different sampling coordinates to sample the texture.
But sometimes, in addition to different textures, different objects have some slight parameter changes in the material, such as different colors and different floating point properties. However, whether it is dynamic batching or static batching, their premise is to use the same material. It is the same, rather than using the same shader material, that is, the material they point to must be the same entity. This means that as long as we adjust the parameters, it will affect the object that uses this material as we want. So what should I do if I want a slight adjustment? A common method is to use the vertex data of the mesh to store these parameters (the most common one is the vertex color data).
The batched object will be processed into a larger VBO and sent to the GPU. The data in the VBO can be passed to the vertex shader as input. Therefore, we can cleverly control the data in the VBO to achieve the purpose of different effects. An example is that all trees in a forest scene use the same material, we hope they can reduce the draw call by batch processing, but the colors of different trees may be different. At this time, we can use the color data of the grid vertices to adjust.
It should be noted that if we need to access the shared material in the script, we should use it to ensure that the modified material is shared with other objects, but this means that the modification will be applied to all objects that use the material. Another similar API is that if used to modify a material, Unity creates a copy of the material, thus destroying the application of batch processing on the object.
Notes on using batch processing in Unity3D:
1. Use static batch processing as much as possible, but be careful about memory consumption at all times and remember that objects that have been static batched cannot be moved anymore.
2. If static batching is not possible and dynamic batching is used, then minimize the number of objects and allow these objects to contain a small number of vertex attributes and vertex counts.
3. Dynamic batch processing can be used for small props in the game, such as gold coins that can be picked up.
4. For objects like this type of animation, we cannot use static batch processing, but if there is a fixed part, this part can be marked as "Static".
5. Since batch processing requires transforming the models into world space and merging them, if there are some operations based on coordinates in the shader in model space, you will often get wrong results. One solution is to use the DisableBatching tag in the shader to force the shader's material to not be batched.
6. Objects made of translucent materials usually require strict drawing order from behind to front to ensure the correctness of transparent mixing. This means that when the drawing order cannot be satisfied, batch processing cannot be successfully applied on these objects.
The above is personal experience. I hope you can give you a reference and I hope you can support me more. If there are any mistakes or no complete considerations, I would like to give you advice.