dreamau wrote

Note that skeletons in both files match (completely or mostly), so I was assuming at least some outfit parts would show.

If both files contain the same Slots, it is expected to work. [Edit: Attachments don't need to exist in both, these can only exist in the skin's skeleton data]

I just tested this locally with two exports of the Goblins project (one with all skins deleted), using your script with the adaptation of

var outfitSkin = outfitSkeletonData.FindSkin("goblingirl");

instead of

var outfitSkin = outfitSkeletonData.DefaultSkin;

It successfully displayed the goblingirl skin for me.

What kind of error message or exception do you get? Are you sure that your Slots and Attachments match?
Could you perhaps send us the problematic exported assets (or a minimal Unity project)? You can send it as a zip file to contact@esotericsoftware.com

One more solution (a bit more complex however) would also be to programmatically concatenate json files before loading, or appending content of your Skins skeletonData after loading. This is briefly mentioned here on this forum thread:
多个spine共享一套骨骼动作

Regarding your second solution:
FYI: We have an issue ticket that deals with implementing delayed (partial) loading of atlas textures:
https://github.com/EsotericSoftware/spine-runtimes/issues/1890

The disadvantage here is that I need to load whole SkeletonDataAsset, which contains the meshes and some other data for all outfits, and I suspect this file will not be tiny. Can this be stores as binary to avoid parsing cost at least perhaps?

The skeleton .json or binary .skel.bytes file size should not be the problem usually. You can export it as binary:
Export - Spine User Guide: Data
Removing or replacing texture references from an atlas and loading the textures on-demand would be a viable solution. It basically would require to creating a wrapper around SetSkin calls that ensures to load/unload textures and hook up the references as you described. It should not be necessary to write your own AttachmentLoader, replacing texture references depending on the next skin to be set should be easier to implement and sufficient for many use cases.

dreamau wrote

1. the slots are not in the same order .. and so slot index does not match. This somehow seems important, as even this function uses slot index:

Different slot order is a problem then, since the skin's slotIndex is used to assign the attachment at the base skeleton's slot at this index.

What you can do is find the Slot of the same name in the body skeleton's skeletonData as shown below:
(this is using the Spine 3.8 API, if you are using 4.0-beta you need to slightly adjust the lines accessing the skinEntry in outfitSkin.Attachments, as you posted in your original code in the first posting of this thread)

// instead of customSkin.AddSkin(outfitSkin);

var bodySkeletonData = Body.GetSkeletonData(true);
foreach (var pair in outfitSkin.Attachments) {
   var skinEntry = pair.Key;
   string slotName = outfitSkeletonData.Slots.Items[skinEntry.SlotIndex].Name;
   int bodySlotIndex = bodySkeletonData.FindSlotIndex(slotName);
   customSkin.SetAttachment(bodySlotIndex, skinEntry.Name, skinEntry.Attachment);
}

dreamau wrote

2. the names of attachments don't match .. but I assume those don't have to?

Sorry, this was actually a wrong statement, the attachments don't need to match or even exist in the body skeleton data part, only the slots need to. I'll edit my original posting to mention this as well.

Sorry to hear that it's not working as desired yet. Thanks for sending the reproduction project, we received everything. We will have a look at it and will get back to you once we've figured out what's going wrong.

The problem with your project seems that there are missing slots in your body skeleton. You are trying to attach e.g. JuliaArmor/belt to slot named belt, but this slot does not exist in your body skeleton. Same goes for all other slots that fail to be attached (with a returned slotIndex or -1 at FindSlotIndex()).

Are you sure that these slots existed in the original body Spine project? If so, could you please check your export settings or share some screenshots of the export settings you used?

Oh, I see. I have been misled by your project setup of the missing attachments, and I incorrectly assumed that e.g. JuliaArmor/footL was intended to show the naked foot attachment, but it is instead intended to show an armoured boot. I will have another look at your project and will get back to you when we've figured it out.

The problem turned out to be that all your attachments are successfully set, but they are just not shown in setup pose. E.g. you have Slot forearmL and in the setup pose you have attachment JuliaNude/forearmL active. Now you add the attachment JuliaArmor/forearmL at the same slot, but never switch to this attachment at the slot, keeping the setup pose attachment JuliaNude/forearmL active of the two attachments.

A nice tool for testing such issues is opening the Skeleton Debug window (SkeletonAnimation Inspector - Advanced - Debug) and inspect all slots.

The difference to the Goblins project, and why it works out-of-the-box there, is that in the Goblins project, a skin placeholder is used at each slot.
E.g. in the goblins base skeleton.json:

"slots": [
    { "name": "left-shoulder", "bone": "left-shoulder", "attachment": "left-shoulder" },

and in the skin goblins.json file this skin placeholder is set:

"slots": [
   { "name": "left-shoulder", "bone": "left-shoulder", "attachment": "left-shoulder" },
"skins":
    ..
    "left-shoulder": {
        "left-shoulder": {
            "name": "goblin/left-shoulder",

In contrast, in your projects there seems to be no skin placeholder name used, but instead directly the default attachment name is referenced:

"slots": [
   { "name": "footR", "bone": "P_FootR", "attachment": "JuliaNude/footR" },

while in the skin .json file it is referencing JuliaArmor/footL:

"slots": [
   { "name": "footR", "bone": "P_FootR", "attachment": "JuliaArmor/footL" },
...
"skins":
    ..
    "footR": {
        "JuliaArmor/footL"

This will then not be replaced by the SetSkin() call, but will instead be added as a second attachment.

So please check whether you are using skin placeholders with the same name in both projects, then it will work without any additional code required.

dreamau wrote

but how do I get to its instance at runtime, from the SkeletonData / SkeletonDataAsset?

skeletonAnimation.SkeletonDataAsset.atlasAssets holds the array of atlas assets of the base-class type AtlasAssetBase. You can iterate over this array and cast each element to SpineAtlasAsset to access its content.

Very glad to hear you've got a working implementation already! :cooldoge:

dreamau wrote

within couple of months, or longer

Exactly that .

Thanks to this thread, I've made a solution to load texture on demand during runtime. It helps reduced texture memory usage by about 40MB (from 131 to 87 MB) in best case scenario (the character equipped few items).

There are 3 things that need to be done:

• Set all Spine Atlas's materials' Main Texture to a dummy texture (2x2 white picture).
• Know which atlas(es) each items use.
• During runtime, when an item is equipped, load the required texture and assign it to the Spine Atlas material.

PictureLoaderEditor: iterate through all the regions in Spine Atlas, get the item name from the region's name then add the atlas's name to the item's data.

SkinAtlasFinder: the editor script handles assigning all the material's Main Texture to a dummy texture so I don't have to do it by hand. The runtime script load the item's data to get the list of atlases that the item uses then load those textures and assigns it to the corresponding material.

cdr9042 Awesome, thanks very much for sharing! I'm sure your code will help a lot of users! ️