• Editor
  • Spine 3.8 Export attachments atlas maintaining image folders

Related Discussions
...

As the title says, I can#t seem to find a way to export an atlas of ONLY the attached images without having them all mixed together. This happens if I select "Image Folders", but then all images are exported, even the ones that are not attached anywhere.
Suggestions/Solutions? :think:

Spine is going to export all the images you added to your project unless you uncheck the export checkmark in the attachment properties. However, if the attachment is keyed in an animation, it will still be exported.
Attachments - Spine User Guide: Settings

I have an image that is unchecked for export, and is not part of any animation. Still, if I select "Image Folders" it is exported anyway. But i also feel that's the intended behavior; on the other hand, I wish there was a third option to export only attached/keyed images keeping the folder structure, cause atm it's whether one or the other, am I wrong?


I know this is annoying, but I'm in the middle of defining our spine workflow, so I need to know if I'm missing something or if that's actually not possible so... Up 😃

When you select Image Folders it is equivalent to running the texture packer on the images folder. It does not use the Spine project or attachments in the project (except meshes for whitespace stripping), so unchecking the Export checkbox on an attachment won't prevent the image from getting picked up and put in the atlas.

You can put images you don't want in the atlas into their own folder, then create a pack.json file in that folder with the contents:

{
    ignore: true
}

That will cause all images in that folder to be ignored by the texture packer when using Image Folders or running the packer separately from data export.

Thats just a partial answer, this way I have to manually check and be sure any of the images in the "ignore" folder is linked on the skeleton I'm exporting.
This makes it prone to raise errors when exporting, especially with big and complicated setups.
I'd rather turn this card into a feature request, as I really feel this could be a feature many people would/could benefit from.

If you want to only pack images that your skeleton uses, why are you choosing Image Folders? It sounds like if you choose Attachments that it will do what you want.

Nate wrote

If you want to only pack images that your skeleton uses, why are you choosing Image Folders? It sounds like if you choose Attachments that it will do what you want.

Because Attachments doesn't retain the folder structure, and creates atlases that mix all the graphics together, as I wrote in my first post.
On the other side, Image Folders does create an atlas per folder, but it packs all the images regardless if they're attached or not.
What I'm looking for is some built-in way to do both: like an Attached Image Folders that creates an atlas for each image folder but only with the attached images among the ones in the folder.

I see, sorry I missed that point. One thing you can do is pack an atlas using Attachments, then unpack the atlas so you have a folder (and subfolders) of only the images used by attachments, then run the texture packer on that, which will use the filesystem subfolders to control how the images are grouped on the atlas pages. It's a little bit more work to do, but you can automate it using the command line interface to do the export, unpacking, and repacking. We'll consider a way to do it without the extra steps.

Nate wrote

I see, sorry I missed that point. One thing you can do is pack an atlas using Attachments, then unpack the atlas so you have a folder (and subfolders) of only the images used by attachments, then run the texture packer on that, which will use the filesystem subfolders to control how the images are grouped on the atlas pages. It's a little bit more work to do, but you can automate it using the command line interface to do the export, unpacking, and repacking. We'll consider a way to do it without the extra steps.

I see, that's a bit tricky, especially if one goes through reimporting stuff pretty often (I'm in the process of defining a workflow that will hopefully give the chance to our artists to handle the whole Spine part themselves).
Would there be a way to automate that with an external extension script, while waiting for an eventual built-in solution? 😃

Nate wrote

Yes, you can export, pack, and unpack from the command line.
Export - Spine User Guide: Command line

Is there a way to run such scripts from within Spine, similar to what happens with custom Photoshop scripts?

No, I'm afraid it has to be done from the command line or with a shell script.

I see 🙁 Please consider adding something like that in the future, as for someone who's not really used to use the terminal (e.g. the artists I'm preparing the workflow for) this is not really less tricky than doing the pack/unpack/repack thing by hand ^^"

What we did, to kinda sorta solve this, is make sure all the attachments of a single skin are in their own folder (no reusing of the same attachment) and afterwards pakc those folders separately using the command line.

7 days later
nimbling wrote

What we did, to kinda sorta solve this, is make sure all the attachments of a single skin are in their own folder (no reusing of the same attachment) and afterwards pakc those folders separately using the command line.

I'm aware of all the command line options; the thing is, I can't ask non-programmers to write things in the terminal. That's too prone to mistakes and also it's not a a good workflow. Spine already offers the two separated packing options, what I'm asking is just considering implementing a mixed one in the program GUI so no artist will risk messing up on export using weird script or worse, the terminal.

Understood. As mentioned, we will consider a way to do it without the extra steps. The workaround described above is a stopgap until then. While I also wouldn't suggest asking animators to write terminal commands, it may be acceptable for them to run a shell script that does the necessary steps for them.

However, I do believe that automating export can be beneficial in many cases. In general, it can be error prone to trust people (animators, programmers, or anyone else) to both remember to do the exports when project files change and to do all the exports with the right settings, to the right place, etc. Also, often a build is not just processing Spine projects


usually all but the simplest of applications has a fair amount of tasks that can be automated to reduce errors and save time.

We do have similar export scripts for Photoshop. The problem is not writing them, is to make them easily accessible from the program GUI; for example, Photoshop has the option to place .jsx files in the Scripts folder that then pop-up in the program GUI as menu options. A similar function in Spine could help lot of developers to automate specific processes without requiring you (ES) to consider coding them in yourself.

4 months later

How do I get the command line packer NOT to create multiple atlas based on folders?

My command is like this:
Spine -i image_folder/ -o "output_path" -n set1 -p polygon_halfsize.pack.json

There seems no way to tell the packer to ignore folders and pack everything into one big atlas. I have skin folders of characters and some common folders which contains shared images among skins. I want to use symbolic link to prepare image folders which can skip copying images every time doing the export.


Besides the single atlas issue, I got a lot of "Missing Region" warning but I already unchecked "export" for the unrelated skins. I found that the export.json seems doesn't even saved which skins should be ignored thus causing the "Missing Region" warning in unity. It try to get the attachment which should be excluded from the export.

Note folders give you one atlas with multiple atlas page images, not multiple atlases.

You can use the "combine subdirectories" setting to pack images in folders (subdirectories) into the same atlas page. If they don't fit they will spill over into subsequent pages.

When you run the texture packer on a folder of images, it just packs the images found. Unchecking Export for a skin causes that skin and its attachments to not be written in exported JSON or binary data. You can inspect the JSON and make sure that is the case. The only reason you should ever get "missing region" messages in Unity is that there are attachments in the data that don't have a matching texture region in the atlas.