upvector contraint

[tanzfisch]

Hi,

I used to have a cube that was not rotating after colliding with anything.
I used two upvector constraints to force it to stay axis aligned (0,1,0) and (1,0,0).

But using the latest version of newton now I get an assertion in dgBilateralConstraint::SetPivotAndPinDir
In the commit note it says: now skeletal joints handle root with infinite mass

So how can I achive now to make e.g. a cube not to rotate after colliding with things?

Thanks

[Julio Jerez]

if that was working I imagine if was because you where using the old style joints.
It is an engine design condition that you cannot attach two bilateral joints to the same body pair.

it is always possible to make and adaption to one of the custom joint to achieve what you want
what joint are you using.

[JoeJ]

You can use the kinematic joint and remove it's linear rows.

[tanzfisch]

if that was working I imagine if was because you where using the old style joints.
It is an engine design condition that you cannot attach two bilateral joints to the same body pair.

it is always possible to make and adaption to one of the custom joint to achieve what you want
what joint are you using.

is this creating an old style joint?

NewtonConstraintCreateUpVector(static_cast<const NewtonWorld*>(_world), upVector.getData(), static_cast<const NewtonBody*>(body->_newtonBody));

[tanzfisch]

You can use the kinematic joint and remove it's linear rows.

Have not used kinematic joints yet. When I google it I only find superficial answers. Can you please say some more to that!? Thanks

[JoeJ]

It's part of the joint library: \packages\dCustomJoints
there is CustomKinematicController

I see it's not necessary to remove any code, you also can disable position constraint by setting m_maxLinearFriction to zero with SetMaxLinearFriction(0).

[tanzfisch]

ic. Let's say I don't want to use dCustomJoints just yet ...

I need help to unterstand

NEWTON_API void NewtonUserJointAddAngularRow (const NewtonJoint* const joint, dFloat relativeAngle, const dFloat* const dir);

What exactly is relativeAngle? And why was it called relativeAngleError before?
Is that the amount I turn the body arround dir?

[JoeJ]

What exactly is relativeAngle? And why was it called relativeAngleError before?
Is that the amount I turn the body arround dir?

There are mainly two use cases, think of a door hinge.

First case is: Door can rotate freely, but it's not allowed to go outside 0-90 degrees.
This is a hard limit.

Code: Select all

if (doorAngle > PI*0.5)
{
NewtonUserJointAddAngularRow (joint, doorAngle-PI*0.5, &hingeAxis)
NewtonUserJointSetRowMinimumFriction (joint, -angularFriction);
NewtonUserJointSetRowMaximumFriction (joint,  0);
}
if (doorAngle < 0)
{
NewtonUserJointAddAngularRow (joint, 0-doorAngle, &hingeAxis)
NewtonUserJointSetRowMinimumFriction (joint, -0);
NewtonUserJointSetRowMaximumFriction (joint,  angularFriction);
}


So in this case we give the angle error.
Also with Friction function we set the maximum force / torque the joint can use to keep the limit.
We set it zero for the other direction because the door should not get stuck at 90 degrees,
it should be free to rotate back until it hits the 0 degrees angle.

Warning: I may accidently did this the wrong way around, reversing signs and Min/Max functions is a matter of trial and error. But you get the point...



Second case is: It's a revolving door that should constantly rotate at a given angular velocity
This is a motor.

Code: Select all

float targetAngularAcceleration = measure angular velocity error and convert to angular acceleration that should fixe this error in short time

NewtonUserJointAddAngularRow (joint, 0, &hingeAxis);
NewtonUserJointSetRowAcceleration (joint, targetAngularAcceleration);
NewtonUserJointSetRowMinimumFriction (joint,  -maxMotorTorque);
NewtonUserJointSetRowMaximumFriction (joint,  maxMotorTorque);


Here we don't want to change the angle immideately, thus zero.
Instead we want to change acceleration, and optionally clamp torque again to prevent a infinite strong motor (no one should get killed by this door).

The term "relativeAngle" makes more sense if it's a joint between two bodies,
which is not the case for the kinematic joint, which is between a single body and global space.

[tanzfisch]

So in the first case we basically set back the door to zero if the angle for any reason was below zero?

So if I want a door that does not rotate but stay in a specific position I calculate in what position it is compared to where I want it and then give difference as a correction value to NewtonUserJointAddAngularRow!?

Is that what they try to do in the following example?
http://newtondynamics.com/wiki/index.ph ... o_rotation
I tried out that example but the orientation does not stay still. It jitters.

Does it jitter because the don't set min max friction?

[JoeJ]

So in the first case we basically set back the door to zero if the angle for any reason was below zero?

So if I want a door that does not rotate but stay in a specific position I calculate in what position it is compared to where I want it and then give difference as a correction value to NewtonUserJointAddAngularRow!?

Yes and yes.

Is that what they try to do in the following example?
http://newtondynamics.com/wiki/index.ph ... o_rotation
I tried out that example but the orientation does not stay still. It jitters.

Does it jitter because the don't set min max friction?

In this example i can't really follow the way the angle is measured - do you understand this?

Anyways, locking rotation removes any degree of freedom and so is a hard task for the solver - stability issues are expected - max friction may reduce but not prevent the problem.

The kinematic joint handles this by being a motor, fixes error over time, less aggressive.
I suggest you copy it's code and tweak it to your liking.

[tanzfisch]

In this example i can't really follow the way the angle is measured - do you understand this?

no me neither but the resulting angle seems to be the difference from where it should point to to where it actually points.

Anyways, locking rotation removes any degree of freedom and so is a hard task for the solver - stability issues are expected - max friction may reduce but not prevent the problem.

Yes that is a problem but if you can not lock it physics kind of get's in the way of what one wants to accomplish. e.g. a character controller.

But now that I think about it. It could be kind of nice if the character turns a little if it get's hit by something. So kinematic joint you say. I put that on my list of thing to try.

[JoeJ]

I use a character controller by using torque to keep it upright, even with that it's very stiff, with joints more stiffness is possible, even with motors. Don't worry about that.

For a single body it should not jitter noticeable with a setup similar to the tutorial.
I guess the code makes assumtions on planeNormal and body orientation we don't know, but the angle seems buggy anyways, i miss sqrt there.

You can also look at CustomUpVector and add the angle lock there.

[tanzfisch]

Yes the CustomUpVector variant does kind of what I wanted.

Maybe I will use the dCustomJoints in future but I don't feel comfortable with that because I already wrote my own wrapper and I don't want too much redundancy. A good compromise will be to integrate some ideas from dCustomJoints in to my code.

Thanks everyone!