`ContactConstraintManager` asserts when constrained body has limited DOFs about joltphysics HOT 11 CLOSED

As you have been unable to create a repro in the samples, I'll give it a shot to debug it in godot.

from joltphysics.

I think the main issue why this immediately breaks down is that the custom mInertiaRotation that godot-jolt applies doesn't get carried over to the snapshot

Oh right! I should have realized that. I was blinded by the fact that I saw roughly the same results as in Godot.

As soon as the body is rotated by a tiny bit (due to dragging) then the local space inertia tensor and the hinge axis no longer match up and the mass that the hinge sees begins to go to infinity and the whole thing blows up again.

Right, that makes sense.

but maybe you can give it a shot and tell me if it helps

That does seem to fix the issue, actually, in this particular scenario at least.

I think the proper solution for this is for Jolt to officially support locking rotations in world space rather than in local space (for which I already have a partial implementation).

Cool! Looking forward to trying it out. I appreciate the effort.

from joltphysics.

I can confirm that your change did indeed fix the issue of the joint going haywire, in all repros.

And yes, that cleaned up quite a bit of code related to axis-locking, which is great. Thank you!

from joltphysics.

I'm not sure if this assert was related to the problem in godot-jolt/godot-jolt#757, in any case it was not a very serious assert as the code handled the case anyway.

I'm trying to repro the issue using Locked_HingeJoint_GDScript.zip which for me looks like:

Is this what you meant with freaking out or am I getting something else?

I have to say that it crashed at first because of an assert which in godot-jolt does CRASH_NOW_MSG. When I commented that out it runs like in the movie above. There are many asserts that trigger which seem to come from the character having invalid scale. I'm not sure how one would go about fixing them as I haven't worked with the bone objects yet:

Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\CapsuleShape.cpp:267'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\SphereShape.cpp:55'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\CapsuleShape.cpp:267'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\SphereShape.cpp:55'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\CapsuleShape.cpp:267'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\CapsuleShape.cpp:267'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\SphereShape.cpp:55'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\CapsuleShape.cpp:267'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\CapsuleShape.cpp:267'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'IsValidScale(inScale)' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Physics\Collision\Shape\SphereShape.cpp:55'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'inQuat.IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Mat44.inl:87'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'
Assertion 'IsNormalized()' failed with message '' at 'C:\Users\jrouw\Documents\Code\godot-jolt\VS2022_CL\External\Source\jolt\Jolt\Math\Quat.inl:278'

It is difficult to debug it with all these asserts going off.

from joltphysics.

in any case it was not a very serious assert as the code handled the case anyway

Right, I feared that might be the case. I have so far been unsuccessful in reproducing the actual problem in Samples.

I'm not sure how one would go about fixing them as I haven't worked with the bone objects yet

This is an unfortunate known issue in Godot at the moment. I believe there's a pending Godot PR meant to fix this, but it hasn't been merged yet. I'm not sure there's a way to fix it from the project side of things. I typically just change the assertion function to log instead of crash/breakpoint when dealing with skeletons. I'm sure that's less than ideal from a simulation standpoint, although the scales are only invalid by a very tiny amount, from what I remember. Maybe I should consider fixing any invalid scales on my end, if only just to get rid of the Jolt assertions.

Is this what you meant with freaking out or am I getting something else?

Yes, although the effect is much less pronounced with that skeleton for some reason. I have another project that has been further reduced which achieves the same effect with just a regular box instead of the skeleton, which also gets rid of all the invalid scale assertions (which again is a known issue in Godot, unfortunately): JointExplosion.zip

Here's what that looks like for me:

The first door it encounters has the entire body rotated. The second door has no rotations at all. So that might have something to do with it, although I saw no ill effect from this in the Samples app, weirdly enough.

Note that this also uses an angular damping of 0. Changing this back to the default of 0.1 does affect the outcome to something that looks more like what you showed in your clip, but I'm not sure if that's because it actually matters or if it just shuffles things around enough for the result to be different.

This is what it looks like with the default angular damping:

So fairly similar to what you showed in your clip.

I've also observed that this result changes based on which configuration I compile with.

from joltphysics.

Apologies, some last minute changes to the project I linked in my previous comment meant that the first door hinge was incorrectly rotated. I've updated the link with a new version. The end result remains largely the same though.

EDIT: And just to be clear, I don't expect you to debug this through Godot, of course. I'd be happy to keep trying to reproduce it in Samples instead.

from joltphysics.

Oh, b.t.w. one thing I ran into (which I may have asked before): Is the EditorDistribution build supposed to have asserts enabled? I thought I was clever to switch to that build to get rid of the asserts but they still triggered.

from joltphysics.

Oh, b.t.w. one thing I ran into (which I may have asked before): Is the EditorDistribution build supposed to have asserts enabled? I thought I was clever to switch to that build to get rid of the asserts but they still triggered.

Jolt's asserts should definitely not trigger in anything but the Debug and EditorDebug configurations. In fact, I use that same trick from time to time. Anything else would imply that _DEBUG is defined, which would mean that /MTd or /MDd is being used, which would be odd, and would likely cause linker errors either way.

Both the Visual Studio generator and the Ninja generator emits binaries without asserts for me when using the EditorDevelopment or EditorDistribution configurations.

EDIT: Things should be set up so that when you run Build Solution in Visual Studio it'll copy the current configuration's DLLs into examples/addons. So what I typically do is symlink that folder to whatever project I'm messing around with, which should let you have up-to-date binaries at all times, in case it's some issue like that.

from joltphysics.

So it seems like I am in fact able to reproduce the issues in Samples if I use a snapshot. I keep forgetting that this is a thing I can do for some reason.

Here's the snapshot, which is not the same one linked in #915:

jolt_snapshot_2024-02-10_19-35-54_135314.zip

I realized the kinematic body had nothing to do with anything, and just applying an initial angular Y velocity to the dynamic body was enough to trigger the issue, so the scene in that snapshot is further reduced.

However, given the issue of #915 you'll have to add this to the bottom of LoadSnapshotTest::Initialize to avoid the NaN asserts:

for (BodyCreationSettings &settings : scene->GetBodies())
	settings.mMassPropertiesOverride = settings.GetShape()->GetMassProperties();

It doesn't behave in quite the same way as it does in Godot. In Godot it freaks out immediately, whereas in Samples it seemingly only does so once it hits the hinge limit, but I'm assuming it's the same issue regardless.

It should look something like this:

from joltphysics.

I did some initial debugging and I think the main issue why this immediately breaks down is that the custom mInertiaRotation that godot-jolt applies doesn't get carried over to the snapshot:

If you allow rotation around Y then the yellow vector (parallel to the small green vector, the door is rotated relative to the world) is what rotation is allowed around. This means that the hinge as soon as it hits its limits will try to constrain along the world Y (big green arrow) which is (almost) perpendicular to the yellow arrow so it tries to push against a mass of around 10^12 kg and floating point problems cause the thing to explode.

If I add:

BodyCreationSettings &body = scene->GetBodies()[2];
body.mAllowedDOFs = EAllowedDOFs::RotationZ;

to LoadSnapshotTest to simulate what godot-jolt would be doing to lock in world rather than in local space then it works a lot better. If I start dragging with the mouse then it still explodes due to a similar reason: As soon as the body is rotated by a tiny bit (due to dragging) then the local space inertia tensor and the hinge axis no longer match up and the mass that the hinge sees begins to go to infinity and the whole thing blows up again.

If I change:

to

mInvInertiaDiagonal = Vec3::sReplicate(1.0e-12f);

to make the rotations around other axis very difficult but not infinitely difficult then it seems to work. I'm not completely sure if this is compatible with the godot-jolt trick here:

https://github.com/godot-jolt/godot-jolt/blob/105999a1b7ed40829e29dc532bd0e3064fe17edb/src/objects/jolt_body_impl_3d.cpp#L1423-L1428

but maybe you can give it a shot and tell me if it helps.

In any case I think the proper solution for this is for Jolt to officially support locking rotations in world space rather than in local space (for which I already have a partial implementation).

from joltphysics.

Ok, I think this one is fixed now. I tested the last snapshot you sent and that works without issues now. You should be able to remove this and this code now from godot jolt too.

from joltphysics.