Scalability Limits for Character Customization with High Attachment Count

叶湘伦

Hello,
We've hit a major snag in our game project and need some guidance on Spine limits, especially about attachment counts. Here's the deal:

Our Setup: Unity mobile game with heavy Spine usage for the main character.
The Character: Has tons of customizable parts (hair, clothes, etc.). Players can mix and match them freely. Need to show dozens of these characters on screen too.
Current Stats:
Bones: 1133, Slots: 116, Anims: 280, Attachments: 10,393, Skins: 313.
The Problem: Bones/slots/anims seem fine, but our attachment count is exploding as we add more custom content. New skins aren't just texture swaps – they have unique meshes, attachments, and even animations, so artists have to build them in Spine. Can't do it at runtime easily.
Worst Offenders: Adding one new hair + clothes combo adds 200 new attachments!
The Scary Part: We've seen posts where Nate mentions keeping attachments around 50k for stability. At our current pace (adding 200 attachments per combo), we'll hit that limit after adding only 200 more combos 😬. That's maybe 2 years of content at best. That really puts a damper on our long-term plans.

We tested Spine Editor limits (i9-13900K CPU):

50k attachments? Runs smooth @ 60FPS.
80k? Still pretty good @ 60FPS.
100k? Starts dropping frames noticeably.

In Unity: Adding 10k attachments costs us 6MB more managed memory.

Our Big Fear: We want to keep expanding the character forever, but both the Spine Editor and Unity will eventually choke as the attachment count balloons.

Our Idea (Desperate Hack?):
Could we export each fully-made skin from Spine as its own separate file, then remove those skins from the main Spine project? Then, in Unity, load/unload these skin files on-demand.

Why this might suck:

Pain for Artists: Animators would constantly need to export/import/backup skins. Super messy workflow.
Code Nightmare: We'd have to dig deep into the Spine runtime source in Unity to make this loading work. Big changes!

Our Ask:

Does this "split into skin files" idea sound technically possible? Any big gotchas?
OR – Is there a better/smarter way to handle massive attachment counts from deep customization that we're missing?
Any official advice or best practices for hitting Spine's limits with tons of unique skins?

Thanks!

Spinebot

To manage a high number of attachments and skins in Spine, you can consider several strategies to optimize performance and scalability. One approach is to manually pack the attachments of each skin into separate texture atlases, ensuring that only the necessary atlases are loaded at runtime, which helps in reducing memory usage. Additionally, you can dynamically create attachments at runtime using conventions, which allows you to avoid specifying every attachment in your Spine project. This can be particularly useful for items that only require sprite swaps, such as different colors of the same item.

Your idea of exporting each skin as a separate file and loading them on-demand in Unity is technically feasible, but it may complicate the workflow for artists and require significant changes to the Spine runtime in Unity. Instead, consider using a mixed approach where only essential elements are rigged in Spine, and other elements are swapped at runtime. This can help manage the attachment count more effectively. Also, keep in mind that while there is no hard limit on the number of skins, managing them efficiently with folders and applying recolors via code can help maintain performance.

Nate

It sounds like you've thought through it pretty well.

Bones: 1133, Slots: 116, Anims: 280, Attachments: 10,393, Skins: 313.

1133 is a lot of bones, but could be perfectly fine, depending on the target hardware and especially on what else you are doing in your app. If you can put bones (and constraints) in skins, they only have a performance impact when active.

116 slots doesn't say much. Vertex transforms is a better metric. Be sure to prune every single mesh, eg a max influence of 4 is common. Many tools have a hardcoded limit of 4. Avoid clipping.

280 animations and 313 skins is fine. They take up some storage and memory but otherwise have no limit or performance impact for having many, beyond loading. Avoid deform keys.

10,393 attachments is OK for the editor. As you found, the editor can scale up to around 80k. We might be able to scale farther, but honestly we don't put a lot of effort into that. You probably shouldn't rig 80k attachments in the editor as it would take an ungodly amount of effort. At that scale you definitely want to find other ways to do it.

New skins aren't just texture swaps – they have unique meshes, attachments, and even animations, so artists have to build them in Spine. Can't do it at runtime easily.

Every mesh is truly unique? Are you sure you can't use template attachments? It may be easier (now) not to, but the advantages are great. When using templates the images don't have to be the same, it's normal they have whitespace. With region attachments the whitespace doesn't take up atlas space and doesn't even use up fill rate at runtime, since it is not drawn at all -- prefer regions over meshes where possible.

Editor performance aside, needing to rig tens of thousands of attachments in Spine is very time consuming. Templates and conventions can save a LOT of time and effort, allowing artists to focus solely on generating new content. Even if you need many templates, reuse could still save you a lot.

We don't have a way to do partial skeleton exports. A single skeleton is always exported together, as fracturing it into pieces invites problems that wouldn't otherwise exist. Still, you could export and then break up the data relatively easily. If you do, I suggest doing it with the binary format. However, doing that solely to avoid loading attachment data at runtime isn't worth it IMO. 6MB memory per 10k attachments is reasonable.

Exporting the whole skeleton but only a single skin, so it can be imported back into the editor, isn't great. I think a better idea is (worst case that you can't use templates) to just copy your project, delete all the skins, then juggle 2 (or more) project files. That allows you to scale to any number of attachments, as far as editor performance is concerned.

That works OK as long as you don't change the structure (don't add new bones, slots, or constraints). At some point you probably don't want to keep adding those things anyway. If you do need to change the skeleton, you'll have to change it in all project file copies. That is the fragile part.

With multiple projects, at runtime you may be able to load multiple skeletons, then use skins/attachments from one skeleton in another. Check what references are kept to be sure, there may be some minor fix up. If you mess up and change the skeleton bones/etc things will break.

叶湘伦

Nate

Nate If you can put bones (and constraints) in skins, they only have a performance impact when active.

Yes, we are using bones (and constraints) in skins. The number of concurrently active bones is around 120, and it runs smoothly.

Nate Every mesh is truly unique? Are you sure you can't use template attachments? It may be easier (now) not to, but the advantages are great. When using templates the images don't have to be the same, it's normal they have whitespace. With region attachments the whitespace doesn't take up atlas space and doesn't even use up fill rate at runtime, since it is not drawn at all -- prefer regions over meshes where possible.

I understand your suggestion about template attachments, but there's a fundamental challenge: Our hair and clothing skins differ drastically. Most aren't achievable through texture swaps alone, as they involve unique meshes and topology. Animators even create skin-specific animation tweaks for certain items. I'm uncertain if templates can handle this complexity reliably. We'll need to discuss this approach internally with our art/tech team to assess feasibility.

You mentioned splitting into multiple Spine skeletons. If we ensure identical bone/slot/constraint structures across all skeletons, can skin data loaded from different skeletons be mixed and reused at runtime? If this works, it could genuinely solve our scaling issues.

Additionally, after splitting into multiple Spine projects: What’s the best way to sync new additions (bones, slots, constraints, or animations) across all projects?

Nate

Our hair and clothing skins differ drastically. Most aren't achievable through texture swaps alone, as they involve unique meshes and topology.

While a workflow that allows all skin attachments to be unique provides a lot of flexibility, it may still be reasonable to reuse some of them. It may even be reasonable to modify your approach to creating new skins to maximize reuse. Your artists may still be able to fully achieve their goals.

If you can template say 50%, that may be a big enough win to warrant the complexity of using templates, eg doubling the time you can stay with a single project.

If we ensure identical bone/slot/constraint structures across all skeletons, can skin data loaded from different skeletons be mixed and reused at runtime?

Yes, it should work. Skin and attachments are stateless and don't care about the SkeletonData or Skeleton used.

What’s the best way to sync new additions (bones, slots, constraints, or animations) across all projects?

The best way is to not have any changes. 😉 Otherwise you probably authorize only one person to make changes to the skeleton, and they must be diligent about making the same changes to both/all projects. You won't have to implement this system until you exceed a reasonable number of attachments within a single project.

It's similar to having multiple people work on animations using the same skeleton, then using Import Project to bring the animations into a "master" project.

The risk is someone breaks the rules, changes the skeleton, and uses it in their skin -- everything breaks at runtime and someone has to sort it out. You could consider tools that exercise the code paths that break, so you can automate running them when someone commits a bad project, alerting you as early as possible.

It could be interesting for Spine to allow "locking" the skeleton so breaking changes can't be made as easily.

we are using bones (and constraints) in skins. The number of concurrently active bones is around 120, and it runs smoothly.

If you want to lock down the skeleton but still need bones for skins, you could possibly reuse existing bones from other skins, as long as those other skins aren't shown at the same time. The bones would probably be in the wrong position in the setup pose, but could be correct in skin specific animations.

叶湘伦

Thank you for the suggestions. We will collect our existing skins to evaluate template reuse and assess what benefits it could bring to our workflow.

Nate The risk is someone breaks the rules, changes the skeleton, and uses it in their skin -- everything breaks at runtime and someone has to sort it out. You could consider tools that exercise the code paths that break, so you can automate running them when someone commits a bad project, alerting you as early as possible.

As our costume styles are still expanding, we inevitably need to add a small number of bones occasionally. However, we've discussed this and expect the bone count to stabilize and no longer change by the time we hit the attachment limit. This means it won't be a concern going forward.

Also, regarding the "reuse existing bones from other skins" you mentioned, we are already using it. The setup pose problems did cause some issues initially, but fortunately, we've resolved them by updating anim immediately.