ndJointSpherical

[blackbird_dream]

Hi all,
I'd like to use a spherical joint to model hip joints of a humanoid biped.
As it is currently implemented in ndJointSpherical.cpp I see no way to get 3 angles of orientation, for instance Euler angles or other types, unlike in ndJointDoubleHinge.cpp where I can find GetAngle0() and GetAngle1()
Do I need to add a Hinge to a double Hinge with a dummy newton body of low mass inbetween to finally get pronation/supination flexion/extension and internal/external rotation ?
Seems not elegant and maybe tricky with matters of poor conditioning due to mass ratio.
PS: sorry same question again and again
Thks

[Julio Jerez]

Do I need to add a Hinge to a double Hinge with a dummy newton body of low mass inbetween to finally get pronation/supination flexion/extension and internal/external rotation ?
Seems not elegant and maybe tricky with matters of poor conditioning due to mass ratio.

yes, you know that that let to really bad results if you are think of a dummy body with almost zero mass.?
You cannot directly extract three independent Euler angles from a spherical joint, because Euler angles are not truly independent. Under certain conditions, they lose a degree of freedom a phenomenon known as gimbal lock.

But the issues go beyond that. The result of combining three rotations depends heavily on their order, and even when a standard convention is used, the rotations are still non-commutative.

There are two main approaches you can take:

1. Use a Spherical Joint with Small-Angle Approximation
You can manage the Euler angles yourself by storing them in your own class.
At each simulation step:
-Read the current rotation from the spherical joint in quaternion form.
-Convert that quaternion to Euler angles using your preferred convention.
-Perform angle arithmetic to compute the desired new angles.
Be careful depending on the rotation order, to avoid gimbal lock issues.
-Keep the angle changes small to stay within the small angle approximation range.
-From the updated Euler angles, compute a new target quaternion and apply it to the spherical joint.
-This works because, for small rotations, the approximation allows the composition of angles to behave as if they commute. As long as the target remains close, the joint will follow the shortest rotational path and the error remains bounded.

However, this method won't work well if the target rotation is far away.
In that case, the joint will still follow the shortest path in quaternion space,
which may differ from the path you'd expect using Euler angles.

2. Use ndIkSwivelPositionEffector
Alternatively, you can skip the spherical joint entirely and use the ndIkSwivelPositionEffector.
This method leverages inverse dynamics, which I assume you're not currently using.
It's more complex but gives you full control over the desired orientation without being bound by the limitations of Euler angles.

[Julio Jerez]

There’s a third option you can use that always works, if you're open to slightly modifying your skeleton structure.

This method is commonly used by people who build pose mannequins for animation, and even by robotics companies. Just search “pose mannequins” on Google for examples.

Instead of using a ball-and-socket joint, you replace it with a double hinge joint that provides two independent rotational degrees of freedom.
Then, you split the thigh (or upper limb) into two collinear segments, connected by another hinge joint.

This setup gives you a full three independent degrees of freedom, allowing you to accurately simulate a human leg or arm. The only difference is that the femur (or upper arm) is divided into two parts, which can rotate along their shared axis. However, the system is mathematically equivalent to a spherical joint.
In fact, many robotics companies adopt this approach to model limbs.

I recommend using this method, it will save you a lot of frustration compared to the small-angle approximation, and more importantly, it provides an error-free solution.

That’s probably close to what you had in mind using tow joints, just make sure you don’t divide the upper limb into an unrealistic mass ratio.

As a general rule, you can start by assuming the thigh has about 1.5 times the mass of the calf. Then, you can break the thigh into two collinear segments, say, using a 1:1.5 ratio, or any other proportion you’d like to experiment with. that way the three limbd are within simillar ratios

By the way, I recently improved the joint solver by adding preconditioners to the part that calculates bounded joint limits. This change made the solver significantly faster, even though it does more work per iteration. The reason is that the LCP solver is now not only more accurate, but also converges in just a few iterations, especially in cases where the matrix was previously ill-conditioned.

I made this improvement after noticing a problem: when simulating an articulated model floating in air (with no gravity), and animating it, the system was gaining or losing linear and angular momentum even though it shouldn’t. I wasn’t expecting zero error in angular momentum, because al all the rounding error from many sources, but it should have been small enough for a controller to handle. That wasn’t the case.

After a lot of debugging, I discovered the root cause: the closed-loop joint solver wasn’t converging. That was a serious issue, because the only straightforward fix would have been switching to a direct method solver, which is far too slow and also very brittle.

Instead, I tried conditioning the matrix, and to my surprise, it worked beautifully. Not only did the solver converge faster, but in most cases, it finds near exact numerical solutions within just a few iterations.

This improvement also allows the solver to handle highly ill-conditioned scenarios caused by unbalanced mass ratios.
A good example is vehicle simulation, which often involves many closed loops and extreme mass differences between part. Previously, this caused vehicles to understeer unnaturally.
But after the fix, the simulation started behaving correctly.

To my surprise, I found that the traditional vehicle dynamics literature was right: rear-wheel-drive cars tend to oversteer more than front-wheel or all-wheel drive cars.
Now, the front wheels can fully use their lateral grip because there’s no longer a convergence issue in the LCP solver.
Before the fix, lateral forces would get calculated incorrectly by the solver with poor convergence, and the car would just slide straight ahead.
my solution was to exaggerate the lateral tire friction, which is always a source of bad uncertainty making calibritaion a black art .

Now I actually have to apply real principles from the books to drive the car, and I can even try using a proper Pacejka tire model, which was impossible in the pass since that model does not rely on normal force. Instead, it relies on the empirical try curves of the tire,
The results are quite remarkable with emerging realist behavior.
It actually blows my mind that Pacejka is independent of the normal force,
it is not worder they call it Magic formula.
That’s been very satisfying.

Sorry for the long rant, but I thought this might be interesting context!
that could give you some confidence that splitting the upper limb will no add extra weirdness.

[blackbird_dream]

Hi Julio,
Many thks for your answer.
About gimbal locks, for lower limbs and gait analysis, it's not that troublesome as angle ranges are <+-90 for hip joints.
Your 3rd solution is good.
I was about to model the intermediate body as a sphere (sort of femur's head) same diameter as the femur capsule, So I believe the mass ratio will be acceptable (they have same density) and finally it will be close to your solution of 2 superimposed capsules.
One more question : I need to deactivate the collision box for the intermediate body. How can I do?

[Julio Jerez]

In the version you probably have, collision handling is done by adding a collision callback,
and using either shapes IDs or bitfields assigned to the collision shapes,
depending on the granularity you want, there are several examples of that in the sdk demos.
The callback then responds when bodies overlap or and on contact point callback

That was the old approach.
In the latest SDK, I’ve focused more on using models. Models are now treated as atomic primitives, and by default, bodies within the same model do not collide with bodies of the same model.
This setup reflects more common usage patterns, where bodies internal collisions are usually undesirable.

This change also improves performance, since it reduces the number of collision pairs. Most models control their internal parts using joints, motors, and limits, furthermore a good controller typically generates collision-free trajectories anyway. Basically, collisions are a contingency,
but the engine is strong enough that can handle that with joint limits.

However, this inverts the behavior of the collision callback, it must now explicitly enable self-collisions when needed. ex a calf may not collide with its parent thigh, but it should collide with the parts on the other leg. In practice, I’ve found this is rarely necessary, because as I stated, a good controller should avoid that.

As for the third solution: the main advantage is that it never produces a gimbal lock situation, so you don’t have to worry about that. Using overlapping capsules is actually a smart idea. Visually, they behave like a single structure, with only minor elastic deformation caused by joint stiffness.

A great example of this approach is seen in Boston Dynamics' latest robots. They split the limb right at the midpoint, and the resulting motion is among the most natural and organic I’ve ever seen in a biped robot.

I mention this, because in newton by default, bodies connected by a joint do not collide,
therefore, if when you break the limbs, if you do not make the collision shape equal size, but rather with some overlap, then you can get a very convenient set up where the upper part that is attach to the humanoid body does not collide with the hip, but the lower part of the limb will when is should because it is physically separated.
the same apply for the children, the lower part will not collide with the calf, but it will with the hip.

then you do not have to worry about setting collision callback until later or maybe ever.

[blackbird_dream]

[Julio Jerez]

Yes, that looks like the split thigh setup! Maybe try making each part a different shade of the same color for clarity, helps.

Edit: Ah yes, I can see it now, the telltale sign is that the leg can rotate around the axis connecting the foot to the hip joint to align the knee.

This setup should give you a robust 3-DOF leg without the complexities and limitations of relying on a single joint. Most importantly, it aligns well with modern engineering practices.

It really makes you appreciate how powerful evolution is. It managed to independently arrive at the concept of ball-and-socket joints across a wide range of species: insects, reptiles, mammals, dinosaurs, and even fish.

Try running what I call the "Conservation of Momentum Test":
it is an important Highly Recommended prerequisite, in my opinion .

Place the body in a floating state (no gravity).
Move one limb, then let the system run freely for a while.

The body should not gain any significant angular or linear momentum over time. Ideally, it should remain stable. Some residual drift may occur due to numerical errors in arithmetic and integration (even when using high-quality methods like RK4 or implicit solvers, as Newton does), but the effect should be minimal.

This test is crucial for any serious simulation.

If your system leaks momentum, your controllers will behave erratically similar to those infamous YouTube videos where characters propel themselves by waving a single limb. Machine learning models, especially powerful ones, will exploit any flaw in your physics engine and produce bizarre, unnatural behavior—see this example:
https://www.youtube.com/watch?v=n0Cpqzqzroo

People often claim those engines are "industry standard," but in truth, they aren’t much better than older engines that used aggressive and highly inaccurate position correction kinematic method. They just hide the issue under the rug.
A proper physics simulation should be simple:
-apply external forces.
-calculate internal action reactions force and apply to the bodies
-then integrate.
-repeat.
there should not be hidden corrections or hacks.

As I’ve mentioned before, older versions of Newton may show momentum violations, when systems with closed DOF loops the LCP solver fails to converge. Even early 4.xx.
When that happens, joints may inject or remove momentum in ways that feel completely random.
that’s may not be a big problem for a game, of a real time may believe simulation.
But violation conservation of momentum is a serious flaw for anyone trying a realistic plausible Simulation and it is a hard thing to debug, except in cases like the test I mentioned.
but the results are very profound when broken, and you have no intuitive way to fix it.

This is why it is important you get the latest version, that go a long way to fix that problem.

[blackbird_dream]

I'm using NDv4