@[محذوف]

Could you please describe exactly what you did, and where this exception or error occurred? Could you share some screenshots of the Texture and Sprite import settings?

So actual image size of the green foot is 231x207. But in atlas it shows 263x263. So I simply opened 231x207 and added transparency on all 4 sides to make 263X263. Now there 2 cases from here,

1. If I add transparency and load image from the Resources then it works perfectly.
2. If I add transparency to the image. Make it 263x263 and now I try to load it through the persistence data path then it throws below error.

Graphics.CopyTexture called with negative source coordinate (x on cpu 0 , on gpu 0 ; y on cpu -53, on gpu 0) .
UnityEngine.Graphics:CopyTexture(Texture, Int32, Int32, Int32, Int32, Int32, Int32, Texture, Int32, Int32, Int32, Int32)
Spine.Unity.AttachmentTools.AtlasUtilities:CopyTexture(Texture2D, Rect, Texture2D) (at Assets/Spine/Runtime/spine-unity/Utility/AtlasUtilities.cs:601)
Spine.Unity.AttachmentTools.AtlasUtilities:ToTexture(AtlasRegion, TextureFormat, Boolean, Int32, Boolean, Boolean) (at Assets/Spine/Runtime/spine-unity/Utility/AtlasUtilities.cs:543)
Spine.Unity.AttachmentTools.AtlasUtilities:GetRepackedSkin(Skin, String, Shader, Material&, Texture2D&, Int32, Int32, TextureFormat, Boolean, Material, Boolean, Boolean, Int32[], Texture2D[], TextureFormat[], Boolean[]) (at Assets/Spine/Runtime/spine-unity/Utility/AtlasUtilities.cs:417)
Spine.Unity.AttachmentTools.AtlasUtilities:GetRepackedSkin(Skin, String, Material, Material&, Texture2D&, Int32, Int32, TextureFormat, Boolean, Boolean, Boolean, Int32[], Texture2D[], TextureFormat[], Boolean[]) (at Assets/Spine/Runtime/spine-unity/Utility/AtlasUtilities.cs:354)
<Start>d__10:MoveNext() (at Assets/Texture Change Test/ChangeCharacter.cs:87)
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

Should I send another project in which I load images from persistent data path? That is actually what I want to do. I dont want to load it from Resources. I thought loading it from Resources will reproduce same scenario. Apologies for wasting some time.

Let me know if I need to send you another project which loads images from persistent data path or not.

Thanks for posting the additional info.

parth16parikh wrote

Let me know if I need to send you another project which loads images from persistent data path or not.

Yes, please send us a Unity project using your desired persistent data path setup. Please keep it as minimal as possible, e.g. replace only the single problematic attachment instead of replacing 7 attachments where the 5th one fails. This saves us a lot of time.

Please also send us your Spine project, so that we can try to reproduce why the image is padded from 231x207 to 263x263.

Hi @Harald,

I tried somethings and found solution ultimately.

So we were trying to replace total 8 images in the character. 4 of them were attached to Mesh Attachment and 4 of them were attached to Image Attachment.

So for 4 images which are attached to Mesh Attachment needs following requirement,

1. Image loaded from the persistent data path has to match atlas.txt size.
2. After loading texture, Sprite which is created runtime needs to be Full Rect Mesh Type.

after that it worked perfectly for Mesh Attachments.

So for 4 images which are attached to Image Attachment needs following requirement,

1. Image loaded from persistent data path has to match the original size of the image. It should not be the size which is defined in atlas.txt.
2. After loading texture, Sprite which is created runtime needs to be Full Rect Mesh Type.

I can send you this project which is working completely if you want.

I wanted to ask performance impact of changing and repacking images runtime. How heavy it is? Once it is done, does it affect animation?

Thanks for the additional info.

parth16parikh wrote

So for 4 images which are attached to Mesh Attachment needs following requirement,

1. Image loaded from the persistent data path has to match atlas.txt size.
2. After loading texture, Sprite which is created runtime needs to be Full Rect Mesh Type.

Admittedly, this current behaviour is rather unintuitive. We will have a look if we can provide either an additional method parameter or change default behaviour in spine-unity 4.0 and newer versions to compensate whitespace stripping on MeshAttachments as well.

parth16parikh wrote

I can send you this project which is working completely if you want.

Thanks for offering, currently we don't need it. We will let you know when we require a test project if we cannot reproduce the described behaviour.

parth16parikh wrote

I wanted to ask performance impact of changing and repacking images runtime. How heavy it is? Once it is done, does it affect animation?

Repacking skins is a very costly operation performance wise, as uploading a texture to the GPU is an expensive operation. If possible, you should always perform any repacking at non-crucial times (e.g. when already loading a level, or when inside a character customization menu). It will however save you some drawcalls, so if can move it to non-crucial moments of gameplay, it's most likely well worth the cost. We cannot provide any precise values, as this heavily depends on your scene and character setup and on the target platform. If your character setup does not require many drawcalls before repacking, you might as well be better off not repacking the skins at all.

Harald wrote

Admittedly, this current behaviour is rather unintuitive. We will have a look if we can provide either an additional method parameter or change default behaviour in spine-unity 4.0 and newer versions to compensate whitespace stripping on MeshAttachments as well.

I just had a look at your previous reproduction project again, the problem here is that the .atlas.txt file states size 263x263 for both size and original size ("orig" in the file), not stating the proper original size as you said is 231x207. As requested before, could you please now send us your problematic Spine project (not the Unity project) where the actual image size of the green foot is 231x207 and in the output atlas it becomes 263x263?

@Harald I have sent you spine file from e-mail.

It seems like you are correct. Original file has to be 263X263. Artist might be in some confusion. I am also going to verify it now.

parth16parikh wrote

@Harald I have sent you spine file from e-mail.

Unfortunately we did not receive your email this time (I've also checked the Spam folder).

parth16parikh wrote

It seems like you are correct. Original file has to be 263X263. Artist might be in some confusion. I am also going to verify it now.

Thanks for the info, that's good to hear.

@Harald, someone replied to the the email. His name is Mario.

Thanks for the info, now I found your email.

Thanks for sending the .spine file, unfortunately the image assets (which were the important part) are not included. Could you please send the complete Spine project including the input images, so everything that's required to export a valid skeleton again?

A (potential) bugfix has just been pushed to the 4.1-beta branch, see issue ticket discussion here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1884
A new 4.1 unitypackage will be released soon.