Joint/contact solver PhysX 2.x VS PhysX 3.x.

Recently we upgraded our software from PhysX 2.4 to PhysX 3.2. After a long time of tuning and experimenting we believe that we found the optimal settings for our simulation purpose. With these setting we note that the simulation in a bit faster in PhysX 3.2 than in PhysX 2.4, however we currently believe that this is at the cost of the joint/contact solver accuracy/stiffness (If I remember correctly contacts are handled as temporary constraints in PhysX, therefore I mention the problem in one sentence). With this question I hope someone can tell us right OR (preferably!) explain us how to tweak the PhysX 3.2 (joint) solver to perform reasonable the same as PhysX 2.4.

To get more background information, please read the following:
The purpose of our simulator is to simulate tasks performed with a (simulated) robot that is actuated via a hardware haptic master device by a human (see e.g. The master device is connected to a robotic hand by a controller. The hand has a two finger gripper interface. The controller can exert at most 3.5 [N] of force and 3 [Nm] of torque to the hand. (As the scene dimension are in units of [mm], [s] and [kg] it means that the forces and torques are at most 3500 [mN] and 3*10^6 [mNmm])

The joint solver inaccuracy/slackness that we encounter in PhysX 3.2 is that joints allow movement along an axis that is restricted. The movement occurs even at a fraction of the maximum master forces. This movement does not occur in PhysX 2.4. This can be seen clearly in the following images:
PhysX 2.4 the gripper fingers remain parallel ->
PhysX 3.2 the right finger is bended relative far ->
I must admit that we use a long kinematic chain with many joints, but why is it working correctly in PhysX 2.4 and not in PhysX 3.2?

The contact inaccuracy/slackness that we encounter in PhysX 3.2 a slight movement in contact points. We notice this is behaviour extremely is a Jenga scene we have. When we push to the tower of Jenga bricks so gentle that the static friction force between the bricks is just not overcome, the tower noticeably “bends”. This can be seen clearly by the vertical black line in the following figure -> Even worse is that the tower wobbles back when the contact is released. This bend and wobbling is by far not noticeably in PhysX 2.4.

PhysX 2.4 settings are:
Time step = 0.003 [s] (calculation takes about 0.0027 [s])
Skinwidth = 0.2 [mm]
Typical mass = 0.03 to 1 [kg]
Typical object size = 10 to 1000 [mm]

PhysX 3.2 settings are:
Time step = 0.003 [s] (calculation takes about 0.0021 [s])
contactCorrelationDistance= 10 [mm]
pcm collision detection = false
friction model = two directional
use adaptive forces = true
RestOffset = 0.0 [mm]
ContactOffset 0.01 [mm]
Typical mass = 0.03 to 1 [kg]
Typical object size = 10 to 1000 [mm]

We also tried to use the projection method of joints, which seem to do the trick for pure joints. However The PhysX guide mentions “It is best avoided” and “does not respect collision geometry” while we only notice it in during collision. Moreover it does not work for contacts.

We really hope that someone can point us to the solution to of how to tweak the PhysX 3.2 (joint) solver to perform reasonably the same as PhysX 2.4. If not, I hope that someone form Nvidea can verify that the PhysX 3.2 (joint) solver is more compliant (as we currently suspect) than the one in PhysX 2.4.


I’ll bring this to the attention of the PhysX SDK engineers who deal with joints. I am not aware of any fundamental reason why the 3.2 joints and contacts should be more compliant than those of 2.8.4. However there could be a bug lurking, or there could be some tuning difficulties. I’ve examined the jpgs, but the problem is not clear to me. Could you grab a capture with PhysX Visual Debugger?

Also, you don’t mention what value you used to set the maximum solver iteration count.


Hey Mike,

Thanks a lot for the response. Good point about the solver iteration count. However in PhysX 3.2 I can only find the min and not the max. And is it true that I can only set them for rigid bodies and not for joints?
PhysX 3.2 it is:
minPositionIters = 30
minVelocityIters = 1

PhysX 2.4 it is:
solverIterationCount = 30

This afternoon I will create a PVD file of both PhysX engines for you.


Unfortunately the setup was occupied this afternoon. Monday it will be the frist think I do.

Hey Mike,

There they are: (PhysX 2.8.4) (PhysX 3.2)

The files only contain the object data (and for PhysX 3.2 you can see constraints) as it is a to heavy load for the computer to transmit the data to the debugger. I hope it provides sufficient information.

A note on the files:
-The files are made with version 2.0001.1986.9381
-We do not set a start-up camera for the PVD, so you should look around first where the objects are located.
-As we work in [mm] I guess it is wise to set the camera speed scale to about 60.



Very sorry for not getting back to this sooner, I didn’t receive a notification of the topic update. I’m downloading the files, I’ll have a look.


Also, please note that a new build of PVD is available on RDP, and it will help fix those performance problems with large captures.

Do the current captures provide enough information or do you prefer a new capture? If so, I prefer to send them to you directly instead of posting them on the forum.


This may or may not be related, but when trying to use the PhysX 3.x fixed joints we had to abandon our plan and ended up using compound objects (multiple shapes) because the fixed joints wobbled and bent with even moderate forces.

This sounds defiantly related.

You probably intended to built concave actors out of multiple convex objects. Each actor in our scene that requires to be concave is already made out of multiple convex objects. At the place we use joints, we really need them to make specific movements. Further in the rear occasion that we use a fixed joint, we require specific collision or “actuation” properties.

Thanks for thinking along,

… “defiantly”? Seriously? Come on! DEFINITELY.


Out of curiosity, have you tried to use Articulations ? They are stated to be more stable than regular joints.

We did not try Articulations. I have read about them and they seem to give the same flexibility as D6joints at less computational power. I fear however that it would require considerable rewriting in our code and models (to make it generic and not only for one setup) and that we would need to give in on flexibility. In the end, even if Articulations would solve the “compliant” joint problem, there is still the “compliant” contact problem.

Thanks for your thoughts