Blog #rendering

Дело касается в основном мобилок, но вообще принцип тот же везде. Overdraw - это по сути метрика, с помощью которой можно понять сколько раз вы закрашиваете один и тот же пиксель. Во-первых, красить пиксель дважды - плохая примета. Во-вторых, видяхи на мобилах довольно слабые и каждый новый проход по одному месту может сильно просаживать производительность.

На практике легко получить такую проблему партикл системой с тысячами частиц. Может казаться, что производительность падает из-за количества частиц, но на самом деле проблема на 99% в overdraw. Кстати, для этого в настройках рендера партикл системы есть параметр, который ограничивает максимальный размер частицы относительно размера экрана, т.к. чем больше площадь - тем хуже. Поэтому 100 больших частиц у камеры хуже, чем 10к, но далеко.

На самом деле вариантов всего три:

1. Вы делаете дополнительную ортографическую камеру, которая снимает сверху весь ваш мир (или нужный кусок), которая может исключать определенные слои или, напротив, включать определенные слои, которые не видит основная камера.

2. Вы для каждого объекта считаете позицию в мире и проецируете ее на UI, т.е. если позиция объекта в мире находится в точке 10;20 и размер мира 100x100, то на миникарте эта позиция будет 10/100;20/100 в процентах, а значит умножив полученные проценты на размер миникарты - получим точку в UI миникарты.

3. Гибридный вариант. Когда мы можем снимать некоторые объекты "как есть", а потом накладывать поверх уже вариант 2 для pixel-perfect варианта.

Еще я бы сюда добавил такой интересный момент: для 1-го варианта можно использовать лоды, чтобы сократить количество треугольников + сократить количество draw call.

Я предпочитаю использовать только второй вариант + подкладывать (или вообще не использовать) фон.

Партиклы можно использовать в качестве рендера своих спрайтов.

Для этого нужно вызвать var count = particleSystem.GetParticles(particlesArr); изменить массив и вызвать particleSystem.SetParticles(particlesArr, count).

Таким образом можно контролировать тысячи частиц. На практике мы с таким столкнулись, когда нам нужно было отрисовать 4 тысячи юнитов на экране телефона, при этом каждый юнит имел по 4 спрайта, т.е. 16к спрайтов на одном экране старенького андроида в 2015м году. 

Тогда юнити еще толком не умела нормально контролировать партиклы и пришлось писать свои партиклы на плюсах, что повлекло за собой боль с поддержкой этого кода под все платформы (а это были PS4/XBOXONE/Switch/iOS/Android/PC(x86/x64). И да, в итоге юнити доделали партиклы и мы с радостью избавились от этого кода, но осадочек то остался 😉

Если у вас в проекте есть много skinnedmesh анимаций (например, у вас по лесу бегает много животных), то их анимации можно запечь в текстуру, откуда читать шейдером. Такие анимации будут работать довольно с сильной погрешностью, но для объектов окружения этого может быть вполне достаточно. Такое решение намного производительнее, т.к. работает с одной текстурой и укладывается в один DrawCall.