• Unity
  • 3.8 to 4.1 replacing SkeletonData question

Related Discussions
...

So I'm upgrading from 3.8 to 4.1 and I'm following the guide for the upgrade from 3.8 to 4.0. In it one of the steps is to replace the 3.8 skeleton assets with the 4.0 ones.

"6. Replace the old exported 3.8 skeleton assets with their re-exported 4.0 counterparts. Do not remove any .meta files."

By skeleton assets I assume it means skeletonData? Maybe it does just mean JSON and I'm worrying about nothing, but obviously before importing the data we don't have skeletonData yet. Also "assets" plural has me worried as well. W/o packing a new texture atlas we only end up w/ one file when exporting (json), and based on the way the rest of the guide is phrased I assumed we didn't want to or have to pack a fresh texture.

I've exported all new json files for 4.1 and was ready to replace that but wanted to make sure this was the actual intended action I should be taking before committing to it (I assume it would update the skeletonData to have the correct json when reopening and updating to 4.1).

Any help on this would be greatly appreciated as I don't want to screw this up haha. Thanks!

By "exported skeleton assets" we basically mean all assets that are created when you export your skeleton from Spine as Data in either Binary or JSON form, including any exported atlas assets (which could be exported separately). We don't mean the assets that are generated and updated by Unity, which are the _SkeletonData, _Atlas and _Material assets (these are updated from the exported assets automatically).

When you are upgrading from 3.8 to 4.1, unless you are using new attachment-related features such as image sequences, you should be good with only re-exporting the .json (or .skel.bytes) files, and using the 3.8 atlases as-is, since the 3.8 atlas format is still compatible. We would however always recommend to automate your export via the Spine command line interface, as also mentioned here, and then re-export your atlas assets as well in one go. This way you are always up-to-date and on the safe side.

Perfect, thanks a bunch Harald 😃


So I ended up w/ a lot of errors, and I know my way around solving some of them, but I have no idea what's going on with these errors regarding meshGenerator out of index w/ skeletonGraphics. Any advice on how to approach this?

SoulKarl wrote

So I ended up w/ a lot of errors, and I know my way around solving some of them

What other errors did you receive?

SoulKarl wrote

but I have no idea what's going on with these errors regarding meshGenerator out of index w/ skeletonGraphics. Any advice on how to approach this?

I assume that you're using the latest spine-unity 4.1 runtime package from the download page, right?

When do you receive this error message? E.g. when opening a scene, only when selecting the SkeletonGraphic GameObject in the scene (displaying the Inspector), when entering play mode, when selecting the SkeletonData asset in the project panel, etc. Could you please share the stack trace of the top-most error message (the full error message), only having a truncated line is unfortunately too vague to be able to offer any help.

Harald wrote

What other errors did you receive?

Fairly certain I've handled all errors but this one, and they were all basically my own fault w/ exporting spine files that had been slightly changed which caused an issue w/ the atlas. Just repacked the ones that had errors and fixed all that.

Harald wrote

I assume that you're using the latest spine-unity 4.1 runtime package from the download page, right?

When do you receive this error message?

Yup using latest 4.1 runtime. This error message pops up nonstop while any scene is open with a skeletongraphic in it (don't need to be highlighting them to cause this). This is actually the reason there are so many errors. (EDIT: actually, the error trigger appears to be anytime you click ANY object in the scene, not nonstop - pushes the same error for every instance of a skeletongraphic in said scene).

It's also worth noting that during play there doesn't actually seem to be any issues present. Which is to say all the skeletonGraphic animations work just fine.

Harald wrote

Could you please share the stack trace of the top-most error message (the full error message), only having a truncated line is unfortunately too vague to be able to offer any help.

Sure here is a full error message and the lines it takes me to.





the first 3 images of code are from SkeletonGraphic.cs and the last one is from CanvasUpdateRegistery.cs

Thanks for all your help Harald!

So it may be worth noting that none of my skeletonGraphics have skins. Could this be part of the problem? Also if this is not a common bug could it be caused by only importing a new JSON but not a new atlas? Would I be able to remedy this at least on my end by simply reimporting all my skeletongraphic assets?


Been testing it more and it seems to be caused by having an animation set in the "Starting Animation" field on SkeletonGraphic.cs. Swapping it to <None> removes the error, so that may help in solving what's causing it.


So more testing:
1) while changing the animation to <None> worked on one file it appears to have only worked because it was not on <None> prior to the update??? Changing anything that started on something else to <None> stopped the errors. However for the one file I had set to <None> to begin with, changing it to anything else is what fixed it (and <None> will continue to push the error).

2) a fresh export does not fix the issue. (this is odd considering the first point. You would think that if changing the start animation fixes the issue for pre-existing files, a fresh file would be good to go out the box???)

Thanks for sharing your insights. In general the problem is (or hopefully was) related to update method order (OnValidate vs. LateUpdate vs. Rebuild) after Inspector property modifications.

We have pushed another fix to the 4.1 branch, a new 4.1 spine-unity package has just been released. It's available for download here as usual:
spine-unity Download
Please let us know if this fixes the problems on your end as well.

Thanks again for reporting!

Thanks Harald!

Quick question before I go ahead with this, but what method should I use for updating to a newer runtime of 4.1 (starting from the prior most recent 4.1). Should I delete all of the spine folder again similar to upgrade from 3.8->4.1 or should I just run the package update on top of what already exists? Thanks again!

The bugfix commit only modified a single existing file, so you should just need to update the existing 4.1 runtime via package update.