Bone accuracy problem when import data from JSON

qppistc

Hello，I find a problem：I have a bone position🙁228.1, -1.073) in Spine software, and then I export it as JSON.
In JSON file, the bone position is ( 228.1, -1.07 ), It lose 0.003. Then, I import data from this JSON in Spine software, the bone position is ( 228.1, -1.07 ), is different from raw position.

The core case is：Our Unity spine-runtime is 3.5，and our Spine animator work in Spine software 3.7，so they will export JSON in spine3.7 and import this JSON in spine3.5. The bone position problem will happen.

I find binary data don't have accuracy problem.But spine3.5 can't recognize 3.7's binary data.

Is there any way to solve it? Thanks a lot!

Harald

spine-unity 3.5 is rather old already. Mixing different versions of the Spine Editor and the runtime is in general not supported. While it may still work, it might lead to subtile problems. As .json export precision is limited to two fractional digits, the cleanest solution would be to upgrade the runtime to 3.7 and export the skeleton in binary format (or even better upgrade both the Spine Editor and the spine-unity runtime to 4.0). While upgrading may be a bit of work once, it should usually very well be worth the effort. Being able to use binary exports for example would highly improve loading times.

If you decide to upgrade, we have a guide for upgrading spine-unity from 3.6 to 3.7 here:
Spine-Unity 3.6 to 3.7 Upgrade Guide

qppistc

Thanks！Since this is a 3 years game and have 200+ spines，upgrade is a huge work for us( We need re-export all .spine file and some of them is out of data...

Is there any way to make JSON exact or make 3.5 recognize 3.7's binary data? Or is it possible or guide that I can analysis exact binary file and re-generate to JSON file for spine editor to import?
Anyway，Thanks a lot!

Harald wrote
spine-unity 3.5 is rather old already. Mixing different versions of the Spine Editor and the runtime is in general not supported. While it may still work, it might lead to subtile problems. As .json export precision is limited to two fractional digits, the cleanest solution would be to upgrade the runtime to 3.7 and export the skeleton in binary format (or even better upgrade both the Spine Editor and the spine-unity runtime to 4.0). While upgrading may be a bit of work once, it should usually very well be worth the effort. Being able to use binary exports for example would highly improve loading times.

If you decide to upgrade, we have a guide for upgrading spine-unity from 3.6 to 3.7 here:
Spine-Unity 3.6 to 3.7 Upgrade Guide

Thanks！Since this is a 3 years game and have 200+ spines，upgrade is a huge work for us( We need re-export all .spine file and some of them is out of data...

Harald

qppistc wrote
Since this is a 3 years game and have 200+ spines，upgrade is a huge work for us( We need re-export all .spine file and some of them is out of data...

Please note that there is also a command line interface available to automate import and export of assets. Even if you decide not to use it for the current project, you might want to consider setting it up for future projects. These forum threads might help in this regard:
Spine 3.8 released - mesh tracing, polygon packing, and more
How to automate version migration of binary assets?

Unfortuantely there will be no bugfixes/improvements released for Spine 3.5 any more.

Is there any way to make JSON exact or make 3.5 recognize 3.7's binary data? Or is it possible or guide that I can analysis exact binary file and re-generate to JSON file for spine editor to import?

While there is no guide, the source code is available for all runtime versions, so if you really want to go down that path, you could have a look at the spine-unity runtime code that loads binary skeleton assets:
https://github.com/EsotericSoftware/spine-runtimes/blob/3.7/spine-csharp/src/SkeletonBinary.cs
https://github.com/EsotericSoftware/spine-runtimes/blob/3.5/spine-csharp/src/SkeletonBinary.cs

qppistc

Thanks a lot!