Wednesday, August 15, 2012

Cyclic Physics Mapping

In computer games, the performance of a complex physical object, such as a car, is generally represented by a few numbers: in the case of a car, numbers representing acceleration, tire grip, center of gravity, drag, etc. These numbers are "tweaked" to get performance that matches the real thing, if there is a real thing being modeled. This works fine for making the perfect replica of an existing vehicle, but what about if you want to make something new? You can't just plug in numbers, because you have no numbers to plug in. So, you could guess, or you could physically model the workings of the car.
The latter would seem like a great way to get a good model. After all, if designers use CAD to predict the performance of a part in real life, why not just predict the performance of all the parts and build a virtual car? The problem is speed. Let's look at the engine itself. Inside the cylinders, a mixture of gasoline and air explodes, pushing the cylinder down. Explosions aren't cheap to simulate; and as even an idling engine produces more than 25 explosions per second, it seems impossible that one could simulate an entire running engine, much less a whole car.
Or is it? There's a great way to reduce physics computing overhead, which is known in the Bullet physics library as "sleeping". This happens when:

  1. the forces acting on an object are in equilibrium, 
  2. that object has been static for a period of time (a second or so), and
  3. there is no active object within the reaction boundaries.
To illustrate:
Two falling blocks in Blender; the white outline indicates they are active.
The blocks after coming to rest. The green indicates that they are now "sleeping" and no longer being calculated.
The problem with this is that it only works on objects which are completely at rest. How do we deal with an active object? The solution is lumping things together. For example, instead of doing a laborious fluid dynamics calculation for the explosion, we can lump the combustion chamber into a system with five variables: the amount of gas entering the chamber, the amount of air entering the chamber, the momentum of the piston, the force the piston exerts on the gas, and the speed of the piston. We can calculate the amount of gas that actually burns now, and from that deduce the temperature change (and volume change) in the gas - and therefore the force on the piston.
This is great, but it still won't come anywhere close to simulating a vehicle in real time. The solution is in seeing that most things come in some form of cycles - in this case, the piston repeats itself every two revolutions of the crankshaft. So, we can simulate this cycle once and then just repeat it until one of the variables changes.
But why re-simulate each time a variable changes? The output it creates is continuous within reasonable parameters - so why not just simulate the cycle several times, for different data points in each of the variables, and use splines to interpolate the performance in real time? Furthermore, now that we have a system with a few variable inputs and outputs, it can be lumped into a larger system. Now we can treat the engine as a whole as a system, which has a few variables: fuel input, air input, crankshaft speed, and power output. At lower revs, the crankshaft speed won't be constant, because it slows down in between each explosion, but at higher revs it would be nearly constant.
The discontinuity is the point where the engine stalls; beyond this point a cyclic simulation is pointless.
So, now we've lumped the engine into a single "black box" as seen by our physics engine, but this can continue. This lumping method, which I will call "Cyclic Physics Mapping" because we are mapping physical properties into parameterised cycles, allows us to make progressively larger "black boxes" out of components, until we have basically what was mentioned at the beginning of this post - a car whose performance is represented by a few variables - except that now we have a physical model of the entire car. Which has certain consequences: for example, it is relatively easy to redo the CPM for a different fuel, to simulate, say, nitrous injection, or a switch from gasoline to hydrogen. Also - suppose you drive over a parking bumper at high speed and bend your transmission. That's going to create more drag; the mapping down to the transmission level will have to be redone, but the engine simulation is not affected - you will now be driving a car that now behaves realistically as a damaged car would. There's not really an easy way to do that with purely numbers-based systems.
This isn't just applicable to cars; you could do the same thing for anything complex and physical in a virtual world - boats, planes, even the guns in an FPS could have a physical basis in the same way. And  even noncomplex objects, like the boxes shown before, would be handled like this - once the boxes come to rest relative to the platform they are on, they and the platform can now be treated as a group. Any system that interacts minimally with other systems can be considered a black box under these circumstances.