Coder Corner

I used the new reduced coords articulations for a vehicle in my recent Youtube video but we already had a multibody vehicle using Featherstone articulations back in 2002.

https://www.youtube.com/watch?v=QJVra8LGDeE

PhysX tip: in 4.0 there is support for torsional friction, to help robots grasp objects. See PxShape::setTorsionalPatchRadius() and PxShape::setMinTorsionalPatchRadius().

PhysX tip: “position” iterations and “velocity” iterations are not equally important. My rule of thumb as a user: don’t bother increasing the velocity iters, leave it to 1. Focus on the position iter only. 4 for regular bodies and 16 or 32 for jointed objects give good results.

PhysX tip: are you calling simulate() multiple times per frame? Maybe for sub-stepping? Then you can use the newly introduced PxSceneQueryUpdateMode enum to only update the SQ system in the last substep. That can make “fetchResults” faster for the N-1 first substeps.

PhysX tip: pass a scratch memory block to the simulate() function! Even if it’s just 16 or 32K, it will help reducing the amount of temporary allocations. Just do it. Now.

PhysX tip: beware of the default “contact distance” param for joint limits. By default it’s setup for performance rather than sim quality, and it ignores limit-related constraints until you’re about to reach them. Instead, set them up so that limits are always “active”.

PhysX tip: D6 or dedicated joints? The dedicated joints like PxRevoluteJoint can be a wee bit faster on the CPU because their “solver prep” functions are simpler. But only D6 joints are fully-accelerated (joint shaders running on the GPU). Minor bit of trivia that you can ignore.

PhysX tip: the number of solver iterations is a per-actor parameter in PhysX. It is NOT a global parameter. So you can e.g. use 32 iterations for jointed objects and 4 for debris, in the same scene.

With PhysX 4.0 / PEEL 2.0.

Jacob’s Ladder test

Can you tell I’m an ex-demomaker ?

PhysX 4.0 in PEEL 2.0