Issues post-update to 4.6.1/4.6.2 regarding Constraints

Lucas3DCG

Godot 4.6.1/4.6.2 (extension 4.2-4.6.1/4.6.2)

Crashes on runtime when trying to access constraint_name via get_constraint_name(), more specifically slider constraint name.

for slider in skel_data.get_sliders():
var slider_data = slider.get_data() # returns valid object
var slider_name = slider_data.get_constraint_name() #<--- CRASH RIGHT HERE (no error)

Also after updating GDExtension (previously it was fine) physics (gravity) seems to be unpredictable (sometimes inverted or slanted) right after change to physics_constraint values at runtime via code. Gravity on untouched constraints via runtime code seem to be working fine. But this results in two constraints having same gravity value yet first is going up and the second moving down making mismatch behavior.

Misaki

Lucas3DCG I'm sorry to hear you're having trouble.

Regarding the first issue, I tested this using the diamond project with Godot 4.6.2 and the spine-godot GDExtension, but I was unable to reproduce the crash.

The code I tested was:

extends SpineSprite

func _ready():
	var slider_data = get_skeleton().find_slider("rotation").get_data()
	var slider_name = slider_data.get_constraint_name()
	print(slider_name)

As expected, the slider name, "rotation", was printed to the Output dock without any issues.

Regarding the second issue, could you please send us a minimal project that reproduces the problem via email at contact@esotericsoftware.com ?
Please include a link to this forum thread in your email so we can easily identify the context. Once we have a reproducible project, we'll be happy to investigate further.

Lucas3DCG

get_sliders is the culprit here, not find_slider. Using find_slider with name works without crash (just tested it), but then get_sliders loses the purpose if I want to make snapshot of all sliders settings without manually knowing the names of all sliders. Anyway, I uploaded minimal test project with both issues:

EsotericSoftware/spine-runtimes3107

Misaki

Lucas3DCG Thank you for providing a Godot project that allows us to reproduce these issues. We were able to reproduce the issue described in issue1, and to help us isolate and manage the issue more effectively, we have created a new issue below:
EsotericSoftware/spine-runtimes3109

Regarding issue 2, I tested this with a simplified script and could not reproduce the issue when the physics constraint values are applied only once, or only when the values actually change.

It looks like the unexpected behavior is caused by setting the physics constraint pose values every frame in _process(). Reapplying the same physics values every frame may interfere with or reset the physics simulation, which can result in unstable motion.

Please try applying the values only when they actually change, for example by caching the previous gravity and wind values and skipping the update if they are unchanged.

Lucas3DCG

Another minor thing that I just recalled, while changing a project from 4.5.1 to 4.6.1 I also noitced that
get_physics_constraints() in SpineSkeletonDataResource gives out array of all constraints not just physics constraints, however the other constraints in the array are populated as nulls.

example of constraints list in Spine with order:
physics_constraint_1
transform_constraint_1
IK_constraint_1
physics_constraint_2

in Godot get_physics_constraints() gives basically this array:
[physics_constraint_1, null, null, physics_constraint_2]

only know this minor issue on 4.6.1, not sure if this is present on 4.6.2 though

Misaki

Lucas3DCG Thank you for mentioning this. I tested it on Godot 4.6.2 and was able to reproduce a similar issue.

In my test project, SpineSkeletonDataResource.get_physics_constraints() returned an array with the correct number of entries, but the first element was null even though the skeleton contains four valid physics constraints.

I also verified that all four constraints can be found successfully using find_physics_constraint(), so this does not appear to be a case where non-physics constraints are being included in the array. Instead, it seems that one of the physics constraint entries is not being returned correctly.

I'll investigate this further and create a separate issue if appropriate.

Lucas3DCG

Misaki regarding the _process, I previously had the issue 2 code in _ready instead, where it behaved same way and ready is only applied once. I changed it to the _process so I can then control the gravity/wind via @export variables more easily just for this test. I don't actually change the gravity every frame outside of this test project, however I do change wind, since for accurately simulating it I need to create some turbulence which is hard to do without the constant change. The thing you're describing would mean the physics would reset into default positions, which is not the case. Uncommenting the:

			# Force physics update
			#phys.update(skel, 1)

in the test project further proves it that if simulation is reset every frame, the skeleton bones don't move at all. Which means that again, this is not the case you mentioned.

And I also just now tested on the test project only once or rather re-applied it only when I changed the values in exported variables (not every frame) and the result is still the same "inverted" behavior.

Misaki

I have created the following issue ticket to track the get_physics_constraints() issue:
EsotericSoftware/spine-runtimes3110

Thank you very much for reporting these issues. We have now verified the details and isolated the issue in the first issue you created, so we will close it for now.
We kindly ask for your patience while we work to resolve this issue.

Misaki

Lucas3DCG Thank you for the clarification. It seems I did misunderstand the issue, and I apologize for that.

However, after investigating it further, I don’t think the results are unpredictable. The behavior appears to follow a consistent set of rules. The problem likely seemed more complex because both wind and gravity were being applied at the same time.

What I found is that, compared to the behavior observed in the Spine Editor, applying a positive gravity value via code in Godot can cause the bone to rotate upward rather than downward. This behavior does not appear to be random; it seems to occur consistently under the same conditions.

To make things even more confusing, when a positive gravity value is applied, the physics constraint's translation appears to move downward as expected, while the rotation changes in the opposite direction. Since it is counterintuitive for the translation and rotation to respond differently in this way, I have created an issue ticket to investigate it further: EsotericSoftware/spine-runtimes3112

Lucas3DCG

Misaki Yes, exactly, when I only use translation on 100 in Spine and disable rotation, I get this:

Lucas3DCG

So I tried to prepare simple test project where I have 4 horizontal bones and 5.0 gravity set in Spine:

(bones slightly rotated down)

but now I open the 4.6.2 Godot version I already see this even before I run it (no changes to physics settings via code):

(bones slightly rotated up)

These physics constraints only had rotation enabled on 100

Misaki

Lucas3DCG Thank you for the additional information. That makes it easier to see that the rotation caused by a positive gravity value is consistently directed upward in Godot projects. We will address this issue shortly, so we ask for your patience.

Lucas3DCG

So the issue stems with the XY vs rotation rather than changing values at runtime via code. In my normal projects I have physics constraints that are attached to bones with no length (where rotation is automatically disabled) and then I have physics constraints that have both rotation and XY translation. Now it makes sense to me why each of them was behaving differently. After testing changing things via code seems to be irrelevant. I'm glad that now I finally understand the core issue and where it was. 🙂