Coder Corner

The torus in this video is made of several rigid convex objects connected by fixed joints. Since the joints are fixed, the ideal behavior would be that each torus acts like a rigid compound object (with no deformation). With iterative / approximate solvers however, what you get is that the torus appears quite flexible, and it deforms like a soft body. Sometimes that’s the effect you want to achieve. Sometimes not.

If it’s not, there are two ways to improve this, as demonstrated in the video.

The first way is to increase the number of position iterations in the solver. This is done by calling PxRigidDynamic::setSolverIterationCounts(), with a higher ‘minPositionIters‘ value. The default is 4 iterations, which is usually enough for regular rigid bodies, but often insufficient for jointed systems. As you can see in the video, increasing the number of iterations makes the torus much more rigid. This is a relatively cheap solution, since each iteration is quite fast in PhysX. For example even with 32 iterations as in the video, PhysX remains faster than some other engines which, while providing a more rigid behavior by default, are still slower overall. That is, 32 iterations in PhysX can be faster than 4 iterations in other engines, for roughly the same torus rigidity.

However, increasing the number of iterations affects the performance of the whole ’simulation island’ that the object ends up a part of. Thus, the actual cost can be a bit unpredictable.

There is then a second way to increase the rigidity of the torus: just create the same constraints (i.e. the same joints) multiple times. This is pretty much equivalent to increasing the iteration counts, but the cost remains local to the object. In isolation this is more expensive than the first solution, because the joints’ setup code is performed multiple times now. But it can be a faster approach overall, in the context of a full game.

And then you can of course do both: create the constraints multiple times and also increase the solver iteration counts.

Now, this alternative approach has some issues that should be mentioned. First, for obvious reasons creating the constraints multiple times will use more memory. And second, the effect will depend on the order in which the constraints are created. For example say you have constraints 1 to N, and you want to create them 4 times. If you create them from 1 to N and repeat the sequence from scratch 4 times, it will work better than creating 4 times the same constraint before switching to the next. In other words, 1234..N1234..N1234..N1234..N is better than 1111222233334444..NNNN. This is semi-obvious but worth pointing out. For the same reason, this trick does not work equally well in all physics engines: some of them reorder constraints in arbitrary ways, etc. You can use PEEL 1.1 to check and explore how different engines react to this approach.

If you create rigid bodies in an initially overlapping state in PhysX, you can get a violent reaction like the one in this video.

There are two ways to improve this, as demonstrated in the video.

The first way is to increase the number of velocity iterations in the solver. This is done by calling PxRigidDynamic::setSolverIterationCounts(), with a higher ‘minVelocityIters‘ value. The default is just 1 iteration, which is usually enough - but not when objects are overlapping. As you can see in the video, increasing the number of iterations gets rid of the explosion.

However increasing that number has a performance cost. And it is not always a good idea to increase that number for jointed systems.

So there is a second way, which is to setup a “max depenetration velocity” for the rigid body, using PxRigidBody::setMaxDepenetrationVelocity(). By default this is unlimited. In practice, limiting the depenetration velocity (e.g. to “3.0″ in the video) gets rid of the explosion, and it is much cheaper than increasing the solver iteration counts.

Visually this makes objects slowly move away from each-other until the penetration is resolved. This typical behavior can be seen in other engines like Havok.

Note that reducing the timestep does not improve the results here. The opposite happens: reducing the timestep makes the explosion even more violent, which is perhaps counter-intuitive. This is because PhysX tries to resolve the overlap in a single simulation call, and to move the object over the same distance in a shorter amount of time, it has to apply a larger force. So everything being otherwise equal, you get a more violent explosion.

Also, limiting the depenetration velocity can sometimes lead to thin objects passing through each other more easily, when they’re constantly pushed against one-another. It is easy to tweak on a per-object basis though, so generally speaking it is a good idea to limit the depenetration velocity.

In PhysX, the angular velocity of dynamic bodies is limited and clamped to a user-defined “max angular velocity”. But the default value for it is a bit peculiar.

It’s 7.

Not 5 or 10 or 100. Just 7.

Why 7? Why not 8 or something else? This goes back all the way to NovodeX 2.0 and the story behind this specific value is not clear to me anymore. If I remember correctly it had to do with the lack of angular CCD (Continuous Collision Detection) in NovodeX: clamping the angular velocity to some low value seemed like a cheap way to prevent angular CCD issues. Or so we thought. It probably looked like a good idea at the time, but of course in retrospect, it wasn’t. Because this value is way too low - and no, I don’t remember why we picked “7″ in particular.

If you create a test scene for gyroscopic effects, like the one in this video, that default value prevents the objects from rotating, and you don’t get the expected behavior. Somehow this looks just as bad as CCD issues.

However, and fortunately, it is easy to change. For each body, call PxRigidDynamic::setMaxAngularVelocity() with a new, higher velocity limit (I used “100″ in the video). And suddenly the objects keep spinning and the scene works as expected. Problem solved!

For some reason we never updated that value. From NovodeX 2.0 to PhysX 3.4, the default max angular velocity is 7. I suppose we don’t modify it because we want to make sure that nothing breaks or changes in unexpected ways for users upgrading to a new version - as much as possible at least. We can be a bit paranoid and extreme about that kind of stuff. Do. Not. Break. People’s. Working. Code. (*)

(*) yeah I know, it didn’t always work out

EDIT: the default max angular velocity has finally been increased to 100 in PhysX 4.0.

A “pre-release” version of PhysX 3.4 has been posted on GitHub. It will be called a pre-release until around GDC this year, but there shouldn’t be many changes going in till then - basically just bug-fixes if / when customers report issues.

So for all intents and purpose, that’s basically PhysX 3.4.0’s source code, available right now. The architecture has been completely revisited since last year, to make everything work with GPU rigid bodies. If you wanted to play with “GRB”, now is your chance: it’s now tightly integrated within the usual PhysX library.

By default everything runs on the CPU as usual. But with just a few parameters to change in the scene descriptor, things can now run on the GPU instead.

Reminder: there is no binary release anymore. You must build the code yourself (*). To get access to the source code, follow the instructions here.

After that, you get access to regular GitHub repositories for either PhysX 3.3, or now for PhysX 3.4.

Note: the links will show a 404-error until you get a registered account.

(*) EDIT: except for the GPU DLL, which is only shipped as binary for now.

Trying stuff.

I don’t know how many times I had this discussion so I’ll just write it here once.

No, you do not get the most realistic vehicles using vanilla rigid bodies + joints, and it is pointless to implement the Coulomb friction model perfectly because it is only a model, and it does not work well for tires.

See here for example.

You need to use a dedicated vehicle SDK, like the one in PhysX. Using perfect rigid bodies and joints, with a perfect solver, implementing perfect Coulomb friction, will not give you a perfect car simulation.

Another cool one, just because.

Looks interesting.

Let’s debunk some more.

—

Trying out some more of the APE’s scenes. PhysX version is here. Original is here.

I didn’t put the crane itself yet but the cables are the hard part. Also I made the capsules thinner, to make it more difficult to simulate.

In the Unity thread you can read that:

“This new crane model was pushed to the extreme with the following modifications:

1) Reduce from 5 ropes weight attachments to 4 ropes
2) Increased the main rope’s length for an additional 5 segments
3) Increased the mass ratio between a single rope segment and the cargo box to 1:1000. No commercial physics engines I’ve used before handle such HUGE mass ratio between joined rigid bodies. The common guideline from PhysX and Havok is less than 1:10. Literally you’re lifting a ton with a kilogram ! This is probably overkill for most games. However if you do want to simulate extremely heavy weight sensation, here you go!”

So the mass ratio is 1000:1 in my test, and as you can see it works just fine. You simply must use the right PhysX feature (articulations) for the job.

—

Bonus:

I was at the playground with my kid and we were doing this with the swing set. I wondered if it would work in PhysX. It did

Capsules have a mass of 1. The box has a mass of 1000. Timestep is 1/60. This is again using PhysX’s articulations feature.

It somehow reminds me of these “rubber effects” we did in demos on the Atari ST

Trying out more of the APE scenes.

https://www.youtube.com/watch?v=8TZ9_B_tvLk&feature=youtu.be

What I said before for ropes still apply: it is correct that you don’t always get something working flawlessly out of the box, but that’s more a side-effect of the iterative solver than a bug or defect in the software. And most importantly, there are often several ways to make things work anyway. I think the APE guys didn’t try very hard because in this case it took 3 API calls to make things work better:

j->setProjectionLinearTolerance(0.0f);
j->setProjectionAngularTolerance(0.0f);
j->setConstraintFlag(PxConstraintFlag::ePROJECTION, true);

The video is using regular joints. But I suspect that, as for ropes, this is a case for the articulations feature. They probably would give even better results - I may try later.