• Unity
  • Too many material due to dynamic reload

Related Discussions
...

My project is currently using GetRemappedClone and Skin.SetAttachment to achieve dress change, because the clothing has a high degree of freedom, and the clothing needs to be updated dynamically, so the added clothing atlas needs to be compressed, so the GetRepackedSkin interface cannot be used, resulting in the number of Material at runtime Too much, is there any way to solve this problem, looking forward to your answer

Why are you using compressed textures, which prevent you from using GetRepackedSkin? If you can switch to uncompressed textures you could pack everything into a single atlas texture.

In general using GetRemappedClone is not something that we would recommend to use excessively. Instead we would recommend combining skins (also if not repacking them) as described here and having larger atlas textures exported from Spine for sets of e.g. multiple eyes, eyebrows, faces, etc. This skin API is also demonstrated in the Mix and Match Skins example scene.

Apart from that, you could arrange your draw order in a better way so that you group e.g. your eye skin texture usage, instead of having e.g. 7 draw calls for eyes and eyebrows. Please see the spine-unity documentation page section here for details.

Our skin color and facial features, including various types of clothes, can be replaced or dyed. Because there are some superimposed wear requirements, a piece of clothing may be cut into several accessories, such as the body, left sleeve, right sleeve, etc.In fact, there are already 13 atlases of 2048*2048. Due to the relatively high degree of freedom, if only the AddSkin interface is used, it will produce a lot of Skin, some skins actually only need to change the texture, and it seems that such atlas will continue to increase, so we need to choose compression, may I ask if there is a better solution, thank you


Our folder directory looks like this,Each subfolder is a set of skins.If we use folders to package atlases, we will print out many, many atlases. Is there a function that allows us to choose which folders to make into one atlas?Like all the bodies in one atlas, all t-shirts and pants in one atlas, etc.

Another question, if a spine animation itself has too many skins, such as more than 60, but the runtime will only use about 10 skins for AddSkin and combination, will the consumption be relatively large?


Harald :

Why are you using compressed textures, which prevent you from using GetRepackedSkin? If you can switch to uncompressed textures you could pack everything into a single atlas texture.

In general using GetRemappedClone is not something that we would recommend to use excessively. Instead we would recommend combining skins (also if not repacking them) as described here and having larger atlas textures exported from Spine for sets of e.g. multiple eyes, eyebrows, faces, etc. This skin API is also demonstrated in the Mix and Match Skins example scene.

Apart from that, you could arrange your draw order in a better way so that you group e.g. your eye skin texture usage, instead of having e.g. 7 draw calls for eyes and eyebrows. Please see the spine-unity documentation page section here for details.

niezhijing :

In fact, there are already 13 atlases of 2048*2048. Due to the relatively high degree of freedom, if only the AddSkin interface is used, it will produce a lot of Skin, some skins actually only need to change the texture, and it seems that such atlas will continue to increase, so we need to choose compression, may I ask if there is a better solution, thank you

There are many solutions to this, all have their advantages and disadvantages (mostly trading memory comsumption for processing time):
If you don't repack multiple skins to a single skin, you could create more smaller atlas textures. This way you could end up only using some of the textures, e.g. when you have 4 atlas textures for eyes, you only need 1 of these 4. This comes with the drawback of many additional draw calls. You then want to dynamically load textures that you currently need and have active, and unload textures that you don't need.

If you can repack multiple skins to a single texture, you could dynamically load many smaller textures as described above, and then repack them to a single atlas texture (and unloading the single input textures again). Depending on how your ratio of used vs unused textures is, this might save as much memory as texture compression.

niezhijing :

Our folder directory looks like this,Each subfolder is a set of skins.If we use folders to package atlases, we will print out many, many atlases. Is there a function that allows us to choose which folders to make into one atlas?Like all the bodies in one atlas, all t-shirts and pants in one atlas, etc.

You can pack atlas textures by folder structure. This way you can arrange your attachments how you would like them to be grouped to each atlas texture.
Please see this forum posting here for a brief overview and links to more detailed information:
Export multiple texture files

niezhijing :

Another question, if a spine animation itself has too many skins, such as more than 60, but the runtime will only use about 10 skins for AddSkin and combination, will the consumption be relatively large?

Currently unfortunately all atlas textures that are referenced by the active AtlasAsset (which is referenced by the SkeletonDataAsset) will be loaded into memory by Unity. This is because Unity always loads every asset that is directly referenced by a component in an active scene. We have planned to implement the feature of automatic delayed loading of atlas textures in this issue ticket. Unfortunately we didn't get to this ticket yet. You can see this forum thread for ways to implement such delayed loading in the meantime:
Mix and match outfits + Addressables loading issue