I was all set to start talking about how to handle collision response. I thought I could just have these objects that you could move around, m

ake collide, and then watch their responses. Yeah, collision response, that will be great! Then I thought, "How am I going to get these objects flying around in the first place?" Well, I could give each object an initial velocity and they would collide. But, I would need world boundaries for those objects to bounce off of so they would stay in play. To direct the objects, I need to be able to apply force. Suddenly, instead of a nice collision demo, I had designed Asteroids. All I wanted was a little demonstration of a fairly simple concept and instead I ended up applying forces and acceleration to particles. I had stumbled on the big "D" word: Dynamics.

That’s alright. I will not be afraid. I always say, "Turn a problem into an opportunity." However, physics is a huge field full of fertile topics that can be distilled into nice column-sized pieces. So once more good friends, into the breach.

What’s So Dynamic About It?

When I was writing about inverse kinematics back in September, I was only really interested in kinematics: that is, the study of motion without regard to the forces that cause it. Dynamics, I said, concerns how forces are used to create motion, and I didn’t want to open up that can of worms. Well, the can is now open and the worms are climbing all over.

I’m going to have to recap a bit, but I suggest you go back and reread Chris Hecker’s column from the October/November 1996 Game Developer, "Physics, the Next Frontier." If you don’t have the magazine handy, that article as well as other physics related articles written by Chris Hecker are available on the Definition Six web site at http://www.d6.com/users/checker.

This month, I’m going to focus on particle dynamics. What is particularly important about particle dynamics is the relationship between force, f, the mass of a particle, m, and the acceleration of that particle, a. This can be stated in the familiar Newtonian notation as f = ma. You may recall that the acceleration of a particle is the derivative with respect to time of the velocity of that particle, v. Likewise, the velocity of the particle is the derivative with respect to time of the position of the particle, x. You can see how this relationship works in the following equation:

So, let me state the problem I’m trying to solve. Given a set of forces acting on a particle at time t, where will that particle be after a small amount of time has passed? It’s clear that with the value of the force and the mass of the particle, I can obtain the acceleration of the particle. If I integrate that acceleration with respect to t, I’ll end up with the new velocity of the particle. If I integrate again, I get the new position. Easy, right?

The structure for a particle is in Listing 1. It’s easier to store 1/m for the particle because this is what I need in the equations. The forces that act on the particle accumulate in the f term. With this information, I can integrate the dynamic system forward in time to establish a new position for the particle. This process involves solving ordinary differential equations. Fortunately, Chris’s column described a numerical method of solving these problems. Listing 2 contains code that uses the simplest numerical integrator, known as Euler’s method, to compute the new state of the system. The great thing about this integrator is that it’s simple to implement and understand. However, because it’s a simple approximation, it’s subject to numerical instability, as we will see later.

Listing 1. The particle type.

// TYPE FOR A PHYSICAL PARTICLE IN THE SYSTEM
struct tParticle
{
tVector pos; // Position of Particle
tVector v; // Velocity of Particle
tVector f; // Total Force Acting on Particle
float oneOverM; // 1 / Mass of Particle
};

Listing 2. My simple Euler intergrator.

///////////////////////////////////////////////////////////////////////////////
// Function: Integrate
// Purpose: Calculate new Positions and Velocities given a deltatime
// Arguments: DeltaTime that has passed since last iteration
// Notes: This integrator uses Euler's method
///////////////////////////////////////////////////////////////////////////////
void CPhysEnv::Integrate( float DeltaTime)
{
/// Local Variables //////////////////////////////////////////////////////////
int loop;
tParticle *source,*target;
///////////////////////////////////////////////////////////////////////////////
source = m_CurrentSys; // CURRENT STATE OF PARTICLE
target = m_TargetSys; // WHERE I AM GOING TO STORE THE NEW STATE
for (loop = 0; loop < m_ParticleCnt; loop++)
{
// DETERMINE THE NEW VELOCITY FOR THE PARTICLE
target->v.x = source->v.x + (DeltaTime * source->f.x * source->oneOverM);
target->v.y = source->v.y + (DeltaTime * source->f.y * source->oneOverM);
target->v.z = source->v.z + (DeltaTime * source->f.z * source->oneOverM);

// SET THE NEW POSITION
target->pos.x = source->pos.x + (DeltaTime * source->v.x);
target->pos.y = source->pos.y + (DeltaTime * source->v.y);
target->pos.z = source->pos.z + (DeltaTime * source->v.z);

source++;
target++;
}
}

You Can’t Force Me to Move, Can You?

I now have a method for dynamically moving particles around in a realistic fashion. However, to get anything interesting to happen, I need to get things moving. This requires the application of some brute force, or several forces. But what kinds of forces do I want to apply to my little particles?

Well, the obvious force that has been applied to objects in games since the beginning of computer simulations is gravity. Gravity is a constant force that is being applied to all particles. In order to realistically simulate gravity, force must be added into the particle’s force accumulator every system update. In general, this force is a vector pointing down along the y axis. However, there’s nothing to stop a simulator from having a gravity vector that points in a different direction. In fact, one of the very cool things about having a good physical simulation is that gravity can change and things will still "look" correct. This realistic look may not occur if you are trying to hand animate an object.