Great, thanks!

Hi Harald,

Happy new year. Is this improvement still in the pipeline?

Hi,

We're currently trying to upgrade our unity project. After updating to a new Unity version, we got a prompt error thrown regarding spine:

"Skeleton data could not be loaded. Data version : 3.8.555. Required version: 4.0."

Sadly Unity is not pointing us to the problematic file.

We've upgraded from Spine 3.8 to 4.0 a while ago. We've changed the Spine unity package in consequence and reimported all our files. We never had an issue till now.
Maybe there is still one file in our project that isn't upgraded, but we don't know which one.

All our spine files in our project are in binary. In contrary of json files that we could open to read a version number, we don't know how to get this info easily with skel.bytes files. Is it even possible? (no is an ok answer ^^)

Thanks,

EDIT : We've found the guilty file, but i'm still curious to know if it's possible to get this info

May I bump this and ask if a change is still in consideration?

I did not notice the two parameters were different. Well spotted thanks!

Hi,

Today I was trying to understand why some freshly reexported spine assets in my unity project started to have alliasing.
After researching, I found out it was coming from the imported spine texture.

After thinking it came from the latest Spine version, I realized that I changed one parameter recently on my texture packing.
Instead of asking to create two textures, one with scale 1, and one with scale 0.8, I asked Spine to only create a 0.8.
I thought I would spar some processor time and disk space.

But it seems that by doing so, when exporting the texture only at 0.8, spine is having issues.
However when I check the 0.8 texture when simultaneously exported with a scale 1 texture, it looks fine.

Repro :

1. Open a spine project (v4.40)
2. Export the texture with the following settings.
   
3. Change the pack settings to only export at scale 0.8 (here come the aliasing)
4. Compare the previous 0.8 export with the new 0.8 export

Here is a comparison of the two 0.8 texture (Right Repro step 2, left Repro step 3)

Thanks. We are glad it helped

Thanks, the bit of code that I posted is solving the issue (the line 745 in red brackets).
However we are not sure that it's the best way possible. Feel free to use it, if it makes sense.

If you allow me, I'll try to reformulate the issue before sending a unity package.
In our project we have to use another shader than the one provided by spine to display our spine assets. (All in 1 sprite Shader from the unity store).
We use the override material property provided by spine on this shader. In theses conditions, if we put a spine asset in a Unity UI Canvas, under a Unity mask, the mask will not work. The spine asset will ignore the mask.

I guess you could repro the issue easily using the following steps:

1. Import a spine skeleton in a unity project
2. Change the shader of of your spine asset material
3. Use the override material property on this material
4. Import the spine skeleton in a canvas, under a gameobject with a mask
5. Observe that the spine object is ignoring the UI mask

Hi,

While investigating a bug in our project, our programmer found something that other people might find interesting. So we decided to share it here:

In our project, we have had to use the override material property provided by the SkeletonGraphic. However in doing so, we saw that UI Masks would no longer work on our UI characters with material override.

Digging into the code, we saw that using the override material, the code will go a whole other way and only provide the brut material to the submesh's CanvasRenderer instead of the default property "materialForRendering", which applies all found IMaterialModifier in the GO. Among them, there is MaskableGraphic, which is the key component that makes the Mask possible.

We don't know if such behavior was intended in the first place. So we added a small line, using submeshGraphics, to get the modified material override before sending it to the canvas renderer, this "fix" is most simplistic however because it will not take into account other IMaterialModifier that may be there.

But nevertheless it solved our Mask issue and though we would share it here, as it may (or may not) solve a discrepency in the SkeletonGraphic.

Hi,

I'm wondering if there is a simple way to do a clean crossfade when sprite swapping an attachment from the same slot. Either within spine or within the unity runtimes?
What I mean is fading out the discarded attachment, and fading in the new attachment at the same time (So they reach an alpha value of 50% at the same time kinda).

Thanks for your answer,

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

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

Thanks for investigating and helping us!

Ok, I'll try to do this next week. I keep you updated.

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.

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: