HingeConstraint does not behave as expected

[fhoenig]

The hinge constraint seems to work well, but only when mPoint1=mPoint2 and mAxis1=mAxis2, etc...
Possibly this is a confusion on my end, but I would think the behavior with regards to these settings should be equivalent to the DistanceConstraint.

Here is one way to reproduce the (for me) odd behavior:

From the sample app:

{
	// Two bodies connected with a hard hinge
	Body *body1 = mBodyInterface->CreateBody(BodyCreationSettings(new BoxShape(Vec3::sReplicate(1.0f)), RVec3(4, 5, 0), Quat::sIdentity(), EMotionType::Static, Layers::NON_MOVING));
	body1->SetCollisionGroup(CollisionGroup(group_filter, 0, 0));
	mBodyInterface->AddBody(body1->GetID(), EActivation::DontActivate);
	Body *body2 = mBodyInterface->CreateBody(BodyCreationSettings(new BoxShape(Vec3::sReplicate(1.0f)), RVec3(6, 5, 0), Quat::sIdentity(), EMotionType::Dynamic, Layers::MOVING));
	body2->SetCollisionGroup(CollisionGroup(group_filter, 0, 1));
	mBodyInterface->AddBody(body2->GetID(), EActivation::Activate);

	HingeConstraintSettings hinge;
	hinge.mSpace = JPH::EConstraintSpace::LocalToBodyCOM;
	//hinge.mPoint1 = hinge.mPoint2 = RVec3(5, 4, 0);
	//hinge.mHingeAxis1 = hinge.mHingeAxis2 = Vec3::sAxisZ();
	//hinge.mNormalAxis1 = hinge.mNormalAxis2 = Vec3::sAxisY();
	//hinge.mLimitsMin = DegreesToRadians(-10.0f);
	//hinge.mLimitsMax = DegreesToRadians(110.0f);
	mPhysicsSystem->AddConstraint(hinge.Create(*body1, *body2));
}

To keep it simple and remove the world to COM space transformations, the idea is that we leave everything to default, except setting the space. Now the two cubes will have their COM as the hinge frame origin, one cube dim from each other.

When the simulation starts the dynamic cube assumes the position of the other cube as if this was a distance constraint with min and max distance 0.0. One would expect the initial distance between mPoint1 and mPoint2 being retained.

Similar issues (but more confusing) seem to happen with multiple axes.

[jrouwe]

What you've created with the example code is this:

The constraint enforces the local space mPoint1 and mPoint2 to coincide in world space. It also enforces that the green axis align in world space. If the red axis align in world space we have HingeConstraint::GetCurrentAngle() == 0.

In your example, as soon as the simulation starts, the bodies move together so that their COM's coincide (because both points were set to 0):

and then they can rotate like this (the shared green axis):

[fhoenig]

Thanks for clarifying. This is indeed the behavior I have observed.

I guess the confusion came from HingeConstraintSettings when defined in world space. In that case the really only meaningful way to "fill out" that struct is to set point and axis to the same values, like in all examples. I thought you could define two relative rotational degrees of freedom with this single constraint. Like a wheel that rotates but also can "squat" sideways, like some cars when accelerating.

[jrouwe]

In that case the really only meaningful way to "fill out" that struct is to set point and axis to the same values, like in all examples.

You would use 2 different points/axis if two bodies were created in world space in a different relative orientation than how you would want them constrained. But it is indeed most useful if you specify them in local space.

I thought you could define two relative rotational degrees of freedom with this single constraint. Like a wheel that rotates but also can "squat" sideways, like some cars when accelerating.

That's not possible. You'd need a 6DOF constraint for that.

[fhoenig]

@jrouwe - btw... I noticed a potential contradiction in the comments of HingeContraintSettings...
It says normal axis defines the 0 angle of the hinge. but then also Bodies are assumed to be placed so that the hinge angle = 0.

Experimentally, the limits indeed ignore what normal axis I specify and leaves the 0 angle at the initial state.

[jrouwe]

You can see how it works by dropping this in the Samples app:

void HingeConstraintTest::Initialize()
{
	// Floor
	CreateFloor();

	Ref<GroupFilterTable> group_filter = new GroupFilterTable(2);
	group_filter->DisableCollision(0, 1);

	Body *body1 = mBodyInterface->CreateBody(BodyCreationSettings(new BoxShape(Vec3::sReplicate(1.0f)), RVec3(-1, 5, 0), Quat::sIdentity(), EMotionType::Static, Layers::NON_MOVING));
	body1->SetCollisionGroup(CollisionGroup(group_filter, 0, 0));
	mBodyInterface->AddBody(body1->GetID(), EActivation::DontActivate);
	Body *body2 = mBodyInterface->CreateBody(BodyCreationSettings(new BoxShape(Vec3::sReplicate(1.0f)), RVec3(1, 5, 0), Quat::sIdentity(), EMotionType::Dynamic, Layers::MOVING));
	body2->SetCollisionGroup(CollisionGroup(group_filter, 0, 1));
	mBodyInterface->AddBody(body2->GetID(), EActivation::Activate);

	HingeConstraintSettings hinge;
	hinge.mPoint1 = hinge.mPoint2 = RVec3(0, 4, 0);
	hinge.mHingeAxis1 = hinge.mHingeAxis2 = Vec3::sAxisZ();
	hinge.mNormalAxis1 = Vec3::sAxisX();
	hinge.mNormalAxis2 = Vec3::sAxisY();
	hinge.mLimitsMin = DegreesToRadians(-1.0f);
	hinge.mLimitsMax = DegreesToRadians(1.0f);
	mPhysicsSystem->AddConstraint(hinge.Create(*body1, *body2));
}

This produces:

hinge.mp4

This is because I defined the normal axis (in world space) like this:

hinge.mNormalAxis1 = Vec3::sAxisX();
hinge.mNormalAxis2 = Vec3::sAxisY();

The hinge is configured with a rotational freedom of +/- 1 degree and since the left box is static, the right box must rotate so that its normal axis (Y = up) matches the normal axis of the static box (X = right) in world space.

You can see that it doesn't move in a physically correct way because the rotation originates from fixing the constraint error, not from gravity. This is also why it is usually not a good idea to spawn bodies in such a way that the constraint limits are violated in their initial position.

If you change the rotational freedom to [0, 90] degrees:

hinge.mLimitsMin = DegreesToRadians(0.0f);
hinge.mLimitsMax = DegreesToRadians(90.0f);

Then the inital position is does not violate the constraint. You'll see that the simulation starts at a hinge rotation of 90 degrees and falls under the influence of gravity to 0:

hinge2.mp4

You can use this e.g. for elbow joints where the modeled bind pose (= stretched elbow) is not the most logical 0 angle for the constraint.

The comments are a bit misleading indeed, I've updated them. Is this clear?

[fhoenig]

Ah so basically the normal axis on both bodies are where relative to the body the 0 angle is. Of course! It got really confusing while making custom visualizations.

Btw, it might make sense to expose some getters for the private members of the relative positions so that the code in the debug draw members can be more easily replicated from the "outside".

[jrouwe]

Btw, it might make sense to expose some getters for the private members of the relative positions so that the code in the debug draw members can be more easily replicated from the "outside".

Depends a bit on what you need. Let me know what you're interested in.

[fhoenig]

In essence, an alternative to access info to calculate world space info similar to what the debug draw functions use.

[jrouwe]

Like this: a90e888?

[fhoenig]

Awesome. Thank you!