PhysX Rigid Body Dynamics Engine
NVidia physX is a rigid body dynamics engine that shares a geneology with ODE (both were largely written by ex-MathEngine employees) as well as many architectural similarities. However, physX is a much more mature engine, with a fully fleshed-out API, and contains several important features that ODE lacks.
- physX contains convex hull collision primitives which allows a stable approximation of arbitrary trimeshes.
- physX implementes a penetration map based actual shape collision volume which allows more stable trimesh/trimesh collisions than are possible in ODE
- physX is much more stable for large scenes, and handles interpenetration more gracefully.
Ageia has plans to incorporate a particle-based fluid simulation into their engine, as well as (eventually) soft bodies and cloth simulation.
Answers to Some Questions
Here are some answers to questions that have come in from customers:
How do ODE and physX compare in terms of functionality (quality of simulation, speed, misc. details) and integration in XSI? For example, are there some things which might be better done using one vs. the other?
Both ODE and physX are equally well integrated into XSI. That is, there is no major functionality that is missing from one as compared to the other, the workflow is identical, and simulations built using one engine can be converted to the other with a single click. However, because physX is a superior physics engine (more on that later), simulations built with physX are far less likely to require parameter tweaking in order to be stable. So, in practice, the physX workflow will be superior.
As far as the technical merits of physX versus ODE, the only ways in which ODE is superior to physX are that:
- ODE is free, which can be very important to small game developers
- ODE is cross-platform and, because the source is open, can be changed to compile on any platform a developer needs. For example, Cyan Worlds recently used ODE for Myst V because Havok did not support the Macintosh.
- ODE is open source. For puposes of cross-platform compatibility as well as adding new, or altering existing, functionality this openness is crucial.
However, in just about every other way physX is superior. The "bullet points" are:
- physX uses a faster physics integration algorithm, which allows the stable simulation of many, many more colliding objects than ODE. We're talking tens of thousands rigid bodies for physX, versus maybe 50 for ODE.
- physX is more stable than ODE. This is related to the superior integration technique that physX uses, but the upshot on the user side is that deeply interpenetrating objects do not fly apart at a zillion miles an hour; difficult collisons (for example, an object pinched between two other objects) can be resolved cleanly, and large piles of highly constrained rigid bodies (a pile of hundreds of ragdolls, for example) will be stable and not twitch around.
- physX has convex hull collision types, as well as a very stable and accurate actual-shape collision type. ODE's actual shape collision handling is "heuristic" (to put it politely) and fails when more than a few actual-shape objects are colliding with each other simultaneously.
The only scenarios I can see a customer wanting to use ODE in XSI is if they have already committed resources to ODE (for example they were in mid-production when XSI version 5.0 was released) and wish to continue using their old scenes and simulations. In all other cases, physX is superior and should be used (it will be the default physics engine in XSI).
physX will also be able to take advantage of the physX PPU boards. Aegia is a little cagey on details, but it seems highly likely that the version of physX that XSI will ship with will be able to take advantage of these cards when they begin selling them next year. It's hard to say exactly, but in medium to large scenes (500 or more rigid bodies), there should be maybe a 30-50% speedup of simulation in XSI. We will have better numbers once Aegia gives us some boards to test.
Do we have any recommendations on how to use physX in XSI to leverage its fullest potential?
I'm not quite sure what you mean, but in terms of authoring and interacting with physX, XSI has the best integration of physX into a digital content creation package, bar none. Even though the physX guys themselves have been working on a Max plugin for physX, it is nowhere as mature and full-featured as ours. So, if a customer is interested in using physX in a game, XSI is the way to go, absolutely. Any scenes created in XSI should simulate exactly the same with physX on a game console or PC. You will be able to export data not only as a Collada file, but also in physX's proprietary "core dump" format, which will allow easy data interchange. (Importing of physics scenes will only be available through Collada, dotXSI and so forth; the core dump format is write-only.)
Do closed meshes (solids) perform better with actual shape collisions than open meshes?
The only difference between open and closed meshes is that an open mesh will be seen by XSI as an extremely thin sheet (roughly 0.01 SI units), so it will be easy to get bullet-through-paper collision problems. By contrast, a closed mesh will be seen as being solid, and thus thick. Beyond this, there is no fundamental geometric reason why a closed manifold will generate better data than an open (non-manifold) mesh.
There are two other possibile causes for the bad collisions one might see with an open mesh:
- The grid was not finely tesselated enough. The code that generates the actual shape collision data eats complex geometry for breakfast. Loves it. So highly tesselated (within reason) geometry is better. For example, the default grid (8x8 subdivisions) does not collide well with an actual shape torus (default), but upping the subdivisions of the grid to 24x24 fixed the problem.
- Not enough simulation substeps were used. Actual shape objects can slide through each other if you're not using a small enough time step, and this is especially bad with open meshes (bullet and paper, again). Using the 24x24 grid, 4 substeps showed a little interpentration, but 10 showed none.
In short, with a little tweaking open meshes should work fine with actual shape collisions. For example, here is a scene here where I created a bowl by cutting a sphere (16 by 16 subdivisions) in half, and drop roughly 500 small convex hull objects into it with no fall-through or penetration problems. I am using default material parameters and 16 substeps a frame.
Other questions (and their answers) can be found in the Knowledge Base under Simulation.