Kinematic Controller control modes?

[JoshKlint]

I have found that when max angular friction is set to zero, the kinematic joint in Newton 3 spins around quickly. I would expect instead that a kinematic controller with torque set to zero would act like a ball and socket joint with no twist or cone limits.

I looked at the source and found these constants. It looks like the default mode is m_full6dof.

Code: Select all

   enum dControlModes
   {   
      m_linear,
      m_full6dof,
      m_linearAndTwist,
      m_linearAndCone,
      m_linearPlusAngularFriction, // this is pickmode from screen
   };

• What mode should be used if I want the joint to only affect position? m_linear?
• What mode should be used if I want the joint to only affect rotation?

[Julio Jerez]

That seems from Newton 3.xx.
In Newton 4, the modes are defined like this:

Code: Select all

class ndJointKinematicController: public ndJointBilateralConstraint
{
public:
    enum ndControlModes
    {     
        m_linear,
        m_full6dof,
        m_linearPlusAngularFriction, // for screen-pick mode
    };
};


Now, a few observations:

Kinematic joints are very heuristic.
They’re designed to convert values from linear and angular space into acceleration space. This means the resulting accelerations scale with the square of the timestep. Things get even worse when the joint is used to map screen coordinates into displacements in global space because of perspective inversion, the joint ends up being extremely stiff.

Limitations in Newton 3.xx.
In version 3, joints could not have more than 6 DOF. That meant friction, limits, springs, dampers, and motors—anything operating on a single axis had to be resolved combined on that axis.
The problem is that in many cases, such as kinematic joints, these constraints actually involve different dimensions, they just happen to share a common axis.

For example: if a joint has both a hard limit and friction, once the limit is reached, the solver flips the velocity. However, friction still acts in the same direction, opposing the hard limit. Adding relaxation or spring-damping only makes things worse.

The workaround was to implement a mini constrained system per dimension. But this didn’t always work, because it ignored how other joints interacted.

Improvements in Newton 4.xx.
The solver in version 4 can now handle up to 12 DOF.
-Bilateral constraints (springs, frictions, etc.) are solved directly in their own dimensions.
-Limits are solved separately by the preconditioned LCP solver.
-The final acceleration is the sum of the partial results.

This allows combining dry friction and viscous friction on the same axis,
something not possible in 3.xx.

So, to answer your question:
Accelerations derived from positions are generally unpredictable.
In 3.xx, the workaround was to use strong dry friction, but that made the joint difficult to tune.

you do not want dry friction, but if the acceleration will be very large, or it is permanent, then the joint will probably explode, simply because from newton laws, if there is a net acceleration then the velocity will keep changing.
Even when the acceleration is zero, the angular velocity will still be non-zero, again, because of conservation of momentum.

The answer:
if you do not want dry friction, you set viscous friction applied through a bilateral constraint that dissipate the joint momentum.
Unfortunately, as I said, that functionality is only available starting in Newton 4.xx.

[Julio Jerez]

For 3.xx
The question is confusing.
You say you want to control linear dof by setting target position.
Which to means using the linear mode and the attach body will rotate.

But what I think you mean is that you want to control that the body do not rotate, so you most set a full transform matrix. that will be the second option ( six dof mode).
Those are the modes that control the joint by hard limit, position and angle.

All the other are combination of friction,
which means the body had momentum and will rotate until it reaches zero.

[JoshKlint]

I was thinking that if the SetMaxAngularFriction was set to zero, then the joint would only affect position and the object would still rotate freely, like a ball and socket joint.

[Julio Jerez]

No.
The equation for a degree of freedom (DOF) is a linear function of the reaction joints forces

A f = b
subject to the constraint:
f0 <= f <= f1

Where:
A is the mass term,
f is the joint force,
b is the acceleration of the DOF,
f0 and f1 are the friction limits.

The engine solves this equation continuously.
The SDK provides classes that set the values of b, f0, and f1, to achieve the desired behavior for each DOF.
It also determines how many DOFs a joint has.

Here’s the mistake: you’re configuring an angular DOF. That tells the solver it must handle the constraint

A f = b
with
0.0 <= f <= 0.0

which means the corresponding row in the mass matrix is just a linear combination of other rows. Since the solution for f is zero and when pivoting scaling that row by zero reduces it to nothing.

As I mentioned, Newton 3.14 can't separate joint limits for bilateral constraints.
so the engine tries to solve this inside the joint’s callback function by adding some angular viscous friction, that is calculate heuristically from the inertia. You can see this in

void dCustomKinematicController::SubmitConstraints (dFloat timestep, int threadIndex)
(line 291 and elsewhere).

The only way to get the joint to behave like a ball socket is to use a model that does not issue angular constraints (e.g., m_linear).
But that has the drawback that angular velocity is derived indirectly from converting position deltas to accelerations.

What you actually want is a joint that issues three linear DOFs and one angular viscous DOFs:
Where the angular dof is a pring damper with a high, relaxation, zero spring const and a tunable damping constant. That is.

A f = b
with
−inf <= f <= inf

with b defined as a spring-damper acceleration where the spring constant = 0 and the damper constant > 0.

That joint does not exist in Newton 3.14. but you can make it.

To implement it, you can subclass (or copy/paste) the existing joint and override the joint callback, e.g.:

Code: Select all

void dCustomKinematicController::SubmitConstraints (dFloat timestep, int threadIndex)
{
    dMatrix matrix0;
    dMatrix matrix1;
    CalculateGlobalMatrix(matrix0, matrix1);
    SubmitLinearConstraints(matrix0, matrix1, timestep);

    // Submit angular axis (adapted from ball-and-socket joint)
    MyAngularDamp(matrix0, matrix1, timestep);
}

void MyAngularDamp(const dMatrix& matrix0, const dMatrix& matrix1, dFloat timestep)
{
    // Ensure spring constant is zero
    dVector lateralDir(matrix1[0].CrossProduct(matrix0[0]));
    dAssert(lateralDir.DotProduct3(lateralDir) > 1.0e-6f);
    lateralDir = lateralDir.Normalize();

    dFloat coneAngle = dAcos(dClamp(matrix1.m_front.DotProduct3(matrix0.m_front),
                                    dFloat(-1.0f), dFloat(1.0f)));
    dMatrix coneRotation(dQuaternion(lateralDir, coneAngle), matrix1.m_posit);

    // ... rest of damping implementation
}

[Julio Jerez]

What I don’t understand is why you want to build this with version 3.14, when my impression was that you had already moved on to 4.xx.

Newton 4 introduces major improvements over 3.14, addressing many issues that simply couldn’t be solved in the older branch. For example, Newton 4 has a much more direct solver compared to 3.xx. But that’s not the only improvement: each constraint in Newton 4 has two slots — one for a bilateral with relaxation/unconstrained, and another for a hard limit. The key point is that the hard limit is solved by a preconditioned solver, which makes the solutions significantly more accurate.

Here’s a practical example:
Suppose you want to build a sliding door with a motor that opens and closes it. If you try to model this in 3.14 using a spring-damper as the motor, you’d need to add a relaxation value. The resulting equation looks like this:

Code: Select all

(A +r) f = b + penalty
with constraint
f0 <= f < f1


Since the mass term is modified, the solver cannot calculate the exact solution. The effect is that when the slider hits the limit, it will penetrate past it.

Now, in Newton 4, the formulation is:

Code: Select all

​A00 * f + A01 * g = b0
A01 * f + (A11 + r) * g = b1

With limits
-f0 < f < f1
-inf < g < inf

two independent equations. that go to two different solvers.
The second one corresponds to the bilateral joint, solved exactly by the direct solver, and using the modified mass.
while the first is a constrained row handled by the preconditioned lcp solver, which uses the correct mass matrix, so it generates hard contacts.
The solution combines both contributions.

This means the motor can operate independently of the joint limit, something that isn’t possible in 3.14.

My suggestion: spend some time migrating to 4.xx.
It solves many of the mundane but important behaviors you’d expect from a physics engine,
which are very hard to model accurately with iterative solvers.

In addition, there are some many more refinement, optimization and features, that really make a huge difference.

[JoshKlint]

Although Newton 4 looks very promising, I am using Newton 3 because there is currently no documentation of Newton 4 in the wiki, and the C++ API seems to be very different from what I am used to. I had a partial implementation of it at one point, but had some confusion about something (I don't remember what it was), and decided to stick with what I know. It took me years to fine-tune my physics system to work exactly the way I wanted, and I can't take risks on a new version at this time.

[Julio Jerez]

well, I do not know what to say. Newton 4 is a very plain vanilla c++ api.
Everyone how has tried figure out the SDK philosophy very quickly find that far better and more intutive than 3.xx

but if you feel better with 3.xx, then you have a way to implement the custom joint for that.

and simple way is to just subclass the BallAndSocket,
because it already has all the logic for the angular drag.
them replace the linear part with the linear dof from the kinematic joint.

[JernejL]

A bit offtopic, but one of reasons that makes newton 3 so great for me is the plain C api. It allows much easier and standard integration with other languages.. just plain C api, cdecl calls - pointers and callbacks. simple and can be wrapped in any other language.

[Julio Jerez]

ok. It took me a while to reply, I wasn’t quite ready before.
You’re absolutely right on all those points.

This is what I am doing.
I’m going over cleaning up the demos so they’re completely graphics API agnostic.

As a little bonus, I put together a simple prop vehicle you can actually drive.
It’s not realistic at all, not even a raycast car, just a collision shape sliding over terrain.

Since it’s 2025, we can now use compound collisions to generate solid terrain contacts.
The performance cost is minimal. An application can place hundreds, even thousands,
of these objects in a map and still control them through game logic and AI to do stuff like making the follow a path precisely.

The neat part is that these vehicles are full rigid bodies that interact with everything in the world, while still being precise enough for AI control.

If anyone’s sync, feel free to check it out.
I am now moving to more ndModel based demos, that will be placed on a library.

I post this because, if I remember correctly, you both has done similar things in the pass.
My hope this shows that moving to 4.xx there is a lot of gifts that the engine provides in return for the effort.

[JoshKlint]

I'm about to release Leadwerks 5, and have begun working on a commercial game with physics similar to Amnesia. I will definitely give Newton 4 another try in the future.