RSS

A reader send me a link to the following video, which is an excerpt of an interview with physicist Brian Beckman. Here he discusses an upcoming indie / freeware game Rigs of Rods and talks a bit about what works and what doesn’t with physics engines.

But what’s really interesting here is the method they are using in this game. Beckman calls it “sticks and stones”. Now, this is a YouTube video of someone aiming a camcorder at a laptop, so I can’t be sure about what I’m seeing, but I’m fairly confident he’s using a technique I’ve used in the past, which is something I picked up playing the classic Bridge Builder game. (By the way, if you’ve never played Bridge Builder befoe, do check out that link. It’s simple, brilliant fun. And it’s free.) The physics in that game were pretty transparent, so I was able to learn a lot form just playing the game*. It used link points and joining lines, which I’m willing to bet is very close to the “sticks and stones” Beckman is using. (I’m sure the one in Rigs of Rods is a lot more robust, but I think they’re both driven by the same underlying ideas. Bridge Builder is actually 2D.)

I haven’t seen Rigs of Rods before, but I’ll be keeping an eye on it now. Fascinating stuff.

* I wrote my own version of Bridge Builder at one point, just to mess around with it. I didn’t bother making it a game – it was just a sandbox world. I added a couple of new tricks to the basic gameplay, such as rolling tires and cables, so that it was possible to build suspension bridges. It was a good learning project, which taught me that physics are harder than they seem at first glance, and that you can go a long way with the right combination of approximations.

First, he frequently comments on the power of processors nowadays, but I’m not sure if he’s actually been involved in game development. Roughly speaking, one has to run physics in 10% of the CPU time*, including on the lowest-end hardware (in the case of PC games). You have to design your physics model around that processor load, not the multi-core power of the highest system that can run your physics simulation.

Secondly, I have to be brutally honest: when large forces are applied to the vehicles, they look like Jello. The “crash deformations” were very unrealistic to me. This LOOKS pretty, but if I played a racing game with it and expected to slap the walls, this simulation would break my suspension of disbelief much faster than currently-implemented simulations.

Third, pause about halfway in, when the orange truck is towing the blue one. Note that the front and sides of said truck are just flat planes. These models are Playstation-1 level-of-detail.

As a final note, this physics model does not inherently solve any issue Shamus had mentioned in the previous article, with the possibly exception of tire deformation (and in that case, it only deformed an entire cylinder, rim and all). The description of their code doesn’t present any reason that this physics simulation is any less susceptible to interpenetration issues than any other physics engine.

Interpenetration is an inherent design issue in any physics engine that views time in frames or slices; in other words, pretty much any game. The major difference is what code was written to detect and resolve that situation. (As an extreme example, in Super Mario World, if you’re detected inside a wall, you die.)

I’m most certainly going to grab this and play with it. Most notably, I’ll try to break it in the ways Shamus laments. :) But, at first glance, this demo looks like it improves one visual element of vehicular physics modelling, but hasn’t implemented any other game-physics advancement in the last ten years.

*Estimate based on a quick Google search for “game physics percent of CPU”

I just LOVE the bridge builder game. It brings out the little engineer in me. But I’m a little leery of getting a “Test Passed” when the bridge collapses just behind the train as it reaches the other side… Seems to me that a bridge should be good for more than one trip.

If you like bridge builder check out Pontifex by Chronic Logic. It’s a fantastic game. A lot like bridge builder, but it’s 3D. I’ve had it for years and still load it up and play around from time to time.

I loaded up the actual RoR software, ready to give it a fair shake. Regrettably, I actually think less of it now.

Went to the island, took the repair truck, rammed the airplane on the runway. The truck clipped through the airplane, only colliding with the landing gear. Created a hatchback and rammed it; truck interpenetrated it as well. Took the hatchback and rammed the sidewall on the freeway; the back end started bouncing up and down.

In addition, the second the plane moved (even when my truck no longer touched it), my framerate was cut in half. I’m at 640×480 with everything off, running a 2GHz processor and well over half a gig of memory; this is their “minimum spec” for a tech demo with zero bells and whistles, minimal gameplay features, and none of the other game features that take CPU time (music, AI, network, etc.)

Don’t get me wrong: I am still impressed with the demo. What I am absolutely not impressed with, is the first paragraph on this demo’s site proudly proclaiming that a JPL physicist and “author or [sic] one of the most comprehensive racing car physics study online… says ‘this is one of the best driving simulation [sic] I have ever seen’.”

I don’t care that I saw the man say it; I object to the statement as patently false. This is a pretty demo of what basically amounts to inverse kinematics. It’s ragdoll for cars, and much like early ragdoll, it’s turned to 11 and things are flopping around that shouldn’t be. It’s pretty, it’s unique, but frankly, its status as “wave of the future” is sheer hype being presented by a man who, if his resume is true, should know better.

(All of this disregarding the idea that the demo was simply not fun; the cars drive like, well, a car driving on wet grass, with a driver who can only floor the accelerator and turn the wheel in 90-degree increments.)

I think the critics of this are looking with their eyes.. but not engaging the mind… the point is not how great the thing looks.. it’s how simple physics can be used again.. the rubbery wreck just needs some variables tweeked so that the “stick” breaks at a certain point.. someone said there can’t be an overly complicated Sim.. that’s the point.. simplify the physics and you can complicate the sim.. our world is much simpler than the physics we use in games.. but it takes more calculations.. that’s the point.. we will be seeing games with simpler math but more things can be calculated.. thus more complicated sims.. thus closer to a true sim…

Dave: I agree with you.
This isn’t a ‘professional’ game at all. It’s a proof of concept, the interesting thing is the model they used to model the vehicles. It’s about using simple equations to ease the load required for modeling the vehicles.

Lee:
For the record, the guy being interviewed helped out the Forza team for their tire simulations. From what I saw during the whole interview he does in fact know what he is talking about. It seems that he works on actual physics simulations, not just for games.

In the full interview he comments a few times that car physics simulations are by no means complete and there are still a lot of people in the industry working on making it better. He says that this video shows that another idea that breaks the mold in a lot of respects can come out of left-field and it can only help with both game design and real work done in the field.

Many, many pages of thought deleted. :) It was all calm and well-constructed, but as usual, my closing argument was the only relevant one.

My point during the discussion is that yes, this is an interesting physics model. However, it has nothing to do with any single issue Shamus brought up in the Oversimulation piece. In fact, it exhibits the problems he described, and performs those errors far worse than any recent commercial game. Its only merit in the discussion is as an example of “here’s someone approaching the issue in a new way,” but that message is lost in the trumpeting herald of Dr. Beckman and the RoR website itself, proclaiming it as the best driving simulation ever.

The whole discussion’s completely sidetracked. We start with the problems of current physics models, which are caused by physics models that try to resolve complex issues without going into deep-think. Then, we are presented with a demonstration of an engine which 1) doesn’t even fix said issues as well as current engines, 2) adds a feature irrelevant to the discussion, 3) does so while adding an order of magnitude more CPU load than is even remotely feasible in a game, 4) has the very same deep-think issues that caused existing engines to go for simple-but-odd-looking solutions in the first place.

The reason most physics engines have the occasional bout of odd-looking behavior is because the engine is applying a quick solution to a physics calculation that, if calculated normally, would deep-think the system, effectively locking it up. It is a compromise, and one that does not have a solution that is both “fast” and “right.”

Math fans, try approximating “y = sin x” with a polynomial. Here’s the catch: you must be able to plot y on your polynomial for values x of each of the integers 0 through 10, on paper, in blah minutes (the number’s not relevant). How close was your approximation to the “real” effect? That should be a very visual example of what I’m trying to explain.

RoR doesn’t tackle this problem at all. It actually tackles it less than modern engines; it just deep-thinks instead. That’s literally the “brute force” approach. Its design is unique and should be applauded. Its implementation is incomplete. It’s comparison to commercial engines is laudable.

That’s my point. Shamus decried current games for simulating when they should have approximated; for the errors he points out, approximating is just what they did. Then, we see an engine that simulates when it should approximate (and immediately slows down) and approximates when it should simulate (and clips through objects).

I like the discussion, but it’s very turned around at this point. It was about games, so I pose the question: Would you prefer your in-game collision bounce oddly, or lock up the system? My point was that RoR is not posing an alternative to that dilemma; their code would be in the latter camp if ported to an actual game.

I hadn’t tried the game myself, obviously. It really did sound good to me during the demo, but as I said I’ve worked with an idea similar to this (okay, in 2D) and liked the results. From Beckman’s description it sounded like the solution scaled well into 3D. Alas not.

I assume they’re not going to chuck their physics and start over. It will be interesting to see if it improves, and how much, as they polish it.

I spent most of the day playing it. It was a hoot and substantially different from the way things are done in other games.

I do see where it’s weak, but think about the brillance of it; the whole idea that the entire physics engine just need to rely on one modelling technique, and the rest of the physics would self-adjust to it. It frees up the developer from tackling a technique problem to do more about the content, so I think it’s a good step.

One of the odd things about the program, it does strange good things. Take an AN-12 (the four-engined plane) up into the air, circle, and run the engines at full power. Within 5 minutes, the port outer engine mount would fail and the engine would start to oscillate. Shortly after, one of the wings structure would fail and fold (unrealistically), sending the plane into a death spiral.

Given the behaviour of other planes that are available for download, I think this isn’t hard-coded into any of the program or plane specs, but just something the the physics engine would do systematically; it actually simulates the vibrational failure of the mounts and wing roots.

Not only that, when I started tinkering with increasing engine horsepower on another aircraft, the system actually determined that my propellers were not sufficiently strong to take the strain and broke my propellars!

In my last “Death Spiral”, I also loaded a car into the cargo bay. I was quite pleased to see the car was totally smashed into the ground along with the rest of the aircraft. Many games hsve indestructible cargo holds, and thankfully this isn’t one of those.

A lot of things can be better; collision detection is something that’s quite an issue. However, this is likely because the modellers are just putting in “skeleton” models (with lots of empty air, with just a skin over the frame) and not full models built to be solid. If this catches on, the quality of models should increase as we go along.

Y’know, something occurred to me: have they talked to any engineers? Because those guys have been doing (for generous definitions of ‘doing’) something very similar for sixty-some years. If they haven’t, maybe they should – they could expand past ‘sticks and stones’ into some cool approximations.

[…] wheels affect car behaviour as they should, as you can see when a car's ridiculously smashed and bent and so can only drive in little circles. You can even get rear-wheel-steer and front-wheel-drive, […]

One Trackback

[…] wheels affect car behaviour as they should, as you can see when a car's ridiculously smashed and bent and so can only drive in little circles. You can even get rear-wheel-steer and front-wheel-drive, […]