FeedMyData

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.
unknown (1).png

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

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

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
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

While I don't fully understand what you mean by "full transparency gap" and the like, I assume that the problem is most likely that the repacking code fails to read from your texture. Please have a look at whether you have Read/Write Enabled ckecked at the involved atlas textures.
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

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.
Аватара пользователя
FeedMyData
  • Сообщения: 22

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.
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.
FeedMyData писал(а):Read/write enable was indeed not activated on the texture. Activating it is sadly not solving the issue.
Did you enable Read/Write enabled at all involved textures, in case it is using multiple atlas textures to combine from?

Could you please also check if the target platform's texture settings are set to a non-compressed format? It needs to be set to uncompressed RGBA. You could post a screenshot of the texture settings (including the platform settings) if you prefer that.
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

Harald писал(а):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!
Screenshot_6.png

Harald писал(а):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)
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

FeedMyData писал(а): 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!
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).
Edit: is it best practices to always tick Read/write enabled? Or can I ignore this setting as long as everything is working fine.
For any atlas page textures that need to be combined at runtime, this is required, yes.
We already have a checklist for potential problem causes when combining skins at runtime on the spine-unity documentation pages:
spine-unity Runtime Documentation: Combining Skins
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)
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?

In general, if using Unity versions earlier than 2020.1 with the known bug, then you should make sure that any repacked textures are not resized down due to Quality Settings (half or quarter texture resolution) or via Max Size.
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

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:
Screenshot_7.png
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Аватара пользователя
FeedMyData
  • Сообщения: 22

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?

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?
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

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.
Screenshot_8.png

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.
Screenshot_9.png
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

This looks strange indeed. Could you perhaps send us a minimal Unity project that still shows the issue, as a zip package to contact@esotericsoftware.com? Then we can have a look at what's going wrong.
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

Ok, I'll try to do this next week. I keep you updated.
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

Thanks for sending the reproduction project, we received everything and could reproduce your issue. When playing the demo scene we received an error message displayed in the console window, which might most likely explain why it does not work as expected. We will get back to you once we've figured out what's going wrong.
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

Thanks for investigating and helping us!
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

This issue has just been fixed on both the 3.8 and 4.0-beta branches.

New unitypackages are available for download here as usual:
Spine Unity Download
Please let us know if this fixes the problem for you as well. Thanks again for reporting!
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

Awesome, thanks Harald!
I don't think I'll manage to try it out before next week. I keep you updated :)
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

No hurry, thanks for reporting!
Аватара пользователя
Harald

Harri
  • Сообщения: 2778

FeedMyData

Hey, we've been able to test and it seems to work fine. Thanks a bunch.
Аватара пользователя
FeedMyData
  • Сообщения: 22

Harald

Very glad to hear, thanks for getting back to us.
Аватара пользователя
Harald

Harri
  • Сообщения: 2778


Вернуться в Bugs