Thanks for the clarification. Does this problem occur with binary export?
JSON rounds positions to 2 decimal places and weights to 5. Binary rounds both to 5.
It is not common to need such small weights. Can you post or email the project file? We don't need the images.
Nate
Thank you Nate for your reply.
As mentioned on the initial post, we export in binary. The file cannot be exported properly in json.
If there’s no rounding in the export, the issue is most likely in the runtime.
We really appreciate that you accommodated our special needs. We understand the precision requirement is uncommon, yet it is essential for us.
We prefer sending the file privately via email.
An email with title “Regarding forum discussion: Bug when exporting physics animation to unity. Attn. Nate” was sent.
We hope it would be helpful in resolving the runtime issue.
Thanks for the project. The 3 animations don't really show how you expect the mesh to deform. In Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand mêmeanimation this doesn't seem desirable:
If I run Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand mêmePrune with 4 bones and 0.01 weight then it deletes 72 weights and then animation seems more reasonable:
We need to confirm what looks correct in Spine before we can dig deeper into exports.
Nate
Thank you Nate for your reply.
Apologies for the inconveniences caused. We have sent an updated file. It should behave as intended(as in my second post) now.
You can see with the precision we can achieve the jello like jiggling. The animation is more rigid when you removed the weight.
Hope this will help resolving the runtime issue.
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!
Nate
Thank you Nate for your reply.
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
On one side note, out of curiosity. 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?
This is a weird project, we can’t agree more. We are aware of the method we use are unconventional, and we really appreciate that you accommodated our special needs.
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.
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.
We already emailed you the file, as per mentioned in our post no.4
Please refer to img.2 and img.3 on our post no.2. This is what we see in Spine vs Unity.
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.
The actual problem may something else. It was just our suspicion that it might be rounding.
Can we confirm if the project is actually working as intended on your copy of Unity?
If yes, we suspect that could be something to do with our copy of Unity, or our computer.
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.
Harald
Harald, thank you for your reply.
We were just suspecting the issue was related to decimal points.
In our testing, we found any weight less than 0.0005 will not move the mesh in Unity, therefore we suspected it was likely to do with rounding (to 3 decimal points, hence the value become 0, and vice versa).
The rounding was referring to value of the weight inside the mesh, instead of weight*translation.
The file (TESTfix, just in case you got the wrong file, we initially sent an incorrect one by accident) was exaggerated to demonstrate the effect.
It’s just strange that project looks different in Spine and Unity. The difference were noticeable but not to this extent.
