Для отрисовки объекта на экране движок отправляет команду (draw call) графическому API (например, OpenGL или Direct3D). Графический API производит значительную работу для каждого DC, что сильно влияет на производительность CPU.
Unity uses two techniques to address this:
Built-in batching has several benefits compared to manually merging GameObjects together; most notably, GameObjects can still be culled individually. However, ut also has some downsides; static batching incurs memory and storage overhead, and dynamic batching incurs some CPU overhead.
Батчатся только объекты, имеющие один и тот же материал. Соответственно, для эффективного батчинга вам необходимо делать материалы общими для множества объектов, если это возможно.
Если у вас есть два одинаковых материала, отличающихся только текстурами, можно объединить эти текстуры в одну большую — процесс часто называемый созданием текстурного атласа. Так вы сможете использовать один материал вместо двух.
Если нужно получить доступ к свойствам общего материала из скрипта, то важно помнить, что изменение Renderer.material приведёт к созданию копии материала. Вместо этого следует использовать свойство Renderer.sharedMaterial, чтобы материал остался общим.
Shadow casters can often be batched together while rendering, even if their Materials are different. Shadow casters in Unity can use dynamic batching even with different Materials, as long as the values in the Materials needed by the shadow pass are the same. For example, many crates could use Materials with different Textures on them, but for the shadow caster rendering the textures are not relevant, so in this case they can be batched together.
Unity может автоматически батчить движущиеся объекты в один DC, если они используют общий материал и отвечают ряду других критериев. Динамический батчинг применяется автоматически и не требует дополнительных действий с вашей стороны.
Because it works by transforming all GameObject vertices into world space on the CPU, it is only an advantage if that work is smaller than doing a draw call. The resource requirements of a draw call depends on many factors, primarily the graphics API used. For example, on consoles or modern APIs like Apple Metal, the draw call overhead is generally much lower, and often dynamic batching cannot be an advantage at all.
Static batching allows the engine to reduce draw calls for geometry of any size provided it shares the same material, and does not move. It is often more efficient than dynamic batching (it does not transform vertices on the CPU), but it uses more memory.
При использовании статичного батчинга вы должны убедиться, что объекты статичны и не двигаются, не вращаются и не масштабируются во время выполнения. Если эти условия соблюдаются, можно пометить объекты как статичные, поставив галочку Static в Inspector:
Использование статичного батчинга требует дополнительной памяти для хранения объединённой геометрии. Если несколько объектов используют общую геометрию перед статичным батчингом, то копия геометрии создаётся для каждого объекта, либо в рантайме, либо в редакторе. Это может быть не очень удачной идеей — иногда вы можете пожертвовать производительностью визуализации некоторых объектов для снижения затрат памяти. Для примера, пометив все деревья как статичные на лесистом уровне вы можете получить серьёзный удар по объёму доступной памяти.
Internally, static batching works by transforming the static GameObjects into world space and building a big vertex and index buffer for them. Then, for visible GameObjects in the same batch, a series of simple draw calls are done, with almost no state changes in between. Technically it does not save 3D API draw calls, but it saves on state changes between them (which is the resource-intensive part). Batches are limited to 64k vertices and 64k indices on most platforms (48k indices on OpenGLES, 32k indices on macOS).
Советы:
Currently, only Mesh Renderers, Trail Renderers, Line Renderers, Particle Systems and Sprite Renderers are batched. This means that skinned Meshes, Cloth, and other types of rendering components are not batched.
Полупрозрачные шейдеры часто требуют объектов, которые визуализируются в порядке “от заднего к переднему”, чтобы прозрачность работала корректно. Unity сначала визуализирует объекты в этом порядке и лишь затем пробует сбатчить их — так как соблюдение этого порядка очень важно, то эффективность батчинга для полупрозрачных объектов страдает по сравнению с непрозрачнымию
Manually combining GameObjects that are close to each other can be a very good alternative to draw call batching. For example, a static cupboard with lots of drawers often makes sense to just combine into a single Mesh, either in a 3D modeling application or using Mesh.CombineMeshes.