The evolution of PhysX (7/12) - Joints
Our test scenes so far only used simple rigid bodies. We’ll now look at a few scenes involving rigid bodies connected by joints.
The first scene (“BridgeUsingHinges”) contains a bunch of bridges, made of boxes connected by hinge/revolute joints. This is again a pretty standard test scene, just to check that the basics are indeed working.
And indeed, they are.
The results are not surprising and not especially revealing. This stuff just works in all engines, which is what we expected from mature libraries. Performance and memory usage are pretty much the same, even though PhysX 3.3 seems to have an edge compared to the competitors.
—-
The next two scenes (“HingeJointChain” and “SphericalJointChain”) are similar, and they just create chains of objects connected by either hinge or spherical joints (one end of the chain being attached to a static object).
No big surprise here. Again, this stuff just works, and both performance and memory usage are very similar in all engines.
Compared to the first scene though, Bullet appears to be measurably slower than PhysX here. On the other hand PhysX 3.3 seems to be once again measurably faster than the other libraries, even in these simple scenes.
But let’s see what happens with more complex scenarios.
—-
The next scene (“SphericalJointNet”) creates a large grid of sphere objects connected by spherical joints, creating a “net” falling down on a larger static sphere.
The resulting curves are interesting. 2.8.4 and 3.2 don’t like this test much, and there’s a big spike when the net touches the large static sphere – which does not appear neither in Bullet nor in 3.3.
I believe this spike is related to broadphase. By nature the SAP algorithm doesn’t really like artificial scenarios with perfectly aligned grid of objects, and when the first collisions occur it probably creates a lot of useless swaps within the internal sorted arrays. In any case this is the scenario I used in this test, bad luck. This is a fair game and I’m not going to edit the scene just to hide this.
I believe Bullet doesn’t spike here because I used its “dbVt” option by default (instead of SAP). And PhysX 3.3 doesn’t spike simply because we improved the SAP there quite a bit – in fact, IIRC we used PEEL and this very scene to identify the problem and work out a fix.
Anyway, if we ignore this initial broadphase problem and focus on the second part of the curves (which is when the net has wrapped itself around the large sphere), we can see what the joint-performance looks like. And we find our “expected” results again: each version of PhysX is a bit faster than the previous one, while Bullet remains noticeably slower.
Kudos to Bullet in that one nonetheless, for avoiding falling into the broadphase trap setup in that test.
—-
The final scene (“Ragdolls_256_OnTerrain”) spawns 256 ragdolls on a massive landscape. Each ragdoll has 19 bones and 18 joints. They are spawned at different altitudes to make sure we don’t hit a pathological case in the broadphase. The landscape is made of 256 chunks, for a total of 492032 triangles.
The PhysX 2.8.4 and PhysX 3.2 curves intersect in that one, with 2.84 being a bit faster in the first part, and then slower in the second part. The average time is pretty similar for both.
Then there is PhysX 3.3, which is clearly faster (with or without PCM), and Bullet which is clearly slower.
