We've fixed this in 4.2.10-beta! It is correct at runtime.

Nate
@Harald

No gravity still happening in 4.2.14-beta and 4.2.15-beta editor and spine-unity-4.2-2024-02-15-beta

vs Unity

minimum test case with 2 bones, 1 with and 1 without a physics constraint with gravity at 100, brand new spine made with latest beta editor

vs unity in play mode showing no gravity (brand new empty project), just using a Skeleton Animation dragged into scene

Sent this test project along with the test spine to the contact mail. Please take a look.

@bantam Sorry for the troubles, thanks for sending the reproduction project, we received everything. We will get back to you here on the forum once we've figured out what's going wrong.

We've fixed this in 4.2.24-beta by adding a reference scale field to skeletons. It's fixed in spine-libgdx and will be ported to spine-unity and the other runtimes soon, likely Monday (tomorrow).

Thanks for your help identifying this issue!

@bantam We've just published the bugfix of the above issue for the spine-unity 4.2-beta runtime as well (and spine-csharp in general).

A new spine-unity 4.2-beta unitypackage is available for download here as usual:
https://esotericsoftware.com/spine-unity-download#spine-unity-4.2-beta
Thanks for reporting this issue!

I gave it a test with the latest editor and package and gravity works now!! Thank you! This is such a great feature sincerely.

I noticed one issue, I think the issue is in editor not unity. Take the physics bone from last spine, nested split it into 4 bones, give it a quick mesh and weight it like normal and apply physics constraint to every bone with default settings and 100 gravity. In editor it curls around ignoring gravity or like it's doing something related to the parent bone.

(can't seem to upload images to the forum so I will put them on dropbox)

In unity I feel it does what you expect coming to a natural rest to gravity

I've put the images demonstrating this along the new test spine with the mesh and bones to test this issue in the dropbox link also in case it helps!

https://www.dropbox.com/scl/fo/b6yctecqdac6no38hqnzi/h?rlkey=g2jytges7qjfw1ge4u7z9vnpe&dl=0

Thanks for the project file. I tried this in 4.2.25-beta:

1. Export to JSON.
2. Import Data, 0.1 scale.

The result is correct:

The imported skeleton has the expected reference scale of 10 (normally 100).

If I checked the wrong thing, please let me know what are the reproduction steps!

We'll look into the forum not allowing uploads, I see it too.

Nate

Thanks for responding. The issue is that spine editor and Unity implement this differently. 100 gravity on all 4 bones in unity flops down towards gravity in an expected way (check the Unity png in the dropbox link). In the editor it curls away from gravity. If it's correct in editor then it really needs to behave the same way in Unity so animators can rely on it working reasonably similar to how it behaves in editor. Otherwise they will have to load up unity every time to adjust the gravity to look right which in my experience they are most averse to leaving editor.

I added Flop Difference Unity.zip to the dropbox so you can see the gravity difference in Unity
Assets/Scenes/test.unity

https://www.dropbox.com/scl/fo/b6yctecqdac6no38hqnzi/h?rlkey=g2jytges7qjfw1ge4u7z9vnpe&dl=0

I see what you mean now. In the editor the constraint order is 2d, 2c, 2b, 2 (from the top down):

图像因不支持 HTTPS 被隐藏。 | 仍然显示

{ "name": "bone2", "bone": "bone2", "rotate": 1, "inertia": 0.5, "damping": 0.85, "gravity": 100 },
{ "name": "bone2b", "order": 1, "bone": "bone2b", "rotate": 1, "inertia": 0.5, "damping": 0.85, "gravity": 100 },
{ "name": "bone2c", "order": 2, "bone": "bone2c", "rotate": 1, "inertia": 0.5, "damping": 0.85, "gravity": 100 },
{ "name": "bone2d", "order": 3, "bone": "bone2d", "rotate": 1, "inertia": 0.5, "damping": 0.85, "gravity": 100 }

In this case the editor behavior is correct, but the export is reversed. We'll fix this in 4.2.26-beta. Cheers!