Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

[4.2.43] Atlas Assets list in SkeletonData usage

AlejMC

Hello! The short question is: is there a way to make Atlas Assets resolve the texture it's going to use from "top to bottom", meaning try to use the atlas asset on top and if it can't resolve one specific skin there go to the next as a fallback?

Our use case is the following:

We have one big Spine file with all skins (basically all our characters, enemies, npcs, and everything that share the same bone structure are in that main file + then some more as character sizes sizes are just stacked 'bones' animations)
Every time we export and pack from spine it gets large and long and overwrites too much on the Unity side (overrides texture names, uses 'default' namings usually the Spine's file name, etc)

So we have started to use CLI tools, they work great, that way we can pack new textures to new folders and just allow artists to work completely separate on their photoshop files, run PSD jsx export scripts from there while a technical artist can run packer routines by calling Spine runtime in batch mode on pack said new folders.
This last step creates a 'packed' atlased textures with the corresponding .atlas.txt files. So far so good.

Importing this file in Unity properly detects the regions and creates the corresponding material.

Now here is the part where we got stuck... original spine at some point was exported with the packing option, per folder mode, so it has some of the atlases on its default atlas.txt files, however we would like to use that only as a fallback and start using the 'separate' atlases that the spine runtime routine can create.
In our current case the spine file picks atlas region bounds that seem outdated or wrong, definitely not respecting the material that we are assigning on the new one either because removing a corresponding material found on the 'default/fallback' atlas asset it turns pink even though it properly exists on the 'added on top' atlas asset.

Does that make sense and is it even possible? Can the Atlas Asset list be used like this?

Thanks a lot in advance, great tool, our latest games are using it to our best understanding.

Misaki

AlejMC Our Unity expert, Harald, is currently on vacation, but I believe he will respond as soon as he returns, so I would appreciate it if you could wait for a detailed response.

Harald

AlejMC Now here is the part where we got stuck... original spine at some point was exported with the packing option, per folder mode, so it has some of the atlases on its default atlas.txt files, however we would like to use that only as a fallback and start using the 'separate' atlases that the spine runtime routine can create.

Unfortunately I'm not quite sure I understand why you want to "use that as a fallback" if you have CLI export scripts in place, could you please describe that part in more detail what you have in mind? In general you would normally export using your atlas export CLI scripts and arrange everything as desired, then assign the atlas assets at the SkeletonDataAsset under Atlas Assets, in the desired order.

If you want to avoid manual assignment, You could create a custom SkeletonDataModifierAsset and sort the assigned AtlasAssets as needed.

AlejMC In our current case the spine file picks atlas region bounds that seem outdated or wrong [..]

If you get wrong outdated atlas regions, this sounds as if the .atlas.txt file does not fit the atlas .png textures, like a partial commit e.g. only updating the .png files.

[..] definitely not respecting the material that we are assigning on the new one either [..]

In general you should never assign an atlas texture at a Material, these are automatically assigned upon import. This sounds like a potential source of error (which would explain incorrect regions used) if you accidentally assign an atlas page texture at the wrong material (like assigning texture with "2" in the name at material "1"). At the AtlasAsset, it's crucial that the material order is also not set to anything other than the ascending order.

[..] because removing a corresponding material found on the 'default/fallback' atlas asset it turns pink even though it properly exists on the 'added on top' atlas asset.

The AtlasAssets are just queried in order (atlas asset at Element 0 before Element 1, and so on) for the required region, in the .atlas.txt file has the required region, the material at the respective index is simply assigned. If you assign null at the respective Material element, null is assigned at the MeshRenderer for the respective submesh, which is not what you want.

Spinebot

When multiple Atlas Assets are assigned to a SkeletonData asset, the spine-unity runtime searches through them in the order they are listed to resolve regions. However, there is no built-in "fallback" priority system where it tries the first atlas, and if a region isn't found there, falls through to the next. Instead, all atlases are searched and the first match found wins — so if a region name exists in more than one atlas, the one listed first takes precedence.

The missing-region / pink material issue you're describing is most likely a path/name mismatch between what your skeleton data file expects and what the .atlas.txt file actually contains. As noted regarding this kind of setup:

If you get missing regions, it's likely the paths which are incorrect due to different top- and subdirectories used, like the .atlas.txt file containing subdir/image1 while the skeleton data file requires topdir/subdir/image1 (or the other way round). You would need to check what your .atlas.txt file contains by opening it in a text editor.

So the first thing to do is open both .atlas.txt files in a text editor and compare the region names listed there against what the skeleton data file actually references. If your CLI-packed atlas uses different subdirectory prefixes than the original export, the runtime won't be able to match them even if the image content is identical.

A few practical suggestions for your workflow:

Check region name prefixes carefully. When using Spine's CLI packer, make sure the input directory structure produces region names that exactly match what was baked into the skeleton's .json/.skel file at export time.
Put the more specific / newer atlas first in the Atlas Assets list on the SkeletonData asset, so its regions take priority over the fallback default atlas.
Remove regions from the fallback atlas that are now covered by the new atlas, to avoid ambiguity and stale UV data being picked up from the old atlas.
Use the Spine export CLI's --atlasSubdirectory or equivalent flags to control the path prefix embedded in the .atlas.txt, ensuring it matches what the skeleton file expects.

If after verifying the region names everything looks correct but you're still getting pink attachments, it may help to fully delete and reimport the affected atlas assets in Unity so that no stale cached material/texture references remain.