Comments 5
Дерьмовая статья и дерьмовый перевод (что намекает на общее качество курса).
Начнем с перевода.
Для систем частиц, линий рендеринга и рендеринга трейлов…
… с помощью окклюзии Unity…
У Legacy Deferred (предварительный проход света) пути рендеринга
И так по всему тексту. Гуглопереводчик на марше.
По исходной статье. Практически везде фейл.
Чтобы подключить Remote Profiler, перейдите в меню Edit > Project Settings > Editor и в разделе Device выберите Any Android Device.
Вообще-то это никак не связано с профайлингом на девайсе, а нужно для использования мобильного приложения UnityRemote для отладки мультитач-ввода в редакторе.
Батчинг (Batching, или пакетная обработка) — очень хороший метод повышения производительности за счет сокращения количества вызовов Draw, который представляет из себя группирование рендеринга нескольких похожих GameObject-ов в одном вызове draw.
Не GameObject-ов, а мешей, висящих на них с MeshFilter / MeshRenderer. Рендерить меши можно и без GameObject — через Graphics.XXX, что тоже может батчиться.
Если ваши GameObject-ы не взаимодействует с вашим Player или если вы не меняете Transform, то лучше всего использовать статический батчинг для большинства вариантов среды в вашей игре, таких как здания, дороги и т. д.
Лучше никогда не использовать статик-батчинг, т.к он неконтролируем от слова "совсем" — можно получить меш из десятка треугольников на одном крае локации и десятка треугольников на другом, а т.к юнити определяет видимость меша для камеры через попадания баунда (габаритного AxisAlignedBox) в область видимости камеры, то такой меш будет всегда рендериться, даже если его не видно. К тому же такой меш всегда лежит как жирный меш в ресурсах самого билда, сильно раздувая его. Ну и копия статик-меша всегда лежит в оперативной памяти. Как неплохую замену следует использовать Mesh.CombineMeshes (о чем было указано ниже по тексту).
Пакетная обработка динамических GameObject-ов имеет определенные накладные расходы на каждую вершину, поэтому пакетная обработка применяется только к сеткам, содержащим не более 300 вершин и не более 900 атрибутов вершин.
Меш собирается каждый фрейм в буфер, что при большом количестве мелких мешей может наоборот — начать тормозить рендеринг из-за большой нагрузки на цпу при подготовке данных. Цифра 900 скорее всего никогда не поменяется, скорее динамический батчинг полностью будет выпилен из движка в угоду инстансингу и urp batching.
Ничего не сказано про "render queue", что очень важно и тоже ломает батчинг даже если все остальные условия были выполнены.
GameObject-ы не обрабатываются пакетно, если они содержит зеркальное отражение в transform (например, GameObject A со скейлом +1 и GameObject B со скейлом –1 не могут быть объединены вместе).
Любые отрицательные скейлы ломают батчинг, а не только идеальное зеркалирование.
Использование разных экземпляров Material приводит к тому, что GameObject-ы не объединяется в пакет, даже если они по сути одинаковы. Исключение составляет рендеринг Shadow Caster.
Если в тенях включена поддержка каскадов — они тоже ломают батчинг + дальность тени (не будет батчиться то что с тенями и то, что без).
Игровые объекты с картами освещения имеют дополнительные параметры рендеринга: индекс карты освещения и смещение/скейл в карте освещения. Как правило для пакетной обработки, GameObject-ы с динамической картой освещения должны указывать на одно и то же местоположение карты освещения.
Тут возникает 2 проблемы:
- лайтмапы в юнити могут быть запечены только от статики, которую не стоит использовать.
- попадание в нужную лайтмапу сложно контролировать.
Как решение — или сторонние плагины-запекалки или запекание во внешнем редакторе как надо и импортом мешей в юнити с сохранением UV2, содержащим координаты в лайтмапе.
В целом Occlusion Culling подразумевает, что Unity не будет отображать GameObject-ы, которые полностью скрыты с точки зрения камеры (окклюдированны) другими GameObject-ами.
Это опять же подразумевает статику, что автоматически увеличивает вес билда.
Ни слова не было сказано про instancing, что является на сегодняшний момент предпочтительным способом оптимизации рендера без значительной перегрузки цпу даже на мобильных платформах (доля gles2 устройств меньше 8% и будет все сильнее падать к 2022). Ни слова не было сказано про освещение скинмешей (лайтпробы — тоже статика, но можно переливать в динамике).
А с остальным полностью согласен!
Смысл в том, что сейчас уже нет смысла упарываться в динамик-батчинг на плотной сцене с повторяющимися объектами (как вот елки на картинке из статьи) — он никогда не вытянет скорость инстансинга. Динамик-батчинг уже по дефолту отключен на новых проектах и скорее всего будет выпилен через пару мажорных релизов в угоду инстансингу и urp batching-у, который работает совершенно не так.
Практические рекомендации по повышению производительности вашей игры на Unity. Часть 1