It seems like you are encountering an issue with the precision of exported physics animation data from Spine to Unity, specifically with the rounding of weight values. This kind of precision issue can indeed affect how animations behave when imported into Unity. While you mentioned using your own code and needing binary export, it's important to ensure that both the Spine Editor and the spine-unity runtime versions are compatible. Since you are using Spine Runtime version 4.2, make sure that your Spine Editor is also updated to a compatible version. If the issue persists, consider reaching out to Esoteric Software directly with your project files for further investigation. You can send your project to contact@esotericsoftware.com for a more detailed examination.

Physics constraints don't have a "weight" property. Which properties are you seeing have a lack of precision?

There is some rounding to 2 or 4 decimal places for JSON, but none of the rounding is to 3 decimals places. Generally JSON should only be used if a human needs to read the data or you are using tools to process the data.

Binary exports do not have any rounding.

Thanks for the project. The 3 animations don't really show how you expect the mesh to deform. In animation this doesn't seem desirable:

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

If I run Prune with 4 bones and 0.01 weight then it deletes 72 weights and then animation seems more reasonable:

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

We need to confirm what looks correct in Spine before we can dig deeper into exports.

Thanks. This is a weird project.

The transform constraint boneaa has a translate mix of 30M to magnify the movement of bone Weight<0.0005 and apply it to bone W<0.0005, which is ~17M away from the skeleton. You then weight vertices in the slimeA test mesh to bone W<0.0005 with a tiny value.

The scale of the numbers you are using is both small and large enough to run into numerical issues with the 32-bit float data type. There is no reasonable workaround for that. Also the Spine UI is not designed for these tiny and massive values. When W<0.0005 is flying around, using Zoom to fit sends the camera off into oblivion. The weight values are so small they show up as 0 in the Weights view.

Using microscopic and astronomical scales makes it difficult to see what is going on and it's difficult to control. I don't think you need such scales to get a similar effect. Why not do the same with much smaller numbers?

We will work on improving some of the issues with using extremely small and large numbers, but it's unlikely that all can be fixed. Floating point numbers in computers have many complexities at the extremes (imprecision, compounding errors, etc) and it's almost always better to avoid huge differences in numbers. I highly suggest using more reasonable numbers, for example in the +/-500k and +/-0.0001 ranges. Just being able to see what the bones are doing will make it easier to adjust your results.

BTW, the orbiting 0 bone is really cool and could produce neat effects!

To be clear, I don't think you should use such massive numbers, which is what led you to wanting more precision. I think you can get the same effect with smaller numbers and then you would not need more precision.

If you feel you do still need additional precision, it would help if you can show a project that needs it (without also having massive numbers).

As mentioned, we will still evaluate what we can do to improve this, but I don't think it will solve all your problems in the project you provided and you probably shouldn't expect it to. It is better to not rely on the behavior of very large or very small floating point numbers across various game toolkits and operating systems.

Precision to 0.0001(4 decimal points) would be much appreciated. We usually use 4-5 decimal points because we need the precision for more realistic physics with more complex model. The currently 3 decimal points (round up to 0.001 or down to zero) in Unity is unusable

I don't believe we round to 3 decimal places anywhere. The Weights view supports 5 decimal places. If you think we do round when we shouldn't, please provide a project and explain how to see where that occurs.

If you are using JSON, use binary.

KLCL We weren’t aware the Spine Unity runtime is 32-bit. We were always under the impression that Spine was 64-bit since version 4.0? Do you think this might have caused the discrepancy within Spine and Unity Runtime?

The Spine editor is indeed 64-bit for versions >= 4.0. The 32-bit I mentioned is for the float data type, which is used by the editor, runtimes, and most game toolkits to represent floating point numbers. There are 64-bit floating point numbers but often that is not used for game toolkits, unless there are special needs.

KLCL The project was intended to as a demonstration of the discrepancy between Spine and Unity, help with reproducing the problem and identifying the potential cause.

Your initial project (exported in binary format) seems to run into numeric precision issues on all runtimes, as Skeleton Viewer also displays the same result as spine-unity. The Spine Editor seems to maintain slightly higher precision here.

KLCL We really look forward to the runtime with improvement on the small/large numbers issue. Precision to 0.0001(4 decimal points) would be much appreciated. We usually use 4-5 decimal points because we need the precision for more realistic physics with more complex model. The currently 3 decimal points (round up to 0.001 or down to zero) in Unity is unusable

Where did you see any rounding to 3 decimal points?

Nate I don't believe we round to 3 decimal places anywhere. The Weights view supports 5 decimal places. If you think we do round when we shouldn't, please provide a project and explain how to see where that occurs.

@KLCL
Nate likely meant if you could send us a project which shows a problem of rounding to e.g. 3 decimal places. Your sent project is using weight * mix of 0.0005 * 30000000 which is quite far away from 3 or even 5 decimal places after mixing.