Nate

Thank you Nate for your timely reply.

Apologies for the confusion. The "weight of physics constraints" is just a regular bone we attached on the mesh with a small weight. The bone is manipulated by a physics constraint, which applies physics to the mesh.

From our testing, the small weight value (4-5 decimal points) on the physics constraint bone, will get round off to zero/up to 3 decimal points in the Unity Spine runtime, therefore the mesh and animations are not behaving the same as within Spine.
We tested on Spine runtime 4.2 on both Unity 2023.2.0b8 and Unity 6, both exhibited the same issue.

The following is an example.
This is a slime in our project, the mesh is attached to the "physical constraint bone" with a very small weight.

img.1
We treaked the slime’s weight for demonstration.
All weight value on the left side of the slime is greater 0.0005, the right side is less then 0.0005. This is what idle looks like with physical constraint off.

img.2
This is what idle looks like if we turn on the physics constraint. You can see both sides bulged down, working as intended in Spine.

img.3
This is our slime with physics constraint activated in Unity. The right side (weight less than 0.0005) doesn’t work at all, and no different to the idle slime.
The left side (weight greater than 0.0005) works to some extent, but clearly different from who it behaved in Spine. The mesh becomes deformed and jagged.

The effect is more obvious in animation

img.4
This is a jumping slime animation with physics constraint activated, working as intended within Spine.

img.5
This is the same animation in Unity. As you can see the right side didn’t move and not affected by the physics constraints. The left side is significantly different from what it looked like in Spine. It became more deformed and jagged then idle.

Then we tested moving the bone manually without the physical constant on.

img.6
The slime with bones manually dragged, both side work as intended within Spine.

img.7
The slime with bones manually dragged, in Unity. The right side (weight less than 0.0005) didn’t move and mesh seem not affect by the drag. The left side (weight greater than 0.0005) moved but no where close to what it looked in Spine, becoming significantly deformed and jagged.

Again thank you very much for your reply. We sincerely hope the runtime issue will be resolved soon.

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.

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.

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.

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.

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.