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 8 years of working with Spine, he has identified the main errors of animation integration and ways to solve them. 

Performance and animation display problems 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 the game engine, as well as suggest basic methods for optimizing animations. This article will be useful for both Spine animators who export animations and developers working with animations in game engines. Many of the principles described also apply 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 amount 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 fighting bugs in advance.

• Naming and order of the project

The names of all elements, attachments and paths for storing animation files in the operating system should always be in Latin, without spaces and special characters. Different engines can 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 make it easier for you to work 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 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 zones are cut off with it. 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 friezes in Spine 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 actions with animation, 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 the exported graphics in Spine after creating the animation. Changing the size of the graphics before exporting from the graphics editor is much easier than redoing an already configured rig.

Mikhail has worked with various 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 - this is a request to the graphical 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 load 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 effect of modes other than Normal may vary. If there are slots with Additional, Multiply and Screen modes, an additional rendering request is created. The degree of load at this point 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 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 vertices of the mesh. 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 the animation, which greatly affects performance. Therefore, it is better to create a Bounding Box manually in Spine. In addition, the presence of a Bounding Box allows you to unload an animated object from memory at the moment 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 bones.

6 — Ways

On the engine side, the path is a cubic Bezier curve, each of the segments of which is built on 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 set of attachments used. On the engine side, they add markers to switch attachments and bones, as well as their properties.

9 — Slots

Slots are containers for storing attachments. Since slots cannot move without dice, they require a minimum amount of resources. The main load falls on the GPU, since timelines for moving in space are not created.

Before exporting an animation, make sure that all unnecessary and unused elements (dice, slots, attachments, background files, additional unused animations) are removed from the Spine project and from the image 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 export are artifacts around PNG images, such as black strokes 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 when exporting is the sharp cropping lines of the image. The reason may be the lack of indentation 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 the 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 permissible values are exceeded and there are real performance problems, you should spend effort on optimization. Sometimes even a very loaded 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 in Riga to increase the mobility and greater opportunities of Riga. However, after creating the necessary animations, we may not use all the features of riga. In this case, we simplify the rig to improve performance.

• 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 will help. The method is applicable when the additive effect does not go 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 greater possibilities when working with graphics. But after the animation, it turns out that the mesh could have been simpler. Visually, there is no difference if we remove any dots. 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 an attachment that is transparent 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 improve performance. 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 — enlarging, moving and tilting them.

• Reducing the size of the background graphics and effects

Monochrome background images and images with blurred edges (clouds, glow, rays of light, shadows, and so on) it can be reduced by two or more times, 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 defines the position and properties of objects. One number in the binary system is 4 bytes of information when in .The json format is 8-9 bytes. If these values are accessed repeatedly during animation, the difference can be significant.

Communicating with developers and artists, as well as figuring out all possible limitations and requirements, play a key role in creating high-quality animations. Close interaction 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 is committed to expanding and creating fresh projects. We are always on the lookout for new artists. If you want to try yourself in the developing gaming field, join us!