Thanks again for the help! Here is a little update.
Harald a écrit
Yes, it is valid to assign Textures or Materials later. The atlas description file (the
.atlas.txt file) holds the names of all pages, 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.
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;
skeletonAnim.SkeletonDataAsset.atlasAssets = atlas;
After doing this, im able to create a skin, set it and the slots and the skin renders.
The issue that im still having is that the atlas that im assigning still has all the materials included.
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.
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? The best solution would be of course just changing the materials.
I also saw in another post that after doing that I should call skeletonDataAsset.Clear() and then Init the skeletonAnimator.
I have been testing since my previous answer, here is some more info.
- 1. The skeletonJSON that comes from the export contains all the data, including the skins info.
- 2. The skeletonData needs to have all the regions from skins referenced (via atlases). (please confirm)
- 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.
With our current mix and match, we have 5 customizable sections of our character. Each section has different skins (mouth_0, _1 _2 / costume_0 , _!, _2 / etc).
The skeletonData requires to have all regions covered, meaning that I need to have the atlas array containing all possibilities per each section at the same time (instead of only 1 per section, as it should be).
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 however brings the following questions:
- While this solves the modular / addressable issue, is it viable in terms of performance? Each user input where I need to change any of the skin sections means redoing the steps above.
- This is also going to reset everything (animations, etc)
- I suppose that I can preload some atlases in groups to avoid reloading each time, but still sounds like an issue.
What would be the best approach to take from here?
Is it possible to make a skeletonData work without loading each of the regions (like on the pic)?