Optimizing memory for many mix-and-match outfits and 60 players

zebro

I’m developing a 2D multiplayer game in Unity using spine-unity, and I’d like some guidance on memory / atlas management for a character system with many outfits and full mix-and-match.

Project requirements

Each character is built with Spine.

There will be hundreds of outfits in the future.

Outfits are fully mix-and-match per body part, e.g.:

skin color, eyes, eyebrows, face, makeup, mouth

hair, clothes, bag, balloon, eyeglass, shoes

In a match, there can be up to ₆₀ players on screen, each with their own customized outfit.

I’m using YooAsset for runtime loading and hot-update.

Current setup

Right now, my artist exports:

One “base” SkeletonDataAsset (body + face parts, multiple skins: skincolor/xxx, eyes/xxx, etc.)

Separate SkeletonDataAssets for each part:

hairDataAsset, clothesDataAsset, bagDataAsset, balloonDataAsset, eyeglassDataAsset, shoesDataAsset

All these skeletons share the same bones / skeleton structure.

On the Unity side I have a SpineAvatarManager that:

Creates a Skin customSkin = new Skin("custom-avatar");

AddSkin from the different SkeletonDataAssets, for example:
customSkin.AddSkin(baseData.FindSkin(skincolor)); customSkin.AddSkin(baseData.FindSkin(eyes)); ... customSkin.AddSkin(hairData.FindSkin(hair)); customSkin.AddSkin(clothesData.FindSkin(clothes)); ... skeleton.SetSkin(customSkin); skeleton.SetSlotsToSetupPose(); animationState.Apply(skeleton);
(Optionally) does GetRepackedSkin to generate a single material/atlas for that avatar.

I’ve read the docs and these threads:

Memory management of character with many outfits
https://esotericsoftware.com/forum/d/15867-memory-management-of-character-with-many-outfits/16

Delayed on-demand loading of Atlas assets (#1890)
EsotericSoftware/spine-runtimes1890

From these I understand:

I should remove any (indirect) references to atlas textures from scenes/prefabs, e.g. set Skeleton materials’ mainTexture to a small dummy texture, so Unity doesn’t auto-load all outfit textures.

When needed, I should load the real atlas textures via Addressables/AssetBundles/YooAsset and plug them back into the Materials (and maybe use the experimental on-demand loading package).

What I’m unsure about

Given my case (hundreds of outfits + 60 players), I’d like to ask:

Is my multi-SkeletonData approach OK?

One base SkeletonData + separate SkeletonDataAssets for hair / clothes / bag / shoes etc., all sharing the same bones, combined with Skin.AddSkin on the main skeleton.

Is this a recommended approach for large mix-and-match systems, or would you suggest using one big SkeletonData with all attachments in different skins instead?

Repacking strategy for 60 players

If I call GetRepackedSkin for every customized player, I may end up with 60 different runtime atlases, which seems heavy in terms of memory.

In your experience, is it better to:

Only repack the local player (and maybe a few important characters), and let other players use multi-material skins?

Or try to reuse repacked skins when multiple players share the same combination (same outfit ID), and only create a new repack for unique combinations?

Best practice for atlas texture loading/unloading

Right now, to avoid Unity auto-loading all textures, I’m planning to:

In Editor: replace all Spine atlas materials’ mainTexture with a 2×2 dummy texture, so scenes/prefabs don’t reference the full textures.

At runtime: when a certain outfit is needed, load the actual atlas texture via YooAsset and assign it back to the correct SpineAtlasAsset.Materials.

Is this approach recommended, or should I rely only on the experimental delayed on-demand loading package mentioned in issue #1890?

Any advice on how to combine the experimental on-demand loading with Addressables/AssetBundles/YooAsset correctly?

Official sample or reference

Is there any official sample or recommended pattern that demonstrates:

A character with many outfits,

Mix-and-match skins across body parts,

And runtime loading/unloading of atlas textures via Addressables/AssetBundles (or similar)?

Any guidance on architecture and best practices (especially around memory usage vs. draw calls vs. repacking) would be greatly appreciated.
Thank you for your time!

Harald

zebro I’ve read the docs and these threads:

Memory management of character with many outfits
https://esotericsoftware.com/forum/d/15867-memory-management-of-character-with-many-outfits/16

Delayed on-demand loading of Atlas assets (#1890)
EsotericSoftware/spine-runtimes1890

Please note that the referenced forum thread above was before the official Spine on-demand-loading extensions were released. While the approach in the forum thread is different, you might save the time and just use the official on-demand loading and addressables packages.

Note that there is also an official documentation page regarding on-demand loading and addressables, there should be no need to read the issue ticket any longer:
https://esotericsoftware.com/spine-unity-on-demand-loading

Is my multi-SkeletonData approach OK?

In general it's ok to use multiple separate SkeletonDataAssets to provide additional skins, given that the skeleton structure is the same (which you mentioned it is).

The question is what your reasons are why you would want to do that. For performance or load time there is no real reason for going in this direction if you use the provided on-demand loading extensions to delay texture loading. It makes sense if you say you later want to add specific single skins in separately downloadable packages, without having to update e.g. the main game package. It also depends on whether you have one or multiple artists working on the same skeleton, or whether the single skeleton file becomes too cluttered for your artist (it should not be a problem with e.g. folders and the like though).

Also there is a difference between whether you have a single Spine project and export multiple SkeletonDataAssets from it, or whether you have many copies of the Spine project, one for each skin or set of skins. Having multiple projects comes with the serious drawback that you can't modify the skeleton easily any more, e.g. adding even skin bones becomes problematic which would be easy with a single project.

zebro Repacking strategy for 60 players

If I call GetRepackedSkin for every customized player, I may end up with 60 different runtime atlases, which seems heavy in terms of memory.

In your experience, is it better to:

Only repack the local player (and maybe a few important characters), and let other players use multi-material skins?

It depends on your actual use case and target hardware, it's impossible to answer. In general I would assume that repacking all skins would be the better solution - if you have so many different equimpent items, it sounds like more atlas textures and vastly more draw calls if not repacked.

zebro Or try to reuse repacked skins when multiple players share the same combination (same outfit ID), and only create a new repack for unique combinations?

This makes little sense to optimize, as it sounds highly unlikely that two players share the same outfit. It's your project though, so you have to decide whether it's worth the effort.

zebro At runtime: when a certain outfit is needed, load the actual atlas texture via YooAsset and assign it back to the correct SpineAtlasAsset.Materials.

Is this approach recommended, or should I rely only on the experimental delayed on-demand loading package mentioned in issue #1890?

I don't know YooAsset, so I can't say anything on that specifically. In general I would use the officially provided on-demand loading and addressables extensions, unless you have reasons not to.

zebro Is there any official sample or recommended pattern that demonstrates:

A character with many outfits,

Mix-and-match skins across body parts,

And runtime loading/unloading of atlas textures via Addressables/AssetBundles (or similar)?

Currently there is just the Spine Examples/Other Examples/Mix and Match Skins example scene demonstrating multiple skins for equipment items, but not in combination with on-demand loading.
How to use on-demand loading is shown in the documentation page here, it's pretty simple to setup:
https://esotericsoftware.com/spine-unity-on-demand-loading#Usage

Spinebot

Memory Optimization for Mix-and-Match with Many Players

Your setup is quite ambitious with 60 players and hundreds of outfits! Let me address your questions:

1. Multi-SkeletonData Approach

Your approach of using separate SkeletonDataAssets for different body parts is workable but not ideal for this scale. Here's why:

Better approach: Use one SkeletonData with all parts organized in separate skins (skin/skincolor, eyes/xxx, hair/xxx, clothes/xxx, etc.). This gives you:

Shared skeleton and animation data (only loaded once)
All parts authored together in Spine Editor with proper preview
Easier to maintain and update animations
More efficient memory usage for skeleton/animation data

The key is smart atlas texture management rather than splitting the SkeletonData itself.

2. Repacking Strategy for 60 Players

Creating 60 different repacked atlases would indeed be very memory-heavy. Here are better strategies:

Recommended approach:

Don't repack for background players at all. Let them use multi-material rendering. With 60 players, the draw call overhead from multiple materials is likely acceptable compared to the memory cost of 60 repacked textures.
Only repack for the local player (and maybe 2-3 closest/important characters) where visual quality matters most.
Reuse repacked skins when players share identical outfit combinations - maintain a cache dictionary with outfit combination IDs as keys.

Example caching approach:

Dictionary<string, Skin> repackedSkinCache = new Dictionary<string, Skin>();

string GetOutfitID(OutfitConfig config) {
    return $"{config.skinColor}_{config.eyes}_{config.hair}_{config.clothes}...";
}

Skin GetOrCreateRepackedSkin(OutfitConfig config) {
    string id = GetOutfitID(config);
    if (!repackedSkinCache.ContainsKey(id)) {
        // Create and repack new skin
        Skin combinedSkin = new Skin("custom");
        // ... AddSkin calls ...
        repackedSkinCache[id] = combinedSkin.GetRepackedSkin(...);
    }
    return repackedSkinCache[id];
}

Remember to clear the cache periodically:

AtlasUtilities.ClearCache();
Resources.UnloadUnusedAssets();

3. Atlas Texture Loading/Unloading

Your dummy texture approach is a reasonable workaround, but has downsides:

Better approach with YooAsset:

Structure your atlases by outfit category - pack each outfit type (hair, clothes, accessories) into separate atlas pages during export from Spine. This is done by organizing images into folders and using the Texture Packer's folder structure packing.
Load atlas assets on-demand:
- Remove atlas asset references from the SkeletonDataAsset's atlasAssets array in the editor
- At runtime, load the SpineAtlasAsset via YooAsset when needed
- Assign it to skeletonDataAsset.atlasAssets array
- Call skeletonDataAsset.Clear() and Initialize(true) to rebuild

Example:

async Task LoadOutfitAtlas(string outfitType) {
    var handle = YooAssets.LoadAssetAsync<SpineAtlasAsset>($"Atlas_{outfitType}");
    await handle.Task;
    
    SpineAtlasAsset atlas = handle.AssetObject as SpineAtlasAsset;
    // Add to your skeleton's atlas array
    // Then Clear() and Initialize()
}

The experimental on-demand loading package mentioned in issue #1890 is not yet officially released. Your manual approach with YooAsset is currently the way to go.

4. Optimized Architecture Recommendation

Here's what I'd recommend for your specific case:

Spine Setup:

One SkeletonData with all outfit parts as separate skins
Pack atlases by folder structure - one atlas per outfit category (hair atlas, clothes atlas, etc.)
Export with multiple atlas pages, each containing one category

Unity Setup:

Keep only the "base" body atlas referenced in the SkeletonDataAsset
Load outfit atlases on-demand via YooAsset
Use Skin.AddSkin() to combine outfit parts (no repacking for most players)
Only repack the local player's skin

Memory Strategy:

Load atlas textures for only the outfit combinations currently visible
Maintain a reference count for each atlas texture
Unload atlases when no player is using them anymore
Use texture compression and mipmaps where appropriate

Draw Call Strategy:

For 60 players, 3-5 submeshes each = 180-300 draw calls, which is manageable
Optimize draw order in Spine to minimize material switches within each character
Use GPU instancing where your platform supports it

Additional Tips

Texture resolution: Consider using lower-resolution textures for distant players (LOD system)
Visibility culling: Don't update animations or apply skins for off-screen players
Pooling: Pre-warm a pool of skeleton instances rather than instantiating during gameplay
Binary export: Use .skel.bytes instead of .json for faster loading
Metrics: Use Spine Editor's Metrics view to optimize vertex counts and keys

Unfortunately, there's no official sample specifically demonstrating this exact scenario with addressables/bundles, but the Mix and Match example scenes included with spine-unity demonstrate the core Skin.AddSkin() and repacking concepts you need.

Your approach is on the right track - the key is being selective about what you repack and when you load textures. Good luck with your multiplayer game!

zebro

Is there a human customer to reply? Still a little confused

zebro

如果我所有的皮肤都在一个SkeletonDataAssets 里面，导出.json的时候不打包图集，手动打包按文件夹分类好的图集，比如 hair.atlas clothes_1.atlas clothes_2.atlas。
runtime：通过AddSkin组合皮肤，再通过GetRemappedClone加载对应的atlas图片。
这样行的通吗，是正确的操作吗？

zebro

感谢您的回复！
所以现在我理解的是：只使用一个.skel.bytes，里面包括了所有皮肤(以后可能有几百个skin，现在是按部位分皮肤，比如很多个Hair的skin，很多个Clothes的Skin.....)，然后通过on-demand loading加载正在使用的texture。（是否就不会加载到其他未使用的图片资源？）
另外，如果这样做的话，怎么导出图集？

zebro 不打包图集，手动打包按文件夹分类好的图集，比如 hair.atlas clothes_1.atlas clothes_2.atlas。

这是对的吗？
我希望您能具体的说明一下Spine中怎么输出文件给Unity。（我需要和Spine制作人员沟通）
再次感谢我才接触Spine两个星期，有比较多不明白的。on-demand loading 我还没仔细研究，我接下来会去研究他。

Harald

Please don't export as .json but export binary as .skel.bytes, otherwise you waste space and loading time (as described e.g. here).

runtime：通过AddSkin组合皮肤，
Runtime: Combine the skin through AddSkin,

This is correct.

再通过GetRemappedClone加载对应的atlas图片。
and then load the corresponding atlas image through GetRemappedClone.

This does not make too much sense here. You should not need to call GetRemappedClone at all, that's for e.g. replacing a single attachment image with a custom Sprite (see the example scenes, e.g. Mix and Match Equip). On-demand loading is triggered automatically for you, you don't have anything to do other than set up the assets accordingly.

If you misunderstood GetRemappedClone that it does repacking: If you have a combined skin, you'll want to repack the whole skin by calling skin.GetRepackedSkin. See the documentation here:
https://esotericsoftware.com/spine-unity-main-components#Runtime-Repacking
This is also shown in all three example scenes Spine Examples/Other Examples/Mix and Match Skins, Mix and Match and Mix and Match Equip.

Repacking with on-demand loading:
When using on-demand loading, all that changes is that you would want to wait until the atlas textures are fully loaded before repacking, otherwise you repack the placeholder textures. For that, you can access AtlasAsset.OnDemandTextureLoader and register to TextureRequested and TextureLoaded. In the TextureRequested callback delegate you could e.g. increase a blocking counter and in TextureLoaded decrease the blocking counter again, and when the blocking counter reaches 0 again (no textures loading in the background anymore) you can repack your whole skin.

foreach (AtlasAssetBase atlasAsset in skeletonRenderer.SkeletonDataAsset.atlasAssets) {
    atlasAsset.OnDemandTextureLoader.TextureRequested += OnTextureRequested();
    atlasAsset.OnDemandTextureLoader.TextureLoaded += OnTextureLoaded();
    // eventually also subscribe to `.TextureLoadFailed` for special error recovery.
}

Note: on-demand loading is triggered in the next LateUpdate call (in LateUpdateMesh) that follows setting the skin. So you might want to call LateUpdateMesh once after setting the new combined skin to ensure on-demand loading is immediately started so that your callacks are working.

An easier alternative:
Alternatively to the loading callback delegates, you could also simply check whether any of the textures at meshRenderer.sharedMaterials is of size <= yourPlaceholderSize;

Harald

So what I understand now is: use only one .skel.bytes file that contains all the skins (in the future there may be hundreds of skins; right now the skins are separated by body parts—for example many Hair skins, many Clothes skins, etc.),

(As machine translation is a bit ambiguous, some of the things might already be clear to you, I just want to make sure nothing important remains open.)

You should definitely export as .skel.bytes, never as .json.

Whether you are exporting a single .skel.bytes file containing the skeleton and all skins, or one base .skel.bytes file plus additional separate .skel.bytes and .atlas.txt files is up to you and your possible workflow. If your art department can manage everything in a single Spine project, that would be making things easier. The Spine on-demand loading and addressables extensions can then be used to load all materials just with a very small placeholder texture, and the full-size textures are then downloaded via addressables when required. You can set them up in addressable packages how you like, grouping them as you think fits best.

If your artists have to work on separate Spine project copies, one for each skin (or set of skins), exporting additional .skel.bytes files that's fine as well. You could then download the required set of skins, which consists of one additional .skel.bytes file, one .atlas.txt file and multiple atlas textures (plus the automatically generated associated Unity assets). Then you however have more programming work to make that all work: you need to write code to:

determine which package needs downloading
download the package
load the SkeletonData from the new SkeletonDataAsset (which reads the .skel.bytes file) and either appends it to the base SkeleletonData, or otherwise manage the additional downloaded skins.
handle unloading eventually to save both RAM and VRAM.

While this is all doable, it's more work and more infrastructure that you have to manually build yourself. The on-demand loading extensions handle downloading, switching and unloading automatically for you. The small downside is that you only save downloading textures, and not the general skin data in the .atlas.txt and .skel.bytes files. The textures make up the vast majority of the size however.

and then use on-demand loading to load only the textures that are currently being used.

Yes, this is automatically done for you once you set up the assets.

zebro: Don’t pack the atlases in Spine. Manually pack atlases that are sorted by folder, like hair.atlas, clothes_1.atlas, clothes_2.atlas.

Is this correct?
I hope you can explain in detail how to export Spine files for Unity. (I need to communicate this with the Spine artists.)

In general we highly recommend automating your exports via the Spine command line interface. This allows you to easily re-export all assets in one go, and if you decide you need to make any changes, you would otherwise have to manually re-export hundreds of files, which is error-prone and takes a lot of time. Also you can much easier re-export in a new Spine version, e.g. currently using Spine 4.2 and later re-exporting everything from Spine 4.3.

Also keep in mind that while currently Spine 4.3 is in beta, the spine-unity 4.3 changes are rather large, e.g. adding multi-threaded animation and mesh generation, and changing the main component architecture, splitting animation and rendering components, see here. So if you later decide to switch to 4.3, it's much easier to re-export all your skeletons for 4.3 via the Spine CLI. (You can of course also decide to right-away start with 4.3-beta if your project scope and risk structure permits that.)

Regarding packing separate atlases: If you don't use the Spine on-demand loading extensions, you might then want to pack by folder structure using the CLI, and arrange your attachment images in folders which should later be packed together. There are a few threads on this forum regarding packing by folder structure, e.g. see this posting here for some references.

If you are using the Spine on-demand loading extensions and exporting as a single .skel.bytes file, you still have the option to pack atlas textures by folder structure to make sure you can determine which attachment images are grouped together on one atlas page texture. You can then either create multiple .atlas.txt atlas file, one for each folder, or via the CLI pack the parent folder containing subfolders, with each subfolder having a pack.json file defining that this folder shall be packed to a separate atlas page but a shared .atlas.txt description file. It's up to you and your team which is more feasible when distributing work.

Harald

Thanks again. I’ve only been using Spine for two weeks, so there are still many things I don’t understand. I haven’t studied on-demand loading closely yet, but I will look into it next.

I forgot to say above: Please be sure to have a look at all example scenes, and especially the Spine Examples/Other Examples/Mix and Match Skins example scene and code on how to combine skins as you will need, then the older Mix and Match and Mix and Match Equip example scenes which show without using skins how you can replace single attachments (e.g. from Unity Sprites) if you need that.