Coder Corner

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: speaking of fetchResults(), don’t forget PxSceneDesc::dynamicTreeRebuildRateHint. Increasing that value can make fetchResults() faster. YMMV here but you can often increase this to 10x the default value without issues.

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

https://news.developer.nvidia.com/announcing-physx-sdk-4-0-an-open-source-physics-engine/

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