Pull to refresh
828.09
OTUS
Цифровые навыки от ведущих экспертов

Практические рекомендации по повышению производительности вашей игры на Unity. Часть 1

Reading time 6 min
Views 6.7K
Original author: Mahesh Athirala
Всем привет. В преддверии старта курса «Unity Game Developer. Basic» подготовили для вас полезный перевод.




Введение


Когда мы делаем игры, мы часто не уделяем должного внимания одному из самых важных аспектов разработки игры — оптимизации. В результате мы получаем лаги и низкий FPS (иногда даже на High-end устройствах, если все совсем уж запущенно). Большинство людей всегда будет рассматривать оптимизацию игры как последний этап, и именно это является первой ошибкой — она всегда должна быть первым пунктом в списке.

Невозможно переоценить привычку при каждой сборке, каждый день, когда вы добавляете новую механику или новую настройку освещения, или какие угодно системы, основанные на физике, в вашу игры, всегда проверять билд, не возникли ли какие-либо проблемы с производительностью из-за этих изменений — это хорошая практика разработки игр.

Если вы не потратите время на оптимизацию производительности с самого начала работы над проектом, на финальном этапе это может вылиться в проблемы для вас и вашей игры. Здесь я хочу поделиться некоторыми мыслями и советами о том, как вы можете повысить производительность вашей игры, основываясь на нескольких практических выводах, которые я извлек из своих ошибок за последние 5 лет.

Профилируйте свою игру


Профайлер (Profiler) — первый в списке и один из моих самых любимых инструментов в Unity для мониторинга производительности игры с целью узнать, что на самом деле вызывает проблемы с производительностью. Он очень полезен для получения подробного представления о том, как ваша игра реагирует на различные изменения в редакторе.


Вы можете найти Profiler в Window->Analysis->Profiler

Он отображает такие категории, как использование CPU и GPU, рендеринг, физику, аудио и многое другое. Мы не можем полагаться на профилирование в редакторе (Editor Profiling), поскольку редактор влияет на производительность проекта во время тестирования, а это может влиять на достоверность информации профилирования. Для получения точных данных профилирования лучше создавать отдельный билд.

Удаленное профилирование (Remote profiling)


Чтобы заставить его работать, вам необходимо установить Android SDK и подключить JDK и USB дебаггинг. Помните, что всегда полезно тестировать, как работает ваша игра, когда речь идет о механике, масштабировании пользовательского интерфейса и т. д. Не говоря уже о тестировании реальной производительности в игре вкупе с вышеперечисленным. Чтобы протестировать реальную производительность игры, вам нужно создать специальный билд для профилирования.


Чтобы подключить Remote Profiler, перейдите в меню Edit > Project Settings > Editor и в разделе Device выберите Any Android Device.

Билд для профилирования


Чтобы убедиться, что Unity имеет доступ к вашему билду, который можно профилировать, вы должны включить “Development build or Deep Profiling Support” и “Auto-connect Profiler” в настройках билда перед его созданием. Это позволяет редактору Unity автоматически подключать ваш билд.



Когда ваша бид будет готов, не закрывая окно Unity Profiler откройте свою игру. Теперь Unity будет автоматически отображать данные о производительности текущего билда игры в окне профайлера.

Узнать о профайлере больше вы можете здесь.

Батчинг GameObject-ов


Батчинг (Batching, или пакетная обработка) — очень хороший метод повышения производительности за счет сокращения количества вызовов Draw, который представляет из себя группирование рендеринга нескольких похожих GameObject-ов в одном вызове draw. Существует два типа методов батчинга: статический и динамический. Для батчинга существуют некоторые ограничения — мы не можем выполнять пакетную обработку skinned мешей, ткани и некоторых компонентов рендеринга.

Статический батчинг


Статический батчинг (Static Batching) используется всякий раз, когда GameObject-ы статические. Такие статические GameObject-ы не должны перемещаться, масштабироваться или вращаться, а также должны использовать один и тот же материал для всех статических GameObject-ов, чтобы батчинг работал.

Если ваши GameObject-ы не взаимодействует с вашим Player или если вы не меняете Transform, то лучше всего использовать статический батчинг для большинства вариантов среды в вашей игре, таких как здания, дороги и т. д.



Динамический батчинг


Динамический батчинг (Dynamic Batching) похож на статический в том, что для GameObject-ов должны использоваться те же материалы, но может группировать движущиеся объекты без необходимости делать их статическими. По сути, Unity может автоматически загружать GameObject-ы в один и тот же вызов отрисовки, если они используют один и тот же материал, но на них накладываются некоторые ограничения динамической пакетной обработки в соответствии с Unity:

  1. Пакетная обработка динамических GameObject-ов имеет определенные накладные расходы на каждую вершину, поэтому пакетная обработка применяется только к сеткам, содержащим не более 300 вершин и не более 900 атрибутов вершин.
    • Если ваш Shader использует Vertex Position, Normal и один UV, вы можете группировать до 300 вершин, но если ваш Shader использует Vertex Position, Normal, UV0, UV1 и Tangent, то только 180 вершин.
    • : ограничение количества атрибутов может измениться в будущем.
  2. GameObject-ы не обрабатываются пакетно, если они содержит зеркальное отражение в transform (например, GameObject A со скейлом +1 и GameObject B со скейлом –1 не могут быть объединены вместе).
  3. Использование разных экземпляров Material приводит к тому, что GameObject-ы не объединяется в пакет, даже если они по сути одинаковы. Исключение составляет рендеринг Shadow Caster.
  4. Игровые объекты с картами освещения имеют дополнительные параметры рендеринга: индекс карты освещения и смещение/скейл в карте освещения. Как правило для пакетной обработки, GameObject-ы с динамической картой освещения должны указывать на одно и то же местоположение карты освещения.
  5. Multi-pass шейдеры исключают батчинг.
    • Почти все шейдеры Unity поддерживают несколько источников света при прямом рендеринге, эффективно выполняя за них дополнительные проходы. Вызовы отрисовки для «дополнительных источников света на пиксель» не группируются.
    • У Legacy Deferred (предварительный проход света) пути рендеринга динамический батчинг отключен, потому что он должен отрисовывать GameObject дважды.

Для систем частиц, линий рендеринга и рендеринга трейлов динамический батчинг работает иначе, чем для мешей.

  1. Для каждого совместимого типа рендерера Unity собирает весь батч контент в 1 большой Vertex Buffer.
  2. Рендерер устанавливает состояние материала для батча.
  3. Unity связывает Vertex Buffer с Graphics Device.
  4. Для каждого рендерера в батче Unity обновляет смещение в Vertex Buffer, а затем отправляет новый вызов отрисовки.

Есть и другие способы улучшить батчинг, используя некоторые ассеты из Assetstore, такие как Simple Mesh Combine, Bakery, или мы также можем использовать Mesh.CombineMeshes для объединения нескольких сеток в одну, что идеально подходит для оптимизации производительности.

Запекайте ваше освещение


Грубо говоря, есть три режима освещения: Realtime, Baked и Mixed.

Realtime самый лучший, НО за него приходится платить производительностью. Он вносит прямой свет в сцену и обновляет каждый кадр, когда источники света и игровые объекты перемещаются внутри сцены, обновляя освещение немедленно.

Всякий раз, когда у вас есть возможность запечь (bake) освещение на сцене, обязательно используйте ее, потому что это идеальный вариант для повышения производительности, особенно если вы ориентируетесь на мобильные устройства. Всегда лучше использовать небольшое освещение на сцене, чтобы добиться желаемого вида.



Таким образом, все ваши источники света будут предварительно вычисляться в автономном режиме в процессе под названием Lightmap Baking (запекание). Когда вы устанавливаете GameObject Lightmap Static Flag, Unity запекает информацию о GameObject Light, тенях, отраженном свете и мягких тенях в текстурах, которые касаются вашей сцены. Однако Lightmaps имеет некоторые ограничения, освещение не может обновляться динамически для выбранных вами объектов с Lightmap Static Flag.





Несколько месяцев назад в свободное время я сделал SCIFI сцену, и я думаю, что это лучший пример, показывающий, как работает запеченное освещение. Конечно, я использовал Emission.

Если кого-то интересует обзор создания этой SCIFI сцены, и как я добился этого вида, дайте мне знать, может быть, я мог бы посвятить этому отдельную статью.
Вот видео, если вам интересно!


Используйте отсечения


Это очень хороший способ повысить производительность вашей игры с помощью окклюзии Unity. В целом Occlusion Culling подразумевает, что Unity не будет отображать GameObject-ы, которые полностью скрыты с точки зрения камеры (окклюдированны) другими GameObject-ами.


Чтобы открыть окно Occlusion перейдите в Window->Rendering->Occlusion Culling


Если кого-нибудь заинтересовало то, как я добился такого вида сцены Mystery Forest, дайте мне знать, возможно, я мог бы написать отдельную статью про это.
Вот видео, если вам интересно!

twitter.com/i/status/1096336962259021824

По умолчанию Unity применяет Frustum Culling, что означает, что он отображает только линию обзора камеры, показывая все объекты. Например, если камера смотрит на стену, все объекты за этой стеной также будут визуализированы. Нам это совсем не нужно, поэтому следует добавить в нашу сцену Occlusion Culling.



Вот почему мы должны использовать Occlusion Culling, что означает, что камера будет отображать только стену без объектов за ней.


Читать ещё:


Tags:
Hubs:
-3
Comments 5
Comments Comments 5

Articles

Information

Website
otus.ru
Registered
Founded
Employees
101–200 employees
Location
Россия
Representative
OTUS