Coder Corner

After GDC 2016 some people asked me about this video:

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

I didn’t know this engine, but some googling revealed that it has been around since 2014 at least:

http://forum.unity3d.com/threads/ape-advanced-physics-engine-for-robust-joints-and-powerful-motors.259889/

First: welcome! Physics is fun and one more competitor is always healthy for end users. Also, your engine looks very nice so far.

Second: unfortunately your claims are slightly misleading and perhaps a bit unfair.

It is certainly correct that the PhysX joints are not perfect. It is certainly correct that PhysX does not handle high mass ratio differences very well. But that is just a side effect of using iterative solvers instead of the real thing. You can use PEEL to verify that Havok, Bullet, Newton, etc, all suffer from the same issue.

But this was not a random design decision, or something that we did not expect. We all started with “perfect” solvers a while ago (NovodeX 1.0 for example). They would solve everything by-the-book and behave much better in the presence of large mass ratio/etc. Unfortunately they were also very slow, and the customers didn’t care about accuracy. They cared about performance, and memory usage. To this date, most customer requests and feedback we get are still about exactly that: it’s never fast enough, and it’s always using too much memory. On the other hand, games get away with inaccurate solutions and imperfect solvers all the time, because they don’t use complex physics. Iterative solvers work fine for ragdolls, and most games don’t use more complex physics than that. So they don’t want to pay the price for a proper solver, when a cheaper one does the job just fine.

Now, when that solver is indeed not enough, we usually have dedicated solutions to specific problems. For example characters will use a character controller module. And vehicles will use a dedicated vehicle library. Contrary to what I read at least twice on different forums, recreating a car using rigid bodies connected by joints will not give you the “most realistic” vehicle, far from it. If nothing else, tires are not rigid bodies at all. If you want the most realistic driving behavior, you need a dedicated simulation just for the tire model (as they did in Project Cars for example). Using raycasts is not a problem per-se, because the contact information it gives you is in fact pretty much the same as what a rigid body cylinder would give you: contact point(s) and normal(s). Contrary to what people claim, PhysX is perfectly capable of simulating a “monster truck”. In fact, we were the first ones simulating a monster truck with rigid bodies connected by joints, back in 2002 with NovodeX 2.0. (And we also did the tank-with-hinge-joints in Rocket, remember?). But we eventually dropped that approach because it is too crude, it doesn’t give you enough control over the driving behavior, and ultimately it does not look realistic enough. The current PhysX vehicle library is way more advanced, with models for the gearbox, clutch, suspension, wheels, anti-roll bars, and so on. It is not easy to use and we don’t have a good demo/sample for it, but the resulting cars are quite fun and pleasant to drive - much more than the NovodeX monster truck ever was. I’m not saying that as the PhysX guy, I’m saying that as the guy who logged hundreds of hours in the Forza games.

It is the same for joints. Most game physics engines have an extra dedicated solution for articulated systems, because they are perfectly aware that regular joints won’t work well there. Thus if you are trying to do an articulated character, there is a dedicated solution in PhysX called, well, “articulations”. There are equivalent solutions in Havok/Bullet/etc. Somebody pointed this out in the forum thread above but it was ignored, maybe because it didn’t fit the desired narrative.

I am not saying that the current PhysX articulations are a perfect solution to all problems (they certainly have their limitations as well), but if you are not even trying them then you are comparing apples to oranges. Just to prove my point I went ahead and recreated one of the scenes in PEEL (I might try other ones later). The forum thread says:

“If you tried this kind of setup with PhysX you should have known that PhysX can’t sustain this sort of load and complexity.”

This is wrong. It works just fine, as long as you use articulations:

Rope on a hanger

To be fair and to give you the benefits of the doubt, it is true that Unity does not expose articulations to their users, so this was probably not possible to try there.

However, even with regular joints, you can get much better results than what got presented. For example here is a short list of things to try to improve ropes:

• Reduce the timestep. Using a better integrator is important for ropes, and reducing the timestep is a cheap way to achieve this. For example instead of doing 1 simulation call with timestep dt and 4 solver iterations per call, you can do 4 simulation calls with timestep dt/4 and 1 solver iteration per call. So it is cheap as in “easy to do”, not cheap as in “no performance impact”. It has an obvious impact on performance. But that is exactly why I recently tweeted that improving performance is equivalent to improving stability/accuracy: if you make your physics code 2X faster overall, you can suddenly halve your timestep (and thus improve the stability/accuracy) while keeping the same performance as before.
• Tweak the inertia tensors of rope links. Increasing the inertia will make the system less likely to explode, while often not making the simulation visually worse. In particular, look for the “PxJoint::setInvInertiaScale” functions in PhysX. It is certainly a hack, but it is a hack that has been successfully used in multiple AAA games that you played and enjoyed.
• Create an additional distance constraint between the start and the end of the rope. This helps for cases where the end of the rope is attached to a heavy object. This is again nothing new. See for example this idea being promoted to an explicit RopeJoint in Box2D: https://github.com/erincatto/Box2D/blob/master/Box2D/Box2D/Dynamics/Joints/b2RopeJoint.h
• Create N additional distance constraints, between the start of the rope and each of the individual rope links. This is a simple extension to the one above, also used in actual games.
• Create additional distance constraints between rope link i and rope link i+2. This is my favorite variation because it improves stability a lot while getting rid of some visual artifacts you may get with the other two versions. For example with the Box2D version a long chain can stretch and end up resting on the heavy object it is supposed to be pulling. That breaks the illusion big time.
• And then of course you can combine all of these together: smaller substeps, tweaked inertia tensors, additional distance constraints. At which point your scene may just work so well that you don’t even need articulations.

Yes, I realize that some people will consider this “cheating”. Well, game physics is a lot about cheating. Which brings me back nicely to what I was saying first: welcome! There is certainly room here for new engines that favor exactness over performance.

This entry was posted on Wednesday, April 6th, 2016 at 4:40 am and is filed under Physics. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.