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.

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.

​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.

Great! It sounds like you have a reasonable plan. Please let us know how it goes or if you run into any issues. I'm confident we can find ways to get you past any humps.