Lock constraint always aligns rotation of the 2 bodies?

[josephrocca]

Has anyone else ever had this problem? I've been trying to nut it out all day.

I initialise the two boxes like the picture on the left, but when I apply the LockConstraint, both boxes quickly rotate around so that they are aligned (but offset) like the picture on the right, and then lock into place like that.

My code for applying the constraint is simply:

      var c = new CANNON.LockConstraint(bodyA, bodyB, {
         maxForce: params.maxForce || Number.MAX_VALUE
      });
      c.collideConnected = false;
      this.world.addConstraint(c);

I haven't fully tested other constraint types for similar behavior, but preliminary tests show similar behavior - if the bodies have different orientations, they will be aligned when I add the constraint.

[schteppe]

Are you using the very latest version? I think this was fixed in 20b7eee

Rebuild and try again? Would be nice to have this fix verified. Thanks.

[josephrocca]

Awesome, LockConstraint is now working properly after updating to the latest version, but HingeConstraint is still having the exact same problem :\

[schteppe]

Oh, nice. The HingeConstraint doesn't have that feature yet. But I guess it would be very handy :)

[josephrocca]

Hmm, so the initial orientation of the 2 bodies must be aligned for a hinge constraint to work properly? If that's correct, are there any hacky workarounds for this that you could suggest?

[schteppe]

No, you just need to specify the pivots and the axes correctly...

As you probably know, the hinge constraint needs a local axis and pivot point in each body. The constraint tries to match the pivot point positions, and the axis directions.

The trick is to setup the parameters so the constraint is in rest when the simulation starts. This can be done manually or in a more automatic manner. The LockConstraint is fully automatic and need no parameters at all - it will take the positions and orientations of the bodies as initial parameters and compute its local pivots and axes.

The HingeConstraint cannot be made as convenient as the LockConstraint, but almost. If you know the point and axis (in world space) of your hinge, you can create it like this:

// Beware: untested code
var worldPoint = ...
var worldAxis = ...
var localPivotA = bodyA.pointToLocalFrame(worldPoint);
var localPivotB = bodyB.pointToLocalFrame(worldPoint);
var localAxisA = bodyA.vectorToLocalFrame(worldAxis);
var localAxisB = bodyB.vectorToLocalFrame(worldAxis);
var c = new CANNON.HingeConstraint(bodyA, bodyB, {
    pivotA: localPivotA,
    pivotB: localPivotB,
    axisA: localAxisA,
    axisB: localAxisB
});

If you use this code, the constraint should start at rest, and not get an "alignment movement" at start.

Should be really easy to get this into the constructor of HingeConstraint, I've just not gotten there yet...

[josephrocca]

Ahhh, yes, you're right! I wasn't setting my axes right :| thanks for your patience!

[donmccurdy]

@schteppe Would you mind doing a release with this patch, if it's not blocked on a milestone? I'm using it in a Vive example, and don't want anyone reusing my code to be surprised by that.

[jsoutherland]

@schteppe I noticed the most recent release (0.6.2) is still missing this patch.
I replaced my version with master (569730f) and believe I am still seeing this issue with lockConstraint.

I have tried turning off self collisions and tried removing one body's collision shape and neither worked.

[schteppe]

Yeah, should really make some time for a new release..
Did you build the latest master? The build/ directory is only updated on releases. Run grunt to update it manually

[jsoutherland]

@schteppe Thanks I missed that step.

I tried again but it still didn't work. I may have something else going on.

I did have to use this fix for grunt to succeed: #280
I was working off of #275

[jsoutherland]

@schteppe I don't see how the three rotation equations are different?

cannon.js/src/constraints/LockConstraint.js

Lines 45 to 62 in 20b7eee

	// ...and the following rotational equations will keep all rotational DOF's in place
	/**
	* @property {RotationalEquation} rotationalEquation1
	*/
	var r1 = this.rotationalEquation1 = new RotationalEquation(bodyA,bodyB,options);
	/**
	* @property {RotationalEquation} rotationalEquation2
	*/
	var r2 = this.rotationalEquation2 = new RotationalEquation(bodyA,bodyB,options);
	/**
	* @property {RotationalEquation} rotationalEquation3
	*/
	var r3 = this.rotationalEquation3 = new RotationalEquation(bodyA,bodyB,options);
	this.equations.push(r1, r2, r3);

[schteppe]

The equations are the same but the vectors they operate on are different. See the diff here: 20b7eee

[jsoutherland]

Thank you for pointing that out. I see how it works now.

It is working now for me, Chrome was caching the old version 😞

[deltakosh]

Hello, we have this issue with the latest version we found on the repo. Is this fix available somewhere? Do you think you could build a new release?

[donmccurdy]

Physics for A-Frame VR currently uses https://github.com/donmccurdy/cannon.js/tree/v0.6.2-dev1, to include this fix.

[deltakosh]

Thanks @donmccurdy, but I would have expected an official build. Some users would like to get the library from the official repo :(

[roscopetracula]

@schteppe Bump on the new build -- Babylon.js could benefit from that too -- the standard method of loading Cannon there is to pull it in via cdn, so building is beyond what many user are likely to know to do.

Thank you for the great library!! :-)