In my previous posts I mentioned some R&D code I wrote for large stable stacks. I can’t talk much about the algorithms involved, for obvious reasons, but I can share a small proof of concept demo.
(Note: don’t let the “CUDA Test” title fool you, it’s all CPU)
Looks like this blog doesn’t render properly in Internet Explorer. Oh well, no idea why. Use Firefox.
I got a bunch of questions about my last series of blog posts so I thought I’d add a quick note here - at the risk of confusing people even more.
The figures I posted are for the CPU part of PhysX only. This does not concern or affect the GPU parts of PhysX in any way. Those things are orthogonal. If we optimize the CPU parts and get a 10X speedup, it does not mean your GPU will suddenly provide 10X less value, because it is running others parts of PhysX anyway - neither the rigid bodies, nor the raycasts/sweeps.
Only a few features are GPU-accelerated, e.g. cloth or particles, mainly because they are the ones that map well to GPUs, and they are the ones for which the GPUs provide real X factors.
Now as shown in the recent “destruction video” I posted, people here are also working on GPU-optimized rigid bodies. This new module is called “GRB”, and it is currently not part of PhysX. But it does provide a speedup compared to our current CPU solution. In other words, it is still faster than PhysX 3.3 on CPU. You might have a hard time believing it, but people are trying to be fair and honest here. One of our tasks is to optimize the CPU rigid bodies as much as we possibly can, just to make sure that the GPU rigid bodies do provide some actual benefit and speedups. If you don’t do that, you release your GPU solution, it’s slower than a CPU solution, and you look like a fool. Like AGEIA. We are not making that mistake again. The CPU solution is here as a reality check for ourselves. I suppose we could just use Bullet or Havok for this, but… well… we think we can do better 
Meanwhile, it is correct that the features that do work on GPU are currently only working on NVIDIA cards, simply because they are implemented using CUDA. There are both obvious political and technical reasons for this. It should be pretty clear that at the end of the day, NVIDIA would like you to choose one of their GPUs. If you are actually complaining about that, then there is little discussion left to have. Of course they want to sell their products, like every other company in the world. And of course they are going to use their own technology, CUDA, to do so. To me this is pretty much the same as what we had in the past with D3D caps. Some cards supported cubemaps, or PN-triangles, or whatever, and some didn’t. GPU PhysX is the same. It’s just an extra cap supported by some cards, and not by other. Complaining about this is silly to me. It would be like complaining that ATI didn’t make any effort to make PN-triangles work on NVIDIA cards. Seriously, what?
The deal is simple. NVIDIA gives you a free, efficient, robust physics engine. In exchange, if possible, add some extra GPU effects to give people an incentive to buy NVIDIA cards. Fair enough, right? I don’t see what the fuss is all about.
—-
Anyway, the usual disclaimer applies here: I’m not a spokesperson for NVIDIA, what I write are my own thoughts about it, and for all I know I may be completely wrong about their intentions. What I know for a fact though, is that most of the stuff I read online about PhysX is just completely insane wrong.
I’ve been optimizing rigid body simulation in NovodeX/PhysX for a long time now, and there’s no big conspiracy behind it. Again, all those engines are free and publicly available so I invite you to run your own experiments, do your own benchmarks, and see for yourselves. We really have nothing to hide.
Part1: PEEL
Part2: Rigid bodies (box stacks)
Part3: Rigid bodies (convex stacks)
Part4: Rigid bodies (piles)
Part5: Rigid bodies (compounds)
Part6: Rigid bodies (meshes)
Part7: Joints
Part8: Raycasts vs simple shapes
Part9: Raycasts vs meshes
Part10: Sweep tests
Part11: More sweep tests
Part12: Final test and conclusion
This last test (“SeaOfStaticBoxes3”) didn’t fit in any category, so I kept it for the end. It does not actually do anything, it only creates a massive amount of static boxes (255*255). There is otherwise no dynamic objects in the scene, nothing to simulate at all.
There are 2 things to notice here. The first one is memory usage. We went from 94Mb to 54Mb to 39Mb, from one PhysX version to another. That’s the right direction here!
The other thing is the time it takes to simulate an empty scene. As you can see, it doesn’t take much time with PhysX – as it should. Bullet however, for some reason, takes a massive amount of time here. On my home PC, Bullet takes about 34ms (!?) to simulate this empty scene. I double-checked everything, looking for something I did wrong, but it turns out the problem has already been reported on the Bullet forums. I think this should be fixed and work out-of-the-box.
In any case, I am not here to fix Bullet issues. The point is simply, again, that contrary to what people may still believe, PhysX is actually very optimized and a perfectly fine CPU physics engine. In fact, if some competitors would not prevent me from publishing the results, I would happily show you that it often beats everybody else. I invite curious readers to create their own benchmarks and see for themselves.
—-
This report is currently incomplete: it did not talk about CCD, or multithreaded simulations, or overlap tests. It also barely scratched the surface of what these physics engines have to offer: I did not talk about character controllers, vehicles, the performance of binary deserialization, or any of those more advanced topics.
As you can easily imagine, I’d need to write a book to cover all this, not just some blog posts.
However I think these posts may reach their limited goal, which is simply to show with very basic tests that:
Now that we’re done with the simple stuff, let’s jump to the next level: meshes.
The first mesh scene (“SceneBoxSweepVsStaticMeshes_Archipelago”) performs 1K vertical box sweeps against the mesh level we previously used.
There are no terribly big surprises here. All engines report the same number of hits. Each PhysX version is faster than the one before. They all perform adequately.
PhysX 3.3 is only about 2X faster than PhysX 2.8.4, so things were generally ok there.
Bullet suffers a bit, being a bit more than 6X slower than PhysX 3.3 on average.
—-
For the next tests we switch back to the Konoko Payne level, which is much more complex and thus, maybe, closer to what a modern game would have to deal with. We start with sphere-sweeps against it (“SceneSphereSweepVsStaticMeshes_KP”).
Results are quite similar to what we got for the Archipelago scene: PhysX gets faster with each new version, 3.3 is a bit more than 2X faster compared to 2.8.4.
Bullet suffers again, being now a bit more than 8X slower than PhysX 3.3 on average.
—-
The same test using box-sweeps (“SceneBoxSweepVsStaticMeshes_KP”) reveals the same kind of results again.
This time PhysX 3.3 is about 3.3X faster than 2.8.4.
Remarkably, PhysX 3.3 is more than an order of magnitude faster than Bullet here (about 11.6X)!
—-
Finally, the same test using capsule-sweeps (“SceneCapsuleSweepVsStaticMeshes_KP”) confirms this trend.
PhysX 3.3 is a bit more than 2X faster than 2.8.4, once again.
As for Bullet, it is now about 15X slower than PhysX 3.3. I feel a bit sorry for Bullet but I think this proves my point: people who claim PhysX is not optimized for CPU should pay attention here.
—-
Now the KP scene, as you may remember from the raycasts section, has a lot of meshes in the scene but each mesh is kind of small. We will now test the opposite, the Bunny scene, which was a scene with just one highly-tessellated mesh.
And since we are here to stress test the engines, we are going to run several long radial sweeps against it.
And using large shapes to boot.
This is not supposed to be friendly. This is actually designed to break your engines.
So, what do we get?
—-
Let’s start with the spheres (“SceneSphereSweepVsStaticMeshes_TessBunny”).
Note that we only use 64 sweeps here, but it takes about the same time (or more) than performing 16K radial raycasts against the same mesh… Yup, such is the evil nature of this stress test.
It is so evil that for the first time, there really isn’t much of a difference between each PhysX versions. We didn’t progress much here.
Nonetheless, PhysX is an order of magnitude faster than Bullet here. Again, contrary to what naysayers may say, the CPU version of PhysX is actually very fast.
In fact, stay tuned.
—-
Switch to capsule sweeps (“SceneCapsuleSweepVsStaticMeshes_TessBunny”). Again, only 64 sweeps here.
There is virtually no difference between PhysX 3.2 and 3.3, but they are both measurably faster than 2.8.4. Not by much, but it’s better than no gain at all, as in the previous test.
Now the interesting figure, of course, is the performance ratio compared to Bullet. Yep, PhysX is about 25X faster here. I can’t explain it, and it’s not my job. I’m only providing a reality check for a few people here.
—-
Ok, this is starting to be embarrassing for Bullet so let’s be fair and show that we also blew it in the past. Kind of.
Switch to box sweeps (“SceneBoxSweepVsStaticMeshes_TessBunny_Test1”). And use fairly large boxes because it’s more fun. Again, we only need 64 innocent sweep tests to produce this massacre.
Look at that! Woah.
“Each PhysX version is faster than the one before”, hell yeah! PhysX 3.3 is about 4X faster than PhysX 3.2, and about 31X faster (!) than PhysX 2.8.4. Again, if you are still using 2.8.4, do yourself a favor and upgrade.
As for Bullet… what can I say? PhysX 3.3 is 123X faster than Bullet in this test. There. That’s 2 orders of magnitude. This is dedicated to all people still thinking that PhysX is “not optimized for the CPU”, or “crippled”, or any other nonsense.
—
The final test (“SceneLongBoxSweepVsSeaOfStatics”) has a pretty explicit name. It’s just one box sweep. The sweep is very large, going from one side of the world to the other, in diagonal. The world is massive, made of thousands of statics. So that’s pretty much the worst case you can get.
The results are quite revealing. And yes, the numbers are correct.
For this single sweep test, PhysX 3.3 is:
Spectacular, isn’t it?
Another important feature is sweep tests, a.k.a. “linear casts” or “shape casts”. This can be used, for example, to implement character controllers. What I previously wrote for raycasts is even more valid for sweeps: a lot of things depend on whether you go for a generic GJK-based sweep, or for dedicated shape-vs-shape sweep functions. And since sweep functions are usually much more difficult to write than raycast functions, this is often the part of physics engines where things sometimes go spectacularly wrong.
There are even more potential things to test here, than for raycasts. Even when you go for customized raycast functions, you get away with N of them (e.g. for N supported shapes you need to write N raycast functions). For sweeps however, you can decide to sweep any shape against any other, so you suddenly need to write N*(N-1)/2 functions, and each of them is a lot harder than just a raycast. This is why most engines just go for a generic GJK-based sweep function, which can be used as-is for all cases. The downside of this is that the generic code, as often, may not be as fast as a customized function.
But enough theory: let’s see what we get. I will only focus on a small set of selected tests, rather than tediously listing the results for all N*(N-1)/2 cases.
—-
Our first scene (“SceneBoxSweepVsStaticSpheres”) uses the same array of spheres as our initial raycast test. But instead of doing a raycast against each of them, we do a box sweep. We are again using the scene-level API functions to do so.
The boxes are slowly rotating over time, to make sure that we hit all codepaths from the sweep functions, and just to make sure that things don’t suddenly break for some angle, for some reason.
The results are a bit different than usual. Each PhysX version is faster than the one before… kind of. This time there isn’t much of a difference between 2.8.4 and 3.2. It looks like 3.2 is a wee bit faster, but frankly that might be just noise at this point.
Bullet looks fine in this test, very similar to PhysX 2.8.4 and 3.2, although slightly slower. The profile curve also isn’t as smooth as for PhysX but overall it’s quite comparable.
The clear winner in this test though, is PhysX 3.3. It is about 3X faster than both Bullet and the previous PhysX versions. Nice.
—-
Let’s stay with box-sweeps, but let’s try against static boxes now (“SceneBoxSweepVsStaticBoxes”).
Things are a bit different this time: Bullet is faster than 2.8.4 is that test. On the other hand it is slower than PhysX 3.x.
Each PhysX version is faster than the one before – checked. In fact, on average, each PhysX version is 2X faster than the one before. That’s quite something!
—-
Ok we did box-sweeps vs spheres and boxes, let’s see what happens against capsules in the next test (“SceneBoxSweepVsStaticCapsules”).
PhysX 3.x is significantly faster than PhysX 2.8.4 – with again each PhysX version being faster than the one before. In terms of relative performance there’s a remarkable 6.7X speedup on average between 2.8.4 and 3.3. Nice.
Bullet has about the same performance as 2.8.4, with again a much more chaotic curve. But PhysX 3.3 is about 8X faster than Bullet on average here.
—-
Now, you guessed it, after spheres, boxes and capsules, and in sake of completeness, let’s have a look at box-sweeps against convex objects (“SceneBoxSweepVsStaticConvexes”).
Wo-ah. Now that is a surprise! See, that’s what I what talking about: sometimes things can go spectacularly wrong with sweeps, and you really need a strong test suite to make sure you catch all those problems.
Clearly the 2.8.4 code had a problem here. I can’t remember what it was, but clearly, if you are still using 2.8.4 and you do a lot of box-sweeps against convexes, you seriously need to upgrade. On average, PhysX 3.3 is 34X faster than 2.8.4 in this case. Now that is some serious speedup.
Other than that, each PhysX version is faster than the one before (good), and contrary to what we saw just in the previous test, Bullet remains quite competitive here, even against PhysX 3.3.
So, that’s sweep tests. You never know until you actually profile.
—-
Now, we could repeat this exercise for sphere-sweeps and capsule-sweeps against all the other shapes as we just did for boxes, but the results are very similar. The only surprise comes again from the capsule-vs-convex case (“SceneCapsuleSweepVsStaticConvexes”).
In short, this is the same as for box-vs-convex: 2.8.4 was pretty bad here. On average, PhysX 3.3 is 17X faster than 2.8.4 in this case.
Bullet’s profile curve is weird. I can’t explain why it suddenly becomes faster towards the end. It is probably related to the fact that the capsules are rotating, and the algorithm may switch from one case to another, but I don’t know the Bullet’s internals enough to tell.
Now, simple shapes are one thing but as for rigid body simulation, what really matters are triangle meshes. So let’s start the serious tests.
The first scene involving meshes (“SceneRaycastVsStaticMeshes_Archipelago16384”) does 16K vertical raycasts against the Archipelago mesh level.
No big surprise here. All engines find the same number of hits. On the right side of the screenshot you can see all the rays that missed the mesh level. It’s all correct.
Each PhysX version is faster than the one before. Bullet is the slowest but remains competitive (“only” about 2X slower than 3.3 here).
—-
The next scene (“SceneRaycastVsStaticMeshes_TessBunny16384”) does again 16K raycasts, but this time they’re radial rays instead of vertical, and we cast them against a single highly tessellated mesh (yes, I guarantee you there is a mesh underneath that mass of raycasts :))
Using a single highly tessellated mesh means that this test stresses the “midphase” structure from that mesh, rather than the scene-level structure. Using radial rays means that engines not using node sorting in the tree traversal will be disadvantaged.
As before, each PhysX version is faster than the previous one. Bullet is slowest, and about 4X slower than 3.3.
—-
The next scene (“SceneRaycastVsStaticMeshes_KP16384”) is the opposite of what we just tested: it now contains a lot of small meshes, none of them having a lot of triangles. So the test stresses the scene-level “broadphase” structure, more than the individual “midphase” mesh structures.
The scene is just the mesh level from Konoko Payne: it contains 4104 meshes, for a total of 592267 triangles. We perform 16K radial raycasts again, from a random position deep inside the level.
The results are in line with what we saw so far. Each PhysX version is faster than the one before. Bullet is slowest, about 4.7X slower than 3.3 on average.
—-
I repeated the same test from another initial ray position in the level, to see if we got the same results (“SceneRaycastVsStaticMeshes_KP16384_2”). This time some of the rays hit a mesh, some don’t.
Each library (pretty much) reports the same number of hits, that’s good.
Each PhysX version is faster than the one before, that’s good.
Bullet is slowest, about 3.47X slower than 3.3 on average. It’s slightly better than before but not exactly fast. Still, I wanted to see if the better performance was due to the rays not hitting anything, so I created a last test in the same scene, where none of the rays hit anything (“SceneRaycastVsStaticMeshes_KP16384_NoHit”).
But it did not change much of the results. Bullet is still slowest, and about 4X slower than 3.3. Well these are pretty consistent results at least.
—-
The final test for this section (“Terrain_RT”) is a raytracing test against a large terrain (the same terrain we previously used for the ragdoll test).
Compared to the KP scene the mesh level is different, the raycasts are neither radial nor vertical anymore, but the results are quite similar to what we saw so far.
All engines find the same number of hits, that’s good. Each PhysX version is faster than before, that’s good. PhysX 3.3 is again a bit more than 2X faster than 2.8.4, and a bit more than 4X faster than Bullet.
Well, contrary to what people may say on the Internet, we do optimize our code for the CPU.
Measuring performance of rigid body simulation is important. But the dark secret of game physics, if you ask me, is that it is not actually the most important part. The most important and far more useful features for a game are simple collision queries like raycasts and sweeps. So let’s see what we get here.
There’s really an army of tests that one could create here, to stress and benchmark various parts of the system. For example for raycasts, like for contact generation, you usually have a choice between using a generic piece of code to implement all your raycasts (e.g. GJK), or you bite the bullet and implement a dedicated raycast function for each shape (e.g. ray-vs-box, ray-vs-sphere, etc). If you do so, one of these functions may be particularly slow compared to the others, e.g. ray-vs-convex-mesh, and thus you’d need a dedicated test scene to discover this.
PEEL does contain a test scene for each case. But I am not going to report all of them here, since at the end of the day they’re mostly saying the same thing. The following, thus, is only a selected subset of the tests implemented in PEEL.
—-
The first scene (“SceneRaycastVsStaticSpheres”) is as simple as it gets. There’s a bunch of static spheres and we do a raycast against each of them, via the scene-level API. This is important: most physics engines also allow you do raycast directly against the shape itself (bypassing the scene level). But we are interested in the generic raycast performance here, and a large part of that is related to traversing the scene-level structures. Hence, we use the scene/world-level API in all the following tests. (This also means that various local acceleration structures like phantoms in Havok or volume-caches in PhysX are ignored here. We could run some other tests some other day for those things).
In the collision-queries tests I excluded the second PhysX 3.3 build using PCM, since PCM has no impact at all on any of these queries.
Anyway, without further ado, here’s what we get:
The profile graphes in these tests is often very flat, since the rays are not moving, the scene is static, and thus we do exactly the same work each frame.
As usual the main thing we want to check is that each PhysX version is faster than the previous version. This is clearly the case here, good.
Bullet appears to be significantly slower (up to 3X slower than PhysX 3.3), even on this simple test.
—-
The second scene (“SceneRaycastVsDynamicSpheres”) is exactly the same, but we made all the spheres dynamic objects (and thus they are now falling under gravity). This is just to check whether this makes any difference in terms of performance. Turns out it does not, numbers are pretty much the same as before. This is why we will not bother with dynamic objects anymore in subsequent tests.
—-
Replacing the spheres with boxes or capsules gives similar results (Bullet < 2.8.4 < 3.2 < 3.3). However things change when replacing the spheres with convexes, as seen in our next scene (“SceneRaycastVsStaticConvexes”).
As I was just saying before, a dedicated ray-vs-convex raycast function might be slower than the other ones, and this is what we see here.
Each PhysX version is faster than the one before, that’s good.
Contrary to what happened for the other shapes, Bullet is faster than 2.8.4 in this case. It remains significantly slower than PhysX 3.x though.
—-
The next scene (“PotPourri_StaticRaycasts2”) creates a whole bunch of random shapes (spheres/boxes/capsules) at random positions in a cubic volume of space, and creates 20000 random raycasts in that space. The resulting screenshot admittedly looks like a giant exploding mess:
An interesting thing to note is that each library returns a different number of hits. This has to do with a number of things. First there is how each of them treats raycasts whose origin lies inside a shape. Some libraries like Havok do not count this as a hit, for example. Others may not give unified results in this case, i.e. maybe a ray starting inside a box gives a hit, but a ray starting inside a sphere does not. I did not investigate the details of it, but we clarified and unified all of these rules in PhysX 3.3.
Another thing that may contribute to the different number of hits is just FPU accuracy and what happens in limit cases. If the ray just ends on the surface of the shape, or if it just touches an AABB from the scene’s AABB-tree, this can be seen as a hit, or not. Using SIMD or not can also make a difference in these limit cases. Etc. In any case the results are approximately the same, and one could verify that they are indeed all “correct”.
Anyway, each PhysX version is faster than the one before – checked. PhysX 3.3 is about 2X faster than 2.8.4.
Bullet is again significantly slower, about 5X slower than 3.3.
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.
