Coder Corner

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.

Speaking of PhysX joints and ropes…. It can do that.

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.

Conventional wisdom says that you should use a profiler, find the bottleneck, optimize the bottleneck, repeat until the profile is flat.

Conventional wisdom says that you should not waste time with minor optimizations that won’t make a dent in the framerate. The gains must be “significant” to justify the time and effort spent optimizing.

Oh fuck off now. Conventional wisdom is stupid.

In terms of optimization I usually say that “everything matters”. All the minor insignificant gains eventually add up to something very valuable in the end. I’ve seen it on the ST. I’ve seen it on PC. I’ve seen it (a lot) on consoles.

And I just saw it again today. Here’s what 3 months of insignificant optimizations look like when you ignore conventional wisdom and keep doing them anyway. First changelist was at the end of last year, last changelist was last week. Scene is “ConvexGalore2″ in PEEL (bunch of convexes falling in a pile).

Granted: there is in fact a “significant” optimization in there that accounts for 1/3 of the gains. But the remaining 2/3 are from supposedly insignificant ones.

And that’s not even an April Fools joke