Батчинг вызовов отрисовки (Draw Call Batching)
Для отрисовки объекта на экране движок отправляет команду (draw call) графическому API (например, OpenGL или Direct3D). Графический API производит значительную работу для каждого DC, что сильно влияет на производительность CPU.
Unity uses several techniques to address this:
- Static Batching: combine static (i.e. not moving) objects into big meshes, and render them in a faster way.
- Dynamic Batching: for small enough meshes, transform their vertices on the CPU, group many similar ones together, and draw in one go.
Built-in batching has several benefits compared to manually merging objects together (most notably, the objects can still be culled individually). But it also has some downsides too (static batching incurs memory and storage overhead; and dynamic batching incurs some CPU overhead).
Material Setup For Batching
Батчатся только объекты, имеющие один и тот же материал. Соответственно, для эффективного батчинга вам необходимо делать материалы общими для множества объектов, если это возможно.
Если у вас есть два одинаковых материала, отличающихся только текстурами, можно объединить эти текстуры в одну большую — процесс часто называемый созданием текстурного атласа. Так вы сможете использовать один материал вместо двух.
Если нужно получить доступ к свойствам общего материала из скрипта, то важно помнить, что изменение Renderer.material приведёт к созданию копии материала. Вместо этого следует использовать свойство Renderer.sharedMaterial, чтобы материал остался общим.
While rendering shadow casters, they can often be batched together even if their materials are different. Shadow casters in Unity can use dynamic batching even with different materials, as long as the values in materials needed by the shadow pass are the same. For example, many crates could use materials with different textures on them, but for shadow caster rendering the textures are not relevant – in that case they can be batched together.
Динамический батчинг (Dynamic Batching)
Unity может автоматически батчить движущиеся объекты в один DC, если они используют общий материал и отвечают ряду других критериев. Динамический батчинг применяется автоматически и не требует дополнительных действий с вашей стороны.
- Динамический батчинг связан с дополнительной нагрузкой для каждой вершины, так что он применим только к мешам, содержащим менее 900 вершин в сумме.
- Если ваш шейдер использует Vertex Position, Normal и единственный UV, то вы можете батчить до 300 вершин; тогда как, если шейдер использует Vertex Position, Normal, UV0, UV1 и Tangent, то только 180 вершин.
- Обратите внимание: ограничение на количество атрибутов в будущем может быть изменено
- Objects will not be batched if they contain mirroring on the transform, for example object A with +1 scale and object B with –1 scale can not be batched together.
- Использование разных экземпляров материалов — даже если они по сути своей являются одним материалом — сделает динамический батчинг невозможным.
- Объекты с картами освещения имеют дополнительное свойство: индекс карты освещения и смещение/масштаб внутри карты освещения. Для батчинга объекты должны ссылаться на одно и то же место в карте освещения.
- Multi-pass shaders will break batching.
- Многопроходные шейдеры могут нарушить батчинг. Почти все шейдеры Unity поддерживают несколько источников света при forward rendering, и эффективно делать дополнительный проход для них. DC для “дополнительных пиксельных источников света” не будут батчиться.
- Legacy Deferred (light pre-pass) rendering path has dynamic batching disabled, because it has to draw objects twice.
Since it works by transforming all object vertices into world space on the CPU, it is only a win if that work is smaller than doing a “draw call”. How exactly expensive is a draw call depends on many factors, primarily on 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 can not be a win at all.
Статический батчинг (Static Batching)
Статичный батчинг позволяет движку снизить количество DC для геометрии любого размера, если она не двигается и использует общий материал. Статичный батчинг более эффективен, чем динамический. Вы должны стараться использовать статичный батчинг, чтобы снизить нагрузку на CPU.
При использовании статичного батчинга вы должны убедиться, что объекты статичны и не двигаются, не вращаются и не масштабируются во время выполнения. Если эти условия соблюдаются, можно пометить объекты как статичные, поставив галочку Static в Inspector:
Использование статичного батчинга требует дополнительной памяти для хранения объединённой геометрии. Если несколько объектов используют общую геометрию перед статичным батчингом, то копия геометрии создаётся для каждого объекта, либо в рантайме, либо в редакторе. Это может быть не очень удачной идеей — иногда вы можете пожертвовать производительностью визуализации некоторых объектов для снижения затрат памяти. Для примера, пометив все деревья как статичные на лесистом уровне вы можете получить серьёзный удар по объёму доступной памяти.
Internally, static batching works by transforming the static objects into world space and building a big vertex + index buffer for them. Then for visible objects in the same batch, a series of “cheap” draw calls are done, with almost no state changes in between. So technically it does not save “3D API draw calls”, but it saves on state changes done between them (which is the expensive part).
Другие советы по батчингу
На данный момент, только Mesh Renderers и Particle Systems могут батчиться. Это значит, что skinned meshes, ткань, trail renderers и прочие типы рендеринг-компонентов не батчатся.
Полупрозрачные шейдеры часто требуют объектов, которые визуализируются в порядке “от заднего к переднему”, чтобы прозрачность работала корректно. Unity сначала визуализирует объекты в этом порядке и лишь затем пробует сбатчить их — так как соблюдение этого порядка очень важно, то эффективность батчинга для полупрозрачных объектов страдает по сравнению с непрозрачнымию
Что такое батчинг
Для отрисовки объекта на экране движок отправляет команду (draw call) графическому API (например, OpenGL или Direct3D). Графический API производит значительную работу для каждого DC, что сильно влияет на производительность CPU.
Unity может объединять объекты во время исполнения, чтобы рисовать их вместе в рамках одного DC. Эта операция называется “батчинг” (batching). Большинство объектов Unity может батчиться для получения наилучшей производительности на стороне CPU.
Встроенная поддержка батчинга в Unity имеет значительное преимущество над простым объединением геометрии в программе моделирования и перед использованием скриптов вроде идущего в пакете Standart Assets скрипта CombineChildren ). Батчинг в Unity работает после этапа определения видимости. Движок обрезает каждый объект индивидуально и количество визуализируемой геометрии остаётся таким же как и без батчинга. Объединяя же геометрию в программе моделирования или иным путём, вы снижаете эффективность обрезки и, в результате, визуализируется значительно большее количество геометрии .
Материалы
Батчатся только объекты, имеющие один и тот же материал. Соответственно, для эффективного батчинга вам необходимо делать материалы общими для множества объектов, если это возможно.
Если у вас есть два одинаковых материала, отличающихся только текстурами, можно объединить эти текстуры в одну большую — процесс часто называемый созданием текстурного атласа. Так вы сможете использовать один материал вместо двух.
Если нужно получить доступ к свойствам общего материала из скрипта, то важно помнить, что изменение Renderer.materialприведёт к созданию копии материала. Вместо этого следует использовать свойство Renderer.sharedMaterial, чтобы материал остался общим.
Динамический батчинг (Dynamic Batching)
Unity может автоматически батчить движущиеся объекты в один DC, если они используют общий материал и отвечают ряду других критериев. Динамический батчинг применяется автоматически и не требует дополнительных действий с вашей стороны.
- Динамический батчинг связан с дополнительной нагрузкой для каждой вершины , так что он применим только к мешам, содержащим менее 900 вершин в сумме.
- Если ваш шейдер использует Vertex Position, Normal и единственный UV, то вы можете батчить до 300 вершин; тогда как, если шейдер использует Vertex Position, Normal, UV0, UV1 и Tangent, то только 180 вершин.
- Обратите внимание: ограничение на количество атрибутов в будущем может быть изменено
- Как правило, объекты должны иметь один масштаб.
- Исключение для неоднородно масштабированных объектов; если несколько объектов имеют различное неоднородное масштабирование, то они всё ещё могут батчиться.
Статический батчинг (Static Batching)
Статичный батчинг позволяет движку снизить количество DC для геометрии любого размера, если она не двигается и использует общий материал. Статичный батчинг более эффективен, чем динамический. Вы должны стараться использовать статичный батчинг, чтобы снизить нагрузку на CPU.
При использовании статичного батчинга вы должны убедиться, что объекты статичны и не двигаются, не вращаются и не масштабируются во время выполнения. Если эти условия соблюдаются, можно пометить объекты как статичные, поставив галочку Static в Inspector:
Использование статичного батчинга требует дополнительной памяти для хранения объединённой геометрии. Если несколько объектов используют общую геометрию перед статичным батчингом, то копия геометрии создаётся для каждого объекта, либо в рантайме, либо в редакторе. Это может быть не очень удачной идеей — иногда вы можете пожертвовать производительностью визуализации некоторых объектов для снижения затрат памяти. Для примера, пометив все деревья как статичные на лесистом уровне вы можете получить серьёзный удар по объёму доступной памяти.
Статичный батчинг доступен лишь в Unity Pro для всех платформ.
Другие советы по батчингу
На данный момент, только Mesh Renderers и Particle Systems могут батчиться. Это значит, что skinned meshes, ткань, trail renderers и прочие типы рендеринг-компонентов не батчатся.
Полупрозрачные шейдеры часто требуют объектов, которые визуализируются в порядке “от заднего к переднему”, чтобы прозрачность работала корректно. Unity сначала визуализирует объекты в этом порядке и лишь затем пробует сбатчить их — так как соблюдение этого порядка очень важно, то эффективность батчинга для полупрозрачных объектов страдает по сравнению с непрозрачнымию
Некоторые части рендеринга Unity пока не поддерживают батчинг; например, батчинг не будет применяться при рендеринге объектов отбрасывающих тени, текстур глубины камеры, или GUI.
Оптимизация: почему время важнее полигонов
Многие начинающие 3D-художники и разработчики игр знают, что существует «оптимизация» — нечто, что позволяет повысить частоту кадров. Но зачастую они не разбираются в том, как она работает — и это заставляет их принимать неверные решения.
В этом материале преподаватель курса OutBlock и левел-дизайнер VOID Interactive Денис Куандыков объясняет, как устроена оптимизация, и почему количество полигонов тут — не ключевой фактор.
Если 3D-артист со стороны попытается самостоятельно оценить сложность кадра, то может получиться недоразумение. Художник не знает, какое количество треугольников будет оптимальным, если нет чёткого технического задания.
Если оно есть, это решает проблему. Но иногда техническое задание бывает нечётким не по вине заказчика: например, если вы сами разрабатываете собственную игру, или же если в проекте всё стандартно и нет ничего специфичного.
Как устроена отрисовка кадра
Процесс отрисовки кадра — это та самая «магия под капотом движка». У отрисовки, как и у работы художника, есть стоимость, и рассчитывается она исходя из необходимого времени.Для того, чтобы оценить время рендера, в редакторах и движках есть отдельные инструменты. Одного лишь значения кадров в секунду в любом случае недостаточно.
«Время кадра» — это время в милисекундах, за которое может быть построен и отрисован один кадр. Чтобы получить 60 кадров в секунду, один кадр должен быть обсчитан за 16 милисекунд или еще быстрее.
Draw Call (вызов отрисовки) — это одна графическая команда, которая должна что то отрисовать.
Сложность кадра можно оценивать именно с помощью вызовов отрисовки. Чем их больше, тем дольше они обсчитываются, тем медленнее выполняется 1 кадр, тем меньше кадров в одной секунде и тем меньше итоговый FPS.
И наоборот — чем меньше вызовов отрисовки, тем быстрее считается кадр, и тем выше FPS.
Примерный разброс лимитов на Draw Call можно описать так:
— Мобильные игры — примерно 100 на средне-высоких настройках, на топовых устройствах можно и больше.
— Игры для ПК и консолей — до 4000.
Например, Battelfield и третий «Ведьмак» в среднем работают на 1000-2000 вызовах отрисовки.
В то же время, некоторые внутренние движки Ubisoft спокойно работают на значениях вплоть до 20 тысяч. Дело в том, что Draw Call — это тоже не идеальное мерило производительности. Вызовы отрисовки бывают разные, и тут всё зависит от того как работает конкретный рендер-пайплайн в конкретном проекте. Подробно разобраться в том, как это устроено, можно здесь.
Рендер-пайплайн — это очень сложная система, и во многих крупных проектах она уникальна. Из-за этого оценить оптимизацию порой практически невозможно.
Однако вы можете самостоятельно проанализировать отрисовку кадра любой ПК игры, используя специальные инструменты:
— Intel Graphics Perfomance Analisys
Подробнее обо всех этих инструментах можно узнать здесь.
Самое важное: нужно оценивать стоимость кадра. А первичное мерило стоимости — это время. Уже затем можно всё раскладывать на процессы, то есть, на те самые вызовы отрисовки.
Когда обсуждают оптимизацию проекта и специфику его контента, в первую очередь речь заходит не о количестве полигонов, а о том, сколько примерно можно позволить себе вызовов отрисовки, — учитывая железо и технологии.
Вызовы отрисовки
Теперь разберёмся, как именно можно подсчитать количество этих вызовов.Простой пример: у нас есть 10 ящиков и одно дерево. Все десять ящиков имеют один и тот же шейдер, материал и количество полигонов. Логично предположить, что у нас будет 11 вызовов, ведь в кадре 11 объектов.
Всё почти так и есть. Программа рендерит так: «ящик, ящик, ящик, ящик, ящик. и потом дерево. Кадр построен».
Однако, судя по статистике, у нас всего три батча (вызова отрисовки):
Дело в том, что движок сам понимает, что перед ним десять одинаковых ящиков. Он сам «сшивает» ящики в один объект, и теперь процессор отдает нашей видеопамяти на отрисовку один кусок меша, который мы видим как 10 отдельных ящиков.
Этот процесс называется «батчинг». Он бывает динамическим и статическим.
Как устроен батчинг
Динамический батчинг работает, если он включен в движке. Движок сам анализирует геометрию и сшивает те объекты, которые подходят под лимиты.Обычно у динамического батчинга очень жёсткие лимиты; он не позволяет сшивать тяжёлую геометрию и занимается в основном мелкими деталями в кадре. Например, если от стены динамически отделились мелкие осколки, то они они, скорее всего, будут сшиты динамическим батчингом в каждом отдельном кадре.
Как устроен батчинг
Динамический батчинг работает, если он включен в движке. Движок сам анализирует геометрию и сшивает те объекты, которые подходят под лимиты.Обычно у динамического батчинга очень жёсткие лимиты; он не позволяет сшивать тяжёлую геометрию и занимается в основном мелкими деталями в кадре. Например, если от стены динамически отделились мелкие осколки, то они они, скорее всего, будут сшиты динамическим батчингом в каждом отдельном кадре.
Партикли (система частиц) умеют «сшиваться» сами по себе, поэтому их стоит использовать, если нужно нарисовать много одинаковых мелких объектов.
Например, тысячи рыб в кадре в Abzu — это на самом деле партикли, геометрия которых дополнительно анимирована шейдером с вертексной анимацией.
Отличие от динамического батчинга в том, что он позволяет перерабатывать огромное количество объектов. За один батч Unity может сшить объектов общим количеством до 64 000 треугольников.
Кроме того, динамический батчинг будет пытаться пересобрать геометрию почти в каждом новом кадре, — а значит будет постоянно увеличивать время расчёта.
Чтобы батчинг сработал, объекты должны быть «одинаковы». Объекты должны иметь один и тот же шейдер, материал на этом шейдере (в Unreal это инстанс материала), текстуру и остальные параметры объекта, а также не должны иметь Non Uniform Scale и не должны быть разбиты светом.
Одна из причин того, почему от художников требуют не текстурить объекты уникальными сетами отдельных текстур, а паковать их в огромные текстурные атласы — как раз в этом. Это позволяет отдать батчингу на обработку сотни разных визуально разных объектов, — ведь они будут отрисованы не отдельно, а группами.
Как уже было сказано, важнейшее мерило оптимизации — время. Иногда один раз загрузить в память один огромный текстурный атлас гораздо выгоднее, чем постоянно гонять туда-сюда отдельные мелкие текстуры — даже если в сумме они будут занимать в памяти меньше места, чем атлас целиком. Загрузка и выгрузка — не бесплатный процесс.
Однако батчинг тоже не «бесплатен» — даже если он статический и обсчитан заранее. Сцены в играх нужно освещать, и даже в случае статичного освещения это будет влиять на батчинг.
Так например, два одинаковых ящика, которые в обычной ситуации превратились бы в один батч, разделят на два батча, так как они привязаны к разным лайт-пробам (Light Probe).
Освещение в реальном времени тоже будет влиять на то, какие объекты сбатчатся, а какие — нет.
Кроме того, нужно учитывать где будет храниться полученный материал. Ведь сбатченная геометрия — это отдельный уникальный меш, который не заменяет ваши ящики на локации. То есть, батчинг требует свободной памяти.
Поэтому иногда применяют «ручной» батчинг, он же просто «мердж» (merge). Берём геометрию, и в любой программе сшиваем так, как нужно под конкретную сцену.
На финальных итерациях, когда весь левел-дизайн и левел-арт готовы, многие мобильные проекты проходят этап ручного сшивания всей локации. А модульные объекты, из которых состояла локация, и вовсе не идут в билд так как заменяются смерженным мешем.
Иногда гораздо выгоднее скормить движку огромный меш в 64 тысячи треугольников, чтобы отрисовать всю локацию целиком. Так поступили, например, разработчики Guns Of Boom.
Уровни детализации
Level of Detail (LOD, или уровень детализации) — простая техника, которая позволяет уместить огромное количество объектов в кадре, не отнимая время на обработку лишней геометрии.LOD может разбить объекты на разные батчи: и в этом нет ничего страшного, ведь зачастую несколько сотен лишних DrawCall будет быстрее обсчитаны на лодированых мешах чем рисовать их оригиналы — но сбатченные.
Сейчас есть неплохие инструменты автоматической генерации LOD-мешей, и это облегчает работу. При нужной настройке можно выдать результат не сильно хуже ручной ретопологии. Но даже используя автоматику, не стоит делать тысячи разных уровней детализации: все уровни LOD тоже нужно хранить в памяти, а её не стоит забивать просто так.
Обычно используют четыре уровня детализации. LOD-0 — это оригинальная модель, а LOD-3 — дальняя. LOD4 может быть просто 2D спрайтом который всегда смотрит на игрока.
Кроме LOD-0 порой нужно делать отдельную модель для кат-сцен. В ней может быть куда больше полигонов, чем у LOD-0, потому что она появляется лишь в срежиссированных сценах, и, как правило, находится очень близко к камере — поэтому для неё лучше использовать крайне высокую детализацию.
Это касается даже мелких объектов: например, у обычной кружки в одной из стартовых сцен Dead Space 2 было достаточно полигонов, чтобы она не казалась «квадратной», в то время как в остальной игре в LOD-0 у аналогичных объектов не было такого сглаживания.
LOD-ы позволяют не считать лишние сотни полигонов в вашей модели. В первую очередь важно понимать роль модели в сцене и прикидывать, насколько детально игрок сможет её разглядеть.
Если модель, например, можно разглядеть вблизи с максимальным приближением, то просто сделайте LOD-0 достаточно детализированным, — а в самой сцене основным рабочим уровнем будет LOD-1.
Подход, основанный на роли модели в кадре полностью защищает вас от критики сторонников «идеальной сетки», которые без понимания контекста — просто по скриншоту, — заявят, что вы сделали 10 лишних треугольников.
Alpha overdraw
Рендер-пайплайн должен адекватно рассортировать и нарисовать сцену — обработать шейдеры, геометрию, текстуры и пост-процессы. К тому же он должен учитывать, что объекты могут быть прозрачными.Чем больше площадь прозрачности в кадре, и чем больше прозрачные объекты наслаиваются друг на друга — тем дольше рендер-пайплайн будет рисовать итоговый пиксель, ведь ему придётся каждый раз его перерисовывать. Это называется Alpha overdraw.
Чем меньше альфы, тем быстрее будут обсчитаны пиксели. По сути, шейдер и сам рендер — это процесс/программа, которая рисует конкретный цвет конкретного пикселя на экране. И в этом случае пара десятков лишних треугольников, наоборот, ускорит рендер.
Z-Fight — артефакт, который образуется, если поставить несколько полигонов в одной плоскости. Рендеру не хватает точности глубины, чтобы отсортировать отрисовку этих полигонов в правильном порядке.
Но кроме визуального артефакта, который заметит игрок, это повлияет и на время рендера — ведь пиксели в этом месте будут постоянно «спорить» друг с другом об очереди отрисовки.
Итог
Итак, мы выяснили, что практически ничего «бесплатного» в случае с отрисовкой кадра не бывает: технологии, которые позволяют что-то оптимизировать, не работают по нажатию нужной галочки. Всегда нужно понимать, для чего мы используем тот или иной инструмент.
Нынешнее железо — даже мобильное, — может обрабатывать огромное количество треугольников. Объёмы памяти и скорость растут. Чипы на мобильных устройствах и их батареи, которые перегреваются при высоком FPS, тоже становятся всё совершеннее.
Взять и назвать точные диапазоны количества полигонов попросту невозможно — да и бессмысленно. Всё слишком сильно зависит от того для чего используется модель, и как ей видит игрок.