Godot + Spine: severe FPS drop

jofamaral

We are developing a slot game in Godot using Spine for reel symbols.
At runtime we have ₃₀ Spine Skeleton instances visible at the same time.
This game is our largest project so far:

18 different symbols
Each symbol is a separate Skin.
Each skeleton contains multiple animations representing states:
static
payline
blur
disabled

Note: Some states use mesh deformation.

In Godot:

Each reel cell instantiates one Skeleton.
Symbols frequently switch states.
set_to_pose() is used when changing animations to avoid state carry-over

Observed behaviour:
FPS drops to _29–40 FPS, and drop happens even when symbols are idle. Removing blur shaders improves performance, but not enough. Asset size and texture resolution are already optimized.

Alternative Spine Structure (worked correctly):
To isolate the issue, we tested another Spine file from a different game, used inside this project and the structure of the working file was:

Symbol states are represented as skins like: symbol01_idle, symbol01_payline, symbol01_disabled, etc. Only one animation is used. No calls to set_to_pose() are required

Result:
With 30 symbols on screen, performance is stable. FPS remains close to 100–120 FPS. No visible stutter during idle or state changes.
This file runs smoothly inside the same project, same scene, same Godot version, which strongly suggests the issue is related to Spine structure and runtime evaluation, not assets or rendering alone.

Hypothesis:
Based on these tests, we suspect performance degradation is related to:

Multiple animations per skeleton;
Frequent animation switching;
Use of set_to_pose() in Godot;

Questions:

Is using skins for state changes + one animation the recommended pattern for many on-screen symbols?
Is it expected that multiple animations per skeleton increase CPU cost in Godot, even when idle?
Is set_to_pose() particularly expensive in the Godot Spine runtime?
Are there any official guidelines for slot games using Spine with many simultaneous skeletons?

We are looking to confirm if this structure aligns with Spine best practices in Godot!
Thank you in advance!

Spinebot

Based on my knowledge of Spine and the Godot runtime, your hypothesis appears to be on the right track. Let me address your questions:

Is using skins for state changes + one animation the recommended pattern for many on-screen symbols?

Yes, this is generally a more performant approach when you have many instances of the same skeleton on screen. Using skins to represent different visual states while keeping a single animation is lighter on CPU than switching between multiple animations. Your alternative structure (symbol01_idle, symbol01_payline, etc. as skins) is a valid optimization pattern.

Is it expected that multiple animations per skeleton increase CPU cost in Godot, even when idle?

Yes, this can happen. Even when "idle," if animations are actively being applied (even if they're not visibly changing), there's computational overhead. Each animation application involves:

Posing bones based on keyframes
Calculating attachment vertices based on bone poses
Applying constraints

With 30 skeletons each processing multiple potential animation states, this overhead accumulates significantly.

Is set_to_setup_pose() particularly expensive in the Godot Spine runtime?

While set_to_setup_pose() itself is not extremely expensive, calling it frequently (especially across 30+ skeletons) does add up. When you switch animations frequently and reset poses, you're forcing additional skeleton updates. In your working alternative, you avoid this entirely by using skin switches instead of animation switches.

Are there any official guidelines for slot games using Spine with many simultaneous skeletons?

The general performance guidance applies here:

Recommendations for your case:

Prefer the skin-based approach you tested - this clearly works better for your use case with many simultaneous instances.
Minimize animation switching - If you must use multiple animations, consider whether some states could be represented through skins or by pausing/resuming a single animation at different times.
Consider the Update Mode - You can set the Update Mode property on SpineSprite instances that are truly idle to Manual and only update them when needed, rather than every frame.
Batch by texture - Ensure all your symbols share the same texture atlas page to enable batching in Godot's renderer.
Profile carefully - Use Godot's profiler to confirm whether the bottleneck is in the Spine skeleton updates (CPU) or rendering (GPU). The mesh deformation you mentioned could be a factor.

Your testing methodology was excellent - comparing two different Spine structures in the same environment clearly isolated the issue. The skin-based approach with a single animation is indeed better suited for scenarios with many simultaneous skeleton instances, like slot games.

jofamaral

In the case that worked before (which worked well), we had a single skeleton containing multiple skins (around 21 skins for 7 symbols, each skin representing a different symbol/state), and only one animation. This setup ran smoothly with ₃₀ instances on screen.

For our current project, this would scale to one skeleton with ₉₀ skins (18 symbols × multiple states). The skeleton structure itself is minimal and shared; skins had in the same symbol duplicated rigs. The .skel size would increase (roughly from ₁₂₀ KB to ₅₂₀ KB).

The alternative would be one skeleton per symbol (18 skeletons total), each containing only the skins to that symbol (around 5–6 skins each), still using the same pattern: one animation + skin-based states + no set_to_pose().

So the core question is: from a Spine and Godot runtime perspective, which approach is preferable for performance and stability when displaying ₃₀ symbols simultaneously?
Is it generally better to:
• keep one skeleton with many skins and duplicated rigs, or
• split symbols into multiple skeletons with fewer skins each?

We want to confirm whether the number of skins inside a skeleton has any runtime cost, or if performance is driven almost entirely by the number of active skeleton instances, bones, meshes, and deforms evaluated per frame.

Misaki

jofamaral The way you switch visual states, whether by using skins, animations, or changing attachments through code, generally does not create a significant difference in processing cost.

What is expected to impact performance is a high frequency of animation switching. Applying animations has a measurable CPU cost, and this cost scales with the number of timelines involved. To reduce overhead, it is recommended to minimize the number of timelines in your animations. The Metrics view page in the Spine User Guide explains this in detail:
https://esotericsoftware.com/spine-metrics#Timelines

Regarding set_to_setup_pose(), as Spinebot already mentioned, this call itself is not considered particularly expensive. It should not be a primary cause of performance degradation.

There are no official guidelines specifically for “games with many simultaneous skeletons.” Simply knowing that many skeletons are on screen is not enough to predict performance. A single complex skeleton can cause severe FPS drops even when displayed alone. For this reason, the Metrics view documentation is the best reference for understanding what actually drives performance costs.

As for your core question about structure: having a very large number of skins in a single skeleton should mainly affect initial loading time. It should not, by itself, cause FPS drops or ongoing runtime performance issues.

One point that Spinebot did not address, but is important here, is your mention of mesh deformation. Direct mesh deformation using deform keys should be avoided whenever possible when performance is a concern. Deform keys are relatively expensive compared to other animation techniques. This is covered in detail in the Spine User Guide here:
https://esotericsoftware.com/spine-keys#Deform-keys

I hope this answer is helpful.

jofamaral

Misaki

Hello, thank you again for the previous explanation, it helped us understand that timelines, animation switching frequency and mixing are the primary performance drivers.

We have a follow-up question regarding structure and performance.

Currently, our symbols are authored in a single Spine file with 18 skins and 6 animations (e.g. tumb, payline, flip, etc.). In Godot, this setup causes noticeable FPS drops. We tested alternative structures (including a large “many skins” approach), but those did not work for our use case either.

As a next step, we are now testing a hybrid approach, where:

some visual states are handled via skins (static/idle/disabled/blur, etc.), and only the states that require real motion (such as payline and flip) remain as animations.

This should significantly reduce animation switching and the number of timelines actively used during gameplay.

Question:
From a performance perspective, could it be more efficient to split these remaining animations across multiple Spine files, for example:
File A: 18 skins + 1 animation (payline)
File B: 18 skins + 1 animation (tumb)
File C: 18 skins + 1 animation (flip)

…and then switch between these skeleton resources in the engine depending on the symbol state, instead of having all remaining animations in a single skeleton?

Our concern is whether this approach could reduce overhead by limiting the number of timelines per skeleton and simplifying the AnimationState, or whether the main cost still comes from applying the active animation only, meaning that splitting into multiple files would not provide meaningful gains.

Additional context:
In the game, multiple Spine files are already active simultaneously (game frame, character, background, etc.), but FPS drops only occur when the symbol skeletons using the 18 skins + 6 animations structure are present.

Based on your experience, which approach would generally be healthier for performance in this scenario:
keeping all the symbols in one file and further reducing timelines, switching, and mixing or
splitting the animations into separate Spine files (one animation per file) and switching between them at runtime?

Thank you in advance for your insight.

Misaki

jofamaral I believe that both approaches are technically viable. Splitting skeletons per animation can, in some cases, be slightly more efficient, since it allows you to remove bones that never need to become active for a given animation. From a pure performance standpoint, this can offer some marginal benefits.

However, from a maintainability and workflow perspective, I would generally recommend keeping all symbol states within a single Spine file whenever possible.

Although this is not identical to your situation, the idea of splitting a single character across multiple skeletons and switching between them for specific animations is a fairly common approach in certain scenarios. A typical example is a character that can move in eight directions and significantly changes facing direction. In such cases, developers may prepare separate skeletons for front facing, diagonal front, back facing, and diagonal back poses, layer them in the scene, and switch which skeleton is active depending on the direction that should be shown.

That said, this approach introduces its own challenges. In particular, it becomes difficult to preserve animation state continuity across skeleton switches. For example, if a character starts an attack animation while facing backward and you want to change the facing direction partway through that animation, you may need to transfer the exact animation progress from the backward facing skeleton to the side facing skeleton. Handling these transitions cleanly can become quite complex and error prone.

I cannot say whether your game would encounter the same issues, but unless there is a strong and unavoidable reason to do so, I would generally advise against splitting a skeleton too aggressively into multiple files. Reducing timelines, animation switching frequency, and mixing complexity within a single skeleton is usually the healthier and more manageable solution overall.

Mario

@jofamaral could you send us a minimal Godot project that reproduces the performance degradation (contact@esotericsoftware.com)? It would also help if you tell us what target hardware and OS you are aiming at.

jofamaral

Hi,

We wanted to follow up and thank you again for your time and support during the investigation of the performance issue we were experiencing.
After further profiling and analysis on our side, we have now identified the root cause of the problem. The issue was not related to the Spine assets themselves, nor to skeleton structure, bones, meshes, or vertex transforms.
The main problem was located in the Spine runtime in Godot integration, specifically in how skins and meshes were being managed at runtime. Meshes associated with inactive skins were still being evaluated and processed every frame, meaning that elements which were not visually active were not being properly frozen or excluded from the update pipeline.

That said, the optimization work done on the Spine side also helped, as it allowed us to better understand the limits, reduce unnecessary complexity and validate which elements were (and were not) contributing to the performance cost. This process, together with your input, was very valuable for improving our internal design pipeline.

Once the runtime issue was corrected on the frontend side, by introducing proper freeze logic for inactive meshes and ensuring that only active/visible elements are processed per frame, performance improved significantly.

With this fix in place we are now able to use the original Spine file without structural changes.

The game is running at ₁₄₉ FPS in real gameplay scenarios.
The final setup uses 18 skins and 4 animations, fully optimized and stable.
This confirmed that the Spine files and metrics were correct from the beginning, and that the limitation was related to runtime handling rather than asset design.

Thank you again for your availability and support throughout this process, it was greatly appreciated.

Best regards!

Misaki

jofamaral Thank you for the detailed report! I'm glad you were able to identify the cause and resolve the issue. We'll keep this in mind for future reference to help users who encounter similar problems.

Mario

@jofamaral thank you for the analysis as well. Could you share how you fixed spine-godot wrt to inactive skins? This might be something other spine-godot users can benefit from as well.