I think he also means only packing one skin.

That can be useful for DLC, or setups where assets are streamed (like what Apple requires now apparently, for overly large app sizes).

To answer the question of packing, there's no way to do this in Spine automatically yet.
You have to move the parts of each skin into their own folder and use the Texture Packer to pack that folder. And do this for every folder.

If you do, you can just use the Texture Packer Spine>TexturePacker and select your specific skin folder of images

On the JSON side, it's just text though.
You can post-process out the skins from the json and split them up into various files you can parse yourself. The skin structure is pretty easy to parse. It's just a dictionary/map/hashmap of strings and Attachments.

For a workaround right now (and do be careful), just delete all the other skins except the one you want, before exporting.
Or if you're not exporting that frequently, just delete the extra skins in the json by hand with notepad or something. It'll work just fine. Make sure you export with pretty-print enabled if you're just using Notepad or you won't have any idea what you're deleting. Or use a json editor.

If you accidentally save a version of your .spine file where you deleted the other skins, Spine actually saves backups of your project in your user folder. But I recommend saving your own backup .spine file anyway.

Just out of curiosity, how long is "FOREVER"? Like a few seconds? More than 2 seconds? 5 seconds? 10?

That's pretty long time to parse just one skeleton.

Christian24 wrote

Yes it is, but it is also big. It is a Spine asset pack, so a slowdown is exptected. And I don't have time to investigate

Are you sure you're not writing out the atlas every time our biggest atlas takes 2 mins (?) to export

Would you have time to add a feature to the command-line tool to export just one skin or export one atlas per skin?

If not, how do you recommend that I automate exporting just one skin?

The artists that I collaborate with want to export one skin so that we do not reserve memory for the unused skins. The artists asked me to fully automate their steps. The command line tool appears to automate many steps, except deleting a skin.

I tried using Texture Packer to export one skin atlas per folder. While that separates the atlases, because the skeleton data references all of the skins, all of the atlases are loaded into memory. If there is a way to prevent loading the unused skin atlas textures, I could work with this.

I tried exporting JSON, deleting the unused skins in the JSON, then converting to binary, but my in my naive attempt, the binary conversion posted warnings about missing images. We use the binary format for speedy loading. I imagine I could edit the JSON and the atlas to prevent unused skins from being referenced. Though for all this effort, it feels like having an export one skin option would be lower maintenance.

@ethankennerly, there are a couple ways this could be done. I'll assume you don't mind that the skeleton data contains information for all the skins. While loading ALL images for all attachments can easily be a problem if there are many, having all the skeleton data is likely not a problem (especially with the binary format). It's possible to break up a skeleton into smaller chunks, but it is likely more work and complication than it is worth.

1) You could write a script that copies only the images you want to pack to another folder, then pack that folder. Usually skin images are kept in a subfolder containing just the images for that skin, so this may be easy to do. At runtime you would have code that choose the right atlas to load.

2) If skins are kept in subfolders, you could pack the whole atlas as normal, letting each skin folder get packed to a different atlas page image. At runtime, you would customize loading the texture atlas, skipping loading atlas page images that aren't needed for a particular game state/level/etc.

Probably the first one is simplest. Note you will have skeleton data that you haven't loaded images for. By default, AtlasAttachmentLoader will fail if it can't find a texture region for a region or mesh attachment, eg:
spine-runtimes/AtlasAttachmentLoader.java at 3.6
You can create your own attachment loader (eg copy/paste AtlasAttachmentLoader, then modify it) and just not set the region if it can't be found in the skin. Attachments that don't have a region set can't be rendered of course.

@Nate What problems do you anticipate from a script that replaces the undesired skin's images with a transparent 1-pixel image?

In a test, that worked. Due to no customization of loading code, I anticipate less maintenance cost.

It seems a bit of a hack. Why not just go with my option #1? Your script copies the files you want packed to a folder, packs them.

spine -i Folder_with_skin_textures -o Folder_to_put_generated_atlas -n name_of_atlas -p texture_export_settings.json

Hi, I'm also having this case now, my client ask for multiple skeletons, each have 1 skin only (and I was looking for a way to replace the default skin but still not found it yet). It seems like they want to replace an existing project/game without any modifying so the file must match their previous version's files.

Also, Is there a way to pack all shared assets into 1 image and each skin into each separate image?