Hi,

Spine-unity runtime version: 3.8.2020.08.31
Spine: 3.8.99

I don't know if what I will describe is a bug or if it's by design (or if it's a known issue).
In our project, we have characters with differents skins that we match and repack at runtime.
We are encountering an when Spine is repacking a skin / image that has a "full transparency gap". The game is enable to display the image.

Here what I mean by " full transparency gap", the image below is on a single png and Spine Slot, but it's visually made of two elements that are separated by a blank space.

At runtime, after repacking, instead of displaying the image properly, it only shows a white image with transparency filling the image mesh:

Looking at the material at runtime, the image is missing (it's supposed to be the white rectangle):

If we don't use the repack, the image will be displayed correctly.
I know I could simply divide the image in two and put it in two slots within Ppine, but I wanted to ask first if it is the normal repack behavior.

Thanks

Thanks for your answer Harald.
What I mean by a "full transparency gap" is that as you can see on the image, there is a big empty area that separate two elements on the texture. My guess is that the repack is unable to slice the image correctly due to that.

Read/write enable was indeed not activated on the texture. Activating it is sadly not solving the issue.

Harald escribió

Could you please also check if the target platform's texture settings are set to a non-compressed format?

Great guess regarding compression. The compression settings were not uniform for all the repacked texture. The legs texture had a max size of 2048 when all the others had a max size of 4096. Putting the same setting everywhere fixed the issue. My bad, thanks!

Harald escribió

The image that you posted is the result combined image, nothing needs to be "sliced" there, it just maps this texture to vertices, mapping gray area to the legs unfortunately. It looks just as if reading from the source texture failed that should end up in the gray rectangle area.

Alright I understand.

Edit: is it best practices to always tick Read/write enabled? Or can I ignore this setting as long as everything is working fine.
Edit2: after making a unity build with and without read/write enabled, I have the answer to my questions. Yes it is mandatory to tick read/write enabled.

On a similar topic, we are not using rotation when exporting textures from spine. When we repack them in Unity, we sometimes have images that are cropped. Is it a known limitation or are we messing up something this time too? (I can open a new topic if you prefer)

Glad to hear you've figured it out! Do you mean that the original file size is 4096 and it was set to Max Size 2048?
If so, then this would most likely be due to this known bug in Unity. The ticket says it's fixed in 2020.1 (in March last year I received a mail claiming it's fixed in 2020.2, so at least there it should be).

I thought the issue was coming from having inconsistent max size resolution (1 texture being repacked had a different max size than the others). But I tested again after reading your comment and you are right: using Quality Settings to lower the texture size is creating the bug, even if the max size are consistent. It's good to know it has been fixed in a later Unity version (We are using 2020.1.0f1 at the moment and in the bug post they are saying it's fixed in 2020.2.0a6).

Regarding the cropped images, do you receive half or quarter sections (in contrast to arbitrarily cropped sections)? If so, then this should be due to the above bug with half or quarter resolution texture settings (either in Quality Settings, then check out the active quality tier, or via max texture resolution). Could you please check these settings as well? If not, could you please post a screenshot showing the cropped image?

I used the same character and this time exported its texture with "rotation" enabled. Without using the repack, everything is working fine. Now using the repack, there is something I never saw... one texture element is combining the two issues: it is cropped and its also not appearing. The absolute dimension of the texture is 876x1027 and it's max size is set to 4096 (increasing it does not change anything). See screenshot below:

Thanks for following up Harald.

Is the region gray in the resulting packed texture? Could you please post a screenshot of the resulting packed texture as well as the source texture?

What is weird is that the face region is inside the texture and displayed properly, yet there is a a grey area somewhere else. Also, by looking at the texture, I noticed that many arms regions were weird. I tried displaying some and they are randomly cut too. But just by looking at the repacked texture as a whole one can see that something is odd.

Maybe the non-power-of-two is causing problems here, although the Texture Import settings look correct. Could you test what happens when you enable "Power of two" in the Spine export settings?

Ticking "power of 2" at export is solving the grey area issue and actually showing that the face region is duplicated on the texture. But as you can see there is still some random cuts. I checked my exported texture and the face region is not appearing twice there.

Thanks for investigating and helping us!

Awesome, thanks Harald!
I don't think I'll manage to try it out before next week. I keep you updated

Hey, we've been able to test and it seems to work fine. Thanks a bunch.