При работе с игровыми анимациями даже опытные аниматоры допускают ошибки и баги. В G5 Games научились избегать подобных проблем. Своим опытом хочет поделиться Михаил Шлыков, Spine-аниматор. За 8 лет работы со Spine он определил главные ошибки интеграции анимации и пути их решения. 

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

Для создания скелетной 2D-анимации часто используют Spine, DragonBones, Blender COA Tools, Rive и встроенный редактор Unity. Основным преимуществом такой анимации является возможность многократно использовать изображения, что позволяет экономить объем графики, хранимой в оперативной памяти. Эта идея лежит в основе максимальной оптимизации использования ресурсов. Повторное использование уже задействованных элементов позволяет повысить визуальную привлекательность анимаций без увеличения объема создаваемой графики.

В данном примере анимация взрыва создана с использованием всего четырех изображений.

Независимо от выбранного редактора, существует набор правил, соблюдение которых поможет вам заранее избежать трат времени на борьбу с багами.

• Нейминг и порядок проекта

Имена всех элементов, аттачментов и путей хранения анимационных файлов в операционной системе всегда должны быть на латинице, без пробелов и спецсимволов. Разные движки могут работать с разными кодировками, но латиница – это универсальный метод нейминга, поддерживаемый везде. 

Кроме того, важно следить за порядком в проекте и давать элементам легко читаемые названия. Это облегчит передачу исходных файлов другим аниматорам и упростит работу вам самим, если в будущем придется вернуться к какому-либо своему предыдущему проекту в Spine. Вы сможете быстрее и легче ориентироваться в нем даже спустя продолжительное время.

• Пути хранения изображений

Одной из причин потери аттачментов при экспорте являются абсолютные пути. Чтобы упаковка в атлас была корректной, рекомендуется указывать относительный путь к папке с изображениями.

• Работа с изображениями и их метаданными

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

Для этого метода упаковки атласа все аттачменты преобразуются в меш и с его помощью обрезаются пустые зоны. Этот приведет к увеличению количества треугольников в проекте, что следует контролировать и выбирать подходящий способ упаковки индивидуально.

Метаданные в PNG-изображениях могут значительно увеличить вес атласа и привести к фризам в Spine при работе с такой графикой. Старые версии скрипта Photoshop to Spine записывали метаданные в PNG, если эта функция не была отключена в Photoshop по умолчанию. Этот момент следует учитывать и проверять вес PNG-изображений после экспорта.

• Размер исходной графики

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

Михаил работал с разными игровыми движками – Unity, Pixie, Godot, Cocos Creator, а также с кастомным движком в G5 Games. За это время он выявил свой универсальный рейтинг влияния элементов Spine на производительность.

1 — Маски

Наиболее ресурсозатратным процессом при использовании масок является создание Draw Call — это запрос к графическому API на рендеринг визуала. В этот момент происходит сбор и анализ всех данных для отображения на экране, а вычисления выполняются на стороне CPU и GPU. Большая часть нагрузки приходится на сам процесс подготовки к запросу. Наличие маски в проекте генерирует два дополнительных запроса на отрисовку. Количество точек маски и её анимация почти не влияют на производительность, в отличие от самих запросов и площади скрываемых изображений.

2 — Режимы наложения

Игровые движки по-разному работают с умножением цветов изображений, поэтому влияние режимов, отличных от Normal, может различаться. При наличии слотов с режимами Additive, Multiply и Screen создается дополнительный запрос на отрисовку. Степень нагрузки в этот момент зависит от площади изображений, использующих эти режимы.

3 — Количество вершин меша 

Каждая точка имеет свои собственные координаты, и при каждом взаимодействии с мешем эти координаты ведут себя как отдельная кость. Каждый аттачмент, даже не превращенный в меш, имеет 4 вершины, поэтому увеличение количества вершин приводит к дополнительным расчетам в движке, нагружая CPU. А ручная деформация точек меша, без привязки к костям, ведет к созданию отдельного таймлайна для каждой из вершин меша. Дополнительной возможностью в работе с мешами является Linked mesh, который позволяет наследовать состояние меша для изображений одинакового размера, не создавая новых таймлайнов для мешей и не просчитывая их заново на стороне CPU.

4 — Bounding Box

В большинстве движков, при отсутствии Bounding Box он генерируется динамически для каждого кадра анимации, что сильно влияет на производительность. Поэтому лучше создавать Bounding Box вручную в Spine. Кроме того, наличие Bounding Box позволяет выгружать из памяти анимированный объект в момент его выхода за пределы экрана, что также повышает производительность.

5 — Constraints

FK и IK констрейны в движке представляют собой математическую конструкцию, влияющую на положение костей. Их наличие добавляет дополнительные вычисления на CPU. По влиянию на производительность каждый из констрейнов сравним с десятью дополнительными костями.

6 — Пути

На стороне движка путь – это кубическая кривая Безье, каждый из отрезков которой строится по четырем точкам. Построение задействует CPU, но кривые используют тот же принцип построения, что и положение костей, с отличиями только в визуальном представлении и дополнительных элементах управления кривой.

7 — Кости

Кость является минимальной вычислительной единицей, которая может перемещаться в пространстве и передавать данные движку для отслеживания координат. Каждая кость добавляет данные для обработки CPU: чем больше костей, тем с большим массивом данных приходится работать.

8 — Скины

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

9 — Слоты

Слоты — это контейнеры для хранения аттачментов. Поскольку слоты не могут перемещаться без костей, они требуют минимального количества ресурсов. Основная нагрузка ложится на GPU, так как таймлайны для перемещения в пространстве не создаются.

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

Размер создаваемого атласа должен быть кратен двум. Если анимация создается для использования на мобильных устройствах, размер не должен превышать 2048 пикселей по длинной стороне. Это ограничение связано с невозможностью отображения изображений более 2048 пикселей по длинной стороне на устройствах Apple.

Одной из частых проблем с графикой после экспорта являются артефакты вокруг PNG-изображений, такие как черные обводки и белые свечения с полупрозрачными пикселями.

Причина этого кроется в несоответствии режимов альфы материала в проекте и экспортированной анимации. За режим работы альфы отвечают параметры Premultiply Alpha и Bleed. Вариант при экспорте следует выбирать в зависимости от настроек проекта в игровом движке.

Еще один тип графических артефактов при экспорте — это резкие линии обрезки изображения. Причиной может стать отсутствие отступов у изображений. Это исправляется увеличением отступов по осям X и Y.

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

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

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

Удаление лишнего — это базовый способ оптимизации. Часто при риге мы создаем более сложные структуры для увеличения подвижности и больших возможностей рига. Однако после создания необходимых анимаций мы можем не использовать все возможности рига. В этом случае упрощаем риг для повышения производительности.

• Фейковый add режим

Иногда возможности использования режимов наложения изображений ограничены и приходится находить альтернативы. В таких случаях поможет использование дополнительных аттачментов, в которых запечены эффекты. Способ применим, когда эффект additive не выходит за границы основного объекта. Для этого в режиме SETUP на необходимые аттачменты применяется эффект наложения и производится экспорт как PNG. После аттачменты с режимом additive заменяются на полученные ранее изображения, но уже в режиме normal.

• Удаление лишних точек меша

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

• Отключение аттачментов в анимации

В случаях, когда нужно скрыть аттачмент и увести его в прозрачность, всегда следует отключать этот аттачмент, а не просто оставлять прозрачным. Это позволит освободить память и снизить нагрузку на GPU, так как даже уведенный в прозрачность аттачмент участвует в расчете рендеринга и обрабатывается при каждом запросе на отрисовку.

• Сокращение кадров секвенций

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

• Уменьшение размера графики фона и эффектов 

Однотонные изображения фона и изображения с размытыми краями (облака, свечения, лучи света, тени и так далее) можно уменьшать в два и более раза, восстанавливая их размер скейлом в Spine. Это дает возможность уменьшить размер атласа и освободить оперативную память и объем хранимой графики билда.

• Выбор формата экспорта

На стадии формирования проекта предпочтения по экспортируемому формату анимации следует отдавать двоичному формату .skel. В отличие от формата .json он имеет меньшие объемы и быстрее считывается движком. Каждый ключ анимации – это набор чисел, определяющий положение и свойства объектов. Одно число в двоичной системе – это 4 байта информации, когда в .json формате это 8-9 байт. При многократном обращении к этим значениям во время анимации разница может быть значительной.

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

Компания G5 стремится к расширению и созданию свежих проектов. Мы всегда в поиске новых художников. Если вы хотите попробовать себя в развивающейся игровой сфере, присоединяйтесь к нам!