The post has been translated automatically. Original language: Russian
When working with game animations, even experienced animators make mistakes and bugs. G5 Games has learned to avoid such problems. Mikhail Shlykov, Spine animator, wants to share his experience. Over the 8 years of working with Spine, he has identified the main errors in animation integration and ways to solve them.
Problems with performance and animation display can occur in any project, regardless of the game engine and animation editor used. We will talk about common problems when integrating Spine animations into a game engine, as well as offer basic animation optimization methods. This article will be useful for both Spine animators who export animations and developers who work with animations in game engines. Many of the principles described are also applicable to animation editors other than Spine.
Spine, DragonBones, Blender COA Tools, Rive, and the built-in Unity editor are often used to create skeletal 2D animations. The main advantage of such animation is the ability to reuse images, which saves the amount of graphics stored in RAM. This idea is at the heart of maximizing resource utilization. Reuse of already used elements allows you to increase the visual appeal of animations without increasing the volume of graphics created.
In this example, the explosion animation was created using only four images.
Regardless of the editor you choose, there is a set of rules that will help you avoid wasting time dealing with bugs in advance.
- Naming and project order
The names of all elements, attachments, and storage paths for animation files in the operating system should always be in Latin, without spaces or special characters. Different engines may work with different encodings, but Latin is a universal naming method that is supported everywhere.
In addition, it is important to keep order in the project and give the elements easy-to-read names. This will make it easier to transfer the source files to other animators and simplify the work for yourself if you have to return to any of your previous projects in Spine in the future. You will be able to navigate it faster and easier even after a long time.
- Image Storage Paths
One of the reasons for the loss of attachments during export is the absolute paths. To ensure that the packaging in the atlas is correct, it is recommended to specify the relative path to the folder with the images.
- Working with images and their metadata
Before starting work, you should always check the graphics for unused empty spaces that were accidentally created in the graphics editor. Even a single random translucent pixel can complicate the work with graphics and increase the size and weight of the final atlas. One of the ways to reduce the size of the atlas is polygonal packaging, in which images are packed taking into account the boundaries of their mesh size.
For this atlas packing method, all attachments are converted into a mesh and empty areas are cut off with its help. This will lead to an increase in the number of triangles in the project, which should be monitored and the appropriate packaging method selected individually.
Metadata in PNG images can significantly increase the weight of the atlas and lead to Spine friezes when working with such graphics. Older versions of the Photoshop to Spine script recorded metadata in PNG unless this feature was disabled in Photoshop by default. This point should be taken into account and the weight of PNG images should be checked after export.
- The size of the original graphics
Often, the original graphics are provided for animation in higher resolution. To minimize unnecessary animation actions, it is important to know in advance what the final size will be used in the engine. This will avoid adjusting the size of the skeleton and exported graphics to Spine after creating the animation. Changing the size of graphics before exporting from the graphics editor is much easier than redoing an already configured rig.
Mikhail worked with different game engines – Unity, Pixie, Godot, Cocos Creator, as well as with a custom engine in G5 Games. During this time, he revealed his universal rating of the impact of Spine elements on performance.
1 — Masks
The most resource—intensive process when using masks is to create a Draw Call, which is a request to the graphics API for rendering a visual. At this point, all data is collected and analyzed for display on the screen, and calculations are performed on the CPU and GPU side. Most of the workload falls on the process of preparing for the request itself. The presence of a mask in the project generates two additional rendering requests. The number of mask points and its animation have almost no effect on performance, unlike the queries themselves and the area of the hidden images.
2 — Overlay modes
Game engines work differently with image color multiplication, so the effects of non-Normal modes may vary. If there are slots with Additive, Multiply, and Screen modes, an additional rendering request is created. The degree of load at this moment depends on the area of the images using these modes.
3 — The number of mesh vertices
Each point has its own coordinates, and with each interaction with the mesh, these coordinates behave like a separate bone. Each attachment, even if it is not turned into a mesh, has 4 vertices, so increasing the number of vertices leads to additional calculations in the engine, loading the CPU. And manual deformation of mesh points, without reference to bones, leads to the creation of a separate timeline for each of the mesh vertices. An additional feature in working with meshes is Linked mesh, which allows you to inherit the mesh state for images of the same size without creating new timelines for meshes and without calculating them again on the CPU side.
4 — Bounding Box
In most engines, in the absence of a Bounding Box, it is generated dynamically for each frame of animation, which greatly affects performance. Therefore, it is better to create a Bounding Box manually in Spine. In addition, the Bounding Box allows you to unload an animated object from memory when it leaves the screen, which also improves performance.
5 — Constraints
The FK and IK constrains in the engine are a mathematical construct that affects the position of the bones. Their presence adds additional calculations to the CPU. In terms of the impact on performance, each of the constranes is comparable to ten additional dice.
6 — Ways
On the engine's side, the path is a cubic Bezier curve, each segment of which is plotted at four points. The construction uses the CPU, but the curves use the same construction principle as the position of the bones, with differences only in the visual representation and additional curve controls.
7 — Bones
A bone is a minimal computational unit that can move in space and transmit data to the engine to track coordinates. Each bone adds data for processing by the CPU: the more bones there are, the more data you have to work with.
8 — Skins
Skins are a visual representation of the used set of attachments. On the engine side, they add markers to switch attachments and dice, as well as their properties.
9 — Slots
Slots are containers for storing attachments. Since slots cannot be moved without dice, they require a minimum amount of resources. The main load falls on the GPU, as timelines for moving in space are not created.
Before exporting the animation, make sure that all unnecessary and unused elements (dice, slots, attachments, background files, additionalanimations in use) have been removed from the Spine project and from the images folder.
The size of the atlas to be created must be a multiple of two. If the animation is created for use on mobile devices, the size should not exceed 2048 pixels on the long side. This limitation is due to the inability to display images larger than 2048 pixels on the long side on Apple devices.
One of the common problems with graphics after exporting is artifacts around PNG images, such as black outlines and white glows with translucent pixels.
The reason for this lies in the discrepancy between the alpha modes of the material in the project and the exported animation. The Premultiply Alpha and Bleed parameters are responsible for the alpha's operating mode. The export option should be selected depending on the project settings in the game engine.
Another type of graphic artifacts during export is sharp cropping lines. The reason may be the lack of margins in the images. This is corrected by increasing the margins on the X and Y axes.
Incorrect animation display may be caused by the Clean Up animation function. This feature automatically removes unnecessary animation keys, which greatly optimizes animation. However, sometimes it can lead to incorrect display of attachments or incorrect position of bones. This is due to inheriting the state of the bones when switching animations. Inheritance of states is configured in the game engine, and this issue should always be discussed with the developer.
Optimization should not be the main goal when creating animations, because otherwise the artistic expressiveness of animations suffers, and we begin to limit ourselves in the means used. You don't need to optimize anything for no good reason, otherwise it will be a waste of time. It is necessary to approach the problem wisely and determine in advance the limit values that should not be exceeded. If the acceptable values are exceeded and there are real performance problems, you should spend your efforts on optimization. Sometimes even a very stressful animation with effects looks good and does not affect performance if there is nothing else on the stage but it.
Therefore, we recommend starting optimization at the final stage in case of real performance problems, finding alternatives to the tools used and increasing productivity by reducing elements.
Removing excess is a basic optimization method. We often create more complex structures at Riga to increase the mobility and greater opportunities of Riga. However, after creating the necessary animations, we may not use all the features of the rig. In this case, we simplify the rig to increase productivity.
- Fake add mode
Sometimes the possibilities of using image overlay modes are limited and you have to find alternatives. In such cases, the use of additional attachments in which the effects are baked in will help. This method is applicable when the additive effect does not extend beyond the boundaries of the main object. To do this, in SETUP mode, an overlay effect is applied to the necessary attachments and exported as PNG. After that, the attachments with the additive mode are replaced with the previously obtained images, but in the normal mode.
- Removing unnecessary mesh points
When rigging a mesh, points are often created to increase the smoothness of bends and provide more opportunities when working with graphics. But after the animation, it turns out that the mesh could have been simpler. Visually, there are no differences if we remove any points. Removing unnecessary dots will have a positive effect on animation performance.
- Disabling attachments in animation
In cases where you need to hide an attachment and make it transparent, you should always disable this attachment, and not just leave it transparent. This will free up memory and reduce the load on the GPU, since even the attachment involved in transparency is involved in the rendering calculation and is processed with each rendering request.
- Reduction of sequence frames
Using sequences in animation, quite often the difference between a high sequence frame rate and a low one is not noticeable on mobile devices. Therefore, removing unnecessary sequence frames will not only reduce the atlas, but also increase productivity. For smoother animation, sequence frames can be distorted with a mesh, or pulled out of the sequence like a regular container and animated with bones — by enlarging, moving, and tilting them.
- Reducing the size of background graphics and effects
Monochrome background images and images with blurred edges (clouds, glow, rays of light, shadows, and so on) you can reduce them by two or more times by restoring their size with a scale in Spine. This makes it possible to reduce the size of the atlas and free up RAM and the amount of stored build graphics.
- Choosing the export format
At the stage of project formation, preferences for the exported animation format should be given to the binary .skel format. Unlike the format .It has smaller json volumes and is read faster by the engine. Each animation key is a set of numbers that determine the position and properties of objects. One number in binary is 4 bytes of information when in .The json format is 8-9 bytes. If you access these values multiple times during animation, the difference can be significant.
Communicating with developers and artists, as well as clarifying all possible limitations and requirements, play a key role in creating high-quality animations. Close cooperation with the team helps to identify potential problems and requirements in advance, which allows you to avoid many mistakes and save a significant amount of working time. Do not neglect this important aspect of the work, and your projects will be successful and effective.
G5 strives to expand and create fresh projects. We are always on the lookout for new artists. If you want to try yourself in the developing gaming field, join us!
При работе с игровыми анимациями даже опытные аниматоры допускают ошибки и баги. В 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 стремится к расширению и созданию свежих проектов. Мы всегда в поиске новых художников. Если вы хотите попробовать себя в развивающейся игровой сфере, присоединяйтесь к нам!
Share
