Introduction

On Monday, we started talking about techniques for animating computer graphics.
We talked about keyframing, skinning, and particle simulation.
We mentioned for particle simulation that we could do this in the onLoop method of our SDL game loop.
We said that when this method is called it should determine how much time had passed since the last time the method was called.
If too little time had passed, we should idle a bit before trying to draw again. I.e., we probably want to cap our refresh rate at say 120 frames per seconds.
On the other hand, if more than our minimum frame time had passed, then we use this `dt` as our change in time when using our update rule of last day
`x_(t+dt) = x_t + v_t dt`
`v_(t+dt) = v_t + a_t dt`
`a_(t+dt) = (F(x_(t+dt), t+dt))/m`.
Let's use this as a starting point to briefly describe how we could organize the objects we are simulating.

Organizing our Objects

To code a simulation of objects we could use a class to represent a Thing in our simulation.
The collection of all Thing's could be stored in a vector.
When OnLoop is called, we compute `dt` since the last call.
We then might have a method updateThings() which cycles through each Thing and calls that Thing's update() method.
A Thing should have at least six fields used to hold position, velocity, and acceleration; nextPosition, nextVelocity, nextAcceleration.
When a Thing's update() method is called, it computes values of nextPosition, nextVelocity from position, velocity, and acceleration values.
We then might have a second loop accelerateThings(), which cycles through each Thing and calls its accelerate() method. This method might make of an auxiliary method forces() which computes using the updated time and position, the sum of the forces the Thing feels. Using the value computed accelerate() divides this by the Thing's mass to compute the new acceleration.
Finally, our OnLoop method could call moveThings(), which cycles through each Thing and calls its move() method. This sets position, velocity, and acceleration to nextPosition, nextVelocity, and nextAcceleration, so that the subsequent call to OnRender will draw objects in their new locations.

Rigid Bodies

To model the time evolution of rigid bodies, we now have to deal with the fact that our objects are no longer point particles.
In particular, this means we have to deal with rotations and angular momentum.
In a rigid body simulation, we also want to model bodies colliding with each other and bouncing in response.
Computing collisions requires us to keep track of all pairs of bodies and determine when they intersect.
This gives rise to the standard problem that for `n` bodies we might have `(n(n-1))/2` many pairs we might need to keep track of.
To solve this problem, we might organize our objects into a spatial bounding hierarchy.
Once we have found an intersection, the bodies have already interpenetrated, so we need to decide how we undo this.
One crude non-physical solution is just to "back" the object out to the point of first collision.
In our set up of the last slide, that means after we call accelerateThings, we should call a function collideThings() which checks for collisions among Things as well as potentially updates nextPosition, nextVelocity, and nextAcceleration of a thing before moveThings() is called.
We also have a choice in modeling how things collide: the collision might have some "elasticity", that is some of the energy of the system might be absorbed by the collision.
A final important issue is how to appropriate model frictional and contact forces. We would like that when an object is at rest on the floor, that the force that keeps the object from falling through the floor combined with gravity doesn't cause the object to constantly "twitch".

Sequence of Method Calls

Below is the order of method calls for our game loop so far. In the update() or collide() method we might mark a Thing as being "too old" or being "destroyed by gun fire", etc. collectDeadAndSpawn() garbage collects dead things and might spawn new Things like explosions.

onLoop()
  updateThings()
    update()
  accelerateThings()
    accelerate()
  collideThings()
    collide()
  collectDeadAndSpawn()
  moveThings()
    move()
onRender()

Modeling Forces

Gravity. In physics we have between two object of mass `m_1` and `m_2` a force due to gravity of
`F = G cdot (m_1 cdot m_2)/ r^2`
where `G` is the gravitational constant, and `r` is the distance between the objects. In a computer simulation, we are free to choose `G` so that the simulation "looks good". We also often just model gravity as a force field pulling objects down. To do this we use:
`vec F= m vec g`
where `m` is the Thing's mass and the vector `vec g` is the direction we want the force field to accelerate.
Drag. If a Thing has a radius field `r`, then we can model drag using equations like:
`A = r^2` // approximate area
`vec F = I cdot A ( vec D - vec v)`
Here `I` is the drag intensity set by artistic look, `vec D` is the normalized drag direction, and `v` is the Thing's velocity
Spring. `vec F = k (vec x - vec x_0)`.
Player Forces. You can model the player of a game as injecting short constant forces on Thing's.

Modeling Collisions

Let's look at a simple case of handling a collision or two objects of mass `m_1` and `m_2`.
Conservation of momentum means
`m_1 cdot vec v_(1out) + m_2 cdot vec v_(2out) = m_1 cdot vec v_(1i\n) + m_2 cdot vec v_(2i\n) `
Notice the velocities are vectors, so have three components.
We are also assuming energy is conserved (elastic collisions). This means:
`1/2 m_1 cdot ||vec v_(1out) ||^2 + 1/2 m_2 cdot ||vec v_(2out) ||^2 = 1/2 m_1 cdot ||vec v_(1i\n) ||^2 + 1/2 m_2 cdot ||vec v_(2i\n) ||^2`
Values for velocities that satisfy the first constraint give a line. Values for velocities which satisfy the second constraint give an ellipse.
So the intersection gives two solutions, a pre and post collision solution.
If we call the mass ratio `MR := m_1/m_2`. Then if we work the solution of this intersection we get:
`vec v_{1out} = [(1- MR) cdot vec v_{1i\n} + 2 cdot MR cdot vec v_(2i\n)]/(1+ MR)`
`vec v_{2out} = [(MR -1) cdot vec v_{2i\n} + 2 cdot MR cdot vec v_(1i\n)]/(1+ MR)`

Cloth

Frequently, the people we animate are wearing clothing.
So how do we model cloth?
One way is to use a grid of particles or a mesh of triangular elements.
In a particle-based approach, spring forces are added to this system to avoid stretching, shearing, as well as excessive bending.
Damping is also added to model internal friction; this kills off oscillation. Damping can be modeled as decreasing the value of the total energy of the system according to an update rule (say an exponential decay).
In a triangle-based approach, one writes down an expression `E` for the energy `E` of the cloth state due to stretching, shearing, and bending. Force at a point in the cloth is then computed as the partial derivative of the energy with respect to position.

Animation