Thanks, Pharan.
I applied the changes today and I haven't seen any issues yet. Good job! I'm still not sure if it's possible to compress our Spine textures as PVRTC 4x4 and repack, but that's less of an issue
I've been keeping the repackable textures at RGBA32 and since there are fewer of them than those that shouldn't be repacked (i.e., they only have a single texture atlas anyway so repacking is unncessary), it's not that big of a deal to keep them uncompressed. Just wondered if you'd taken a look at that.
An update on this.
It seems as though this method is generating a lot of orphan Texture2D data that I can't seem to get rid of. Here's the memory profiling output in Unity on initial load (you can see there are already orphan Texture2Ds like swing3 and SkillArrow2):
However, after updating the texture in-place a few times (randomly customizing the character's skin), here's the output:
I've managed to make sure the "repacked" texture is destroyed every time I customize the character by setting the Material.mainTexture to null (from the previous version's output from calling GetRepackedSkin()) and then calling UnityEngine.Object.DestroyImmediate on the previously generated Texture2D. I even explicitly call the garbage collector, but the sprites used to generate the "repacked" texture stick around and eventually cause my game to use too much memory on-device. Here's my code:
if(this.rigGO.GetComponent<MeshRenderer>().sharedMaterials.Length > 1)
{
UnityEngine.Material runtimeMaterial;
Texture2D runtimeAtlas;
newSkin = newSkin.GetRepackedSkin("repacked", rigShader, out runtimeMaterial, out runtimeAtlas, 2048);
if(this.characterView != null)
{
if(this.characterView.DebugMaterial != null)
{
this.characterView.DebugMaterial.mainTexture = null;
UnityEngine.Object.DestroyImmediate(this.characterView.DebugTexture);
GC.Collect();
}
this.characterView.DebugMaterial = runtimeMaterial;
this.characterView.DebugTexture = runtimeAtlas;
}
}
Any ideas?
Sorry for the update on the update, but it seems as though if I add these lines to AttachmentTools.cs inside GetRepackedSkin just after the call to newTexture.PackTextures, the temporary skin sprite orphans go away:
for(var i = 0; i < texturesToPack.Count; i++)
{
UnityEngine.Object.Destroy(texturesToPack[i]);
}
However, now I'm realizing that sometimes when I call into GetRepackedSkin on an already repacked skin, I lose the benefits of repacking entirely. It very well may be something we're doing, but Spine ends up re-adding all the source texture atlases as materials onto my rig GameObject on top of the repacked texture, like so:
The materials section of my rig looks like this: