We have an issue ticket that deals with implementing delayed (partial) loading of atlas textures:
https://github.com/EsotericSoftware/spine-runtimes/issues/1890
Unfortunately we didn't get to this ticket yet.

You have multiple options to tackle delayed loading and assignment of atlas assets or materials:

1. You could continue your workflow and disable the error by modifying the spine-unity code. Then you would need to download and assign the materials on demand.

2. You could unassign any Material references later via a custom build script (only triggered on building your executable) which unlinks references and sets up any adressable links accordingly.

3. You could also change your workflow from 1 atlas asset with N materials (each downloaded on demand) to N atlas assets (each downloaded on demand) with 1 material each. Then you should not need to modify any code regarding errors upon import.

While it addresses a slightly different goal (having multiple sparse SkeletonDataAssets and assigning a skin from one on-demand-loaded skeleton to another skeleton which is loaded from the start), this forum posting might be interesting for you in case you haven't seen it already:
Memory management of character with many outfits

pathfinder wrote

So with this option it would be valid to leave the mat array empty and modify it on demand as needed? I did a quick test on this and it worked.

Yes, it is valid to assign Textures or Materials later. The atlas description file (the .atlas.txt file) holds the names of all pages (of type AtlasPage), which are setup separately from loading Textures and Materials. In spine-unity it is the MaterialTextureLoader.Load() method overload which will link each AtlasPage to a Material, with the Material referencing a single Texture.

The Material is forwarded from page.rendererObject to a MeshGenerator.SubmeshInstruction (approximately a draw call) here. So you just need to make sure the Material is assigned at the AtlasPage before rendering the Skeleton, and that the Material has a Texture assigned.

Note that you could also swap the Material or Texture out with a tiny white placeholder Texture or placeholder Material, which will get rid of any log error messages as well. This way you could avoid modifying the spine-unity code and still remove the error log output.

pathfinder wrote

The error we are getting with this approach is that the base skeleton still knows about all skins and continues to mention that there are missing regions.
..
If up to this point this is fine, what would be the required steps to add the atlases at runtime?

I think I did not share enough of what I had in mind, sorry about that. The assumption here was to have identical atlas attachment names like "customskin/arm" in all downloadable skin atlas assets, and not know every possible skin in advance. This way you could create and deploy a single skeleton once, and then later add downloadable skins which replace the dummy customskin skeleton skin accordingly. This avoids having to re-export the base skeleton when adding skins later. If you always have all your attachments at hand anyway, and would like to generate all atlas textures at the same time as the skeleton, this would not make much sense. Then replacing Materials or Textures at Materials is an easier solution.

pathfinder wrote

Besides this, a little question about exports. Since we are using a folder structure each export png is named after the skeleton (avatar_avatar_1, avatar_avatar_2), for organization purposes, how could we map the names to the folders used for the pngs? I saw that with a post build script could be possible, but I could not find some examples to base on.

If you run the texture packer either via the Spine - Texture Packer menu or via the command line interface (instead of packing textures alongside skeleton export), you can specify the texture name. When using the Spine Command Line Interface, we use this line to specify the atlas and texture name (note that there are multiple exports combined in a single call which starts here).

So you could use a bash script to automatically setup directories and copy your images following the desired directory structure. E.g. for attachment names like "myskin/arm" you would below a top export directory "export" have a directory "myskin" where you place the attachment image "arm". Then you would run the texture packer via the command line interface on the "export" directory. Then you can continue with setup for the next atlas, export it via the CLI, and so on.

pathfinder wrote

Im investigating this approach since it should be easier to implement from what I understand.
I have been testing the barebones needed to support changing this on runtime and I have it partially working.

skeletonAnim.SkeletonDataAsset.atlasAssets = new AtlasAssetBase[1];
skeletonAnim.SkeletonDataAsset.atlasAssets[0] = atlas;
skeletonAnim.SkeletonDataAsset.Clear();
skeletonAnim.Initialize(true);

After doing this, im able to create a skin, set it and the slots and the skin renders.

I don't quite understand why you are creating an atlas asset via code here. The use case would rather be to assign an already prepared existing SpineAtlasAsset.

Apart from that you should be creating an instance of SpineAtlasAsset instead of the common base class AtlasAssetBase. Also, depending on what you are intending (editor scripting?), creating an instance of a ScriptableObject subclass should be done via ScriptableObject.CreateInstance instead of via new.

I tried accessing to this for modification but looks like the AtlasAssetBase.Materials is only readable. I could not find any way to modify at runtime this so far.

See above, you should be using SpineAtlasAsset instead of AtlasAssetBase.

If in doubt, you can always have a look at what the spine-unity source code does in the normal import scenario:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-unity/Assets/Spine/Editor/spine-unity/Editor/Utility/AssetUtility.cs#L516

I see that there is a static method to create at runtime a SkeletonDataAsset, where I need to provide the mats + the .txt. The issue I see here is that I would need to recreate each time I change any skin (because the intention is to provide only the needed materials, by changing the skin I would need others).

Could you provide some more info on how to go to continue from here?

In general I would not recommend creating an atlas asset programmatically at runtime. You should instead prepare atlas assets ahead of time and then just assign the asset reference.

The best solution would be of course just changing the materials.

Yes, this would be best, if possible.

I also saw in another post that after doing that I should call skeletonDataAsset.Clear() and then Init the skeletonAnimator.

Basically yes, but note that calling skeletonAnimation.Initialize(true) (override == true here) will reload the complete skeleton, which might be tolerable, but costs the full loading time. Only switching Material references is free in comparison.

1. 1. The skeletonJSON that comes from the export contains all the data, including the skins info.

2. 2. The skeletonData needs to have all the regions from skins referenced (via atlases). (please confirm)

All references of active attachments need to be setup so that from each RegionAttachment or MeshAttachment it links to the respective atlas array's AtlasRegion, and has its uv coords setup accordingly.

You can have a look at the NewRegionAttachment and NewMeshAttachment code here, which sets up all references needed for both attachment types:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-csharp/src/Attachments/AtlasAttachmentLoader.cs#L47
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-csharp/src/Attachments/AtlasAttachmentLoader.cs#L62
(attachment.RendererObject = region; assigns the reference from skeleton to the atlas here, together with setting up all uv and offset parameters)

You can however create a Skin separately which is not yet assigned at any skeleton. At the time you set this skin as skeletonAnimation.Skeleton.Skin = customSkin, all RegionAttachment and MeshAttachment region references and uv coords need to be setup accordingly beforehand.

[/]
[*]3. I tried exporting manually each skin, getting a more modular organization (1 atlas per skin)[/]
[*]4. Doing a material override doesnt work on this case because each skins possibility also change positions (not just a recolor).

So from this setup I think it would be a good idea to keep 1 atlas per skin, but the main issue still persists.[/*][/list]

Now I see why you don't want to switch out Materials only. Basically the regions should match up when whitespace stripping is disabled upon atlas export. When whitespace stripping is enabled, differently transparent regions of the same Attachment in two skins will end up being placed at different locations in the respective output atlas, that is correct. This only applies to RegionAttachments, MeshAttachments always use the mesh boundaries for packing, transparent areas within the mesh cannot be cut-off and used by other attachments aparently.

So, if the blocker is that the skeletonData expects to have all the skins, the only viable solution I see is changing the json and creating a skeletonData at runtime with one containing only the skins I need.

It would be something like this:

1. Export from Spine and manually remove the skins on the json (leave the skin[] empty)

2. Pack and export 1 atlas per skin, an additionally add a json that would be the skin entry (that I previously removed)

3. Get the json with the empty skins, concat each skin I need on the empty array

4. Create the skeletonData at runtime providing the modified json + array of atlases that should cover whats only needed.

This is not recommended. Instead it would be better to just assign pre-built atlas assets at the skeletonData's atlas assets array. You could then either perform a full reload of the SkeletonData via skeletonAnimation.Initialize(true), or perform only reloading of the attachments. The latter would however involve some coding I'm afraid.

Sorry for the late reply!

pathfinder wrote

To avoid getting an error that didnt recognize the white tex for the atlas, I commented the following on MaterialsTextureLoader
...
Its really dirty but I wanted to share the current steps to see if there was a way to improve this. Thanks for the help!

Thanks for pointing that out. You are right, having to comment-out these lines does is not ideal. Unfortunately the other way, creating your own MaterialsTextureLoader subclass and using it in SpineAtlasAsset.GetAtlas() would also require to either change this line where the MaterialsTextureLoader is assigned, or to also create a subclass of SpineAtlasAsset, which however again would just move the necessary code modification to another place where the respective object instantiation happens.

We will improve the API situation together with implementing the official support for delayed on-demand loading in the aforementioned issue ticket.

pathfinder wrote

Then on startup, I have as a temporary solution an array of textures (the real ones) paired with another array of strings (the names).

I loop the atlasAssets checking if I find the name im iterating. If I do I replace the primaryMaterial.mainTexture with the tex array paired index.

If I understood you right, your solution is completely legit. You either need to create a mapping of a unique texture ID (name, path, UUID) to the texture, or alternatively for each AtlasAsset create only an array of Texture references, e.g. stored at a scriptable object next to each AtlasAsset. This would work by relying on the order of textures (indices) remaining unchanged.

If you're unhappy with iterating over pairs, it could be implemented via a Dictionary, but this again causes additional work in terms of Unity's serialization.

Hello. There is more one year left and I have the same issue and i see there is still no solution?
I also tryed to change Atlass Asset with no success. And only one way is simple changing materials.

In this case you wont have a sprite atlas asset description of sprite positions.
When exporting spine randomize inner sprites position in atlas.
If its only one way a few questions.

1. How can I export cloth in spine in fixed texture position for all other clothes without tight packing or should have one example and other draw manually in photoshop?
2. You have as pattern 1px texure with large size?
3. How did you solve situation when have different clothes sizes and UV position? (small dress, big dress etc)

Warped wrote

Hello. There is more one year left and I have the same issue and i see there is still no solution?

If by that you mean that the feature is not implemented yet, then yes, there is no officially provided built-in solution available yet. You will need to write some code as described here, as I have already mentioned in my previous posting to you:
Mix and match outfits + Addressables loading issue

Warped wrote

I also tryed to change Atlass Asset with no success.

I have answered to your question here on how you can change the atlas asset at a skeleton instance:
Runtime change SpineAtlasAsset
Did you run into problems following the mentioned advice? If so, please let us know and tell us some details what you tried, then we can help you.

Warped wrote

When exporting spine randomize inner sprites position in atlas.

1. How can I export cloth in spine in fixed texture position for all other clothes without tight packing or should have one example and other draw manually in photoshop?

As I have replied on the other thread, attachment locations within the exported atlas textures are not randomized, placement is deterministic and will be exactly the same with equally sized attachments, unless e.g. whitespace stripping combined with different whitespace areas reduces their size differently. Was there anything unclear at the reply on the other thread?

Warped wrote

2. You have as pattern 1px texure with large size?

I'm afraid I don't understand this sentence. Could you please let us know what you mean by that?
Guessing what you could have meant: You could assign 1px placeholder textures and later via delayed-loading replace the 1px textures with your real textures once they are loaded.

Warped wrote

3. How did you solve situation when have different clothes sizes and UV position? (small dress, big dress etc)

I think now I understand your problem. Only RegionAttachments can be interchanged when having different sizes, if you are using a MeshAttachment, the same mesh geometry is used, then the attachment image must be of the same size, otherwise it's incorrectly mapped or might show undesired parts of the atlas. This also applies when using the code as in the Mix and Match Equip or Mix and Match example scenes, replacing single attachments.

Also, if you have different sizes of attachments, or even different types of attachments (Region attachment vs. Mesh attachment) at the same skin placeholder, then you can't simply replace textures. If you want to replace it 1:1 without both skins being part of a single exported skeleton data file (the .json or .skel.bytes file), then sizes of your attachments need to match. So e.g. when you have a large attachment (a big helmet with horns, e.g. 100x100 px) and a small attachment (a small helmet, 64x64 px), you need to use the large attachment size (100x100 px) and have a lot of whitespace (transparent area) in the small attachment.

In general the easiest way should be to export all your skins at once and then clear the references of the Material's textures, and then on-demand load them as described using Addressables, Asset Bundles, or the like.