More on Particles

Glenn G. ChappellCHAPPELLG@member.ams.org

U. of Alaska Fairbanks

CS 481/681 Lecture NotesWednesday, March 24, 2004

24 Mar 2004 CS 481/681 2

Procedural Methods:Introduction [1/2]

We have considered various ways to represent a scene and objects within a scene.

Sometimes objects are complex enough (in appearance or behavior) that we think primarily about the algorithm that generates the object, rather than any static representation.

Such algorithms are generally known as procedural methods. Perlin’s noise-based texture generation technique (from

CS 381, fall 2003) is a good example of a procedural method.

24 Mar 2004 CS 481/681 3

Review:Procedural Methods We will consider two main categories of procedural methods:

Particle systems• Independently moving particles, obeying some set of laws.• Used for:

• Smoke.• Sparks (from welding or whatever).• Explosions (not too different from sparks).• Semi-rigid solids (particles connected by stiff springs).• Cloth (particles connected by things that act like fibers).• Crowd scenes (each particle is a person).• Flocks of birds & schools of fish.• Etc.

Fractals• Definitions later …• Used for:

• Clouds.• Terrain.• Tree bark.• Pretty pictures.

24 Mar 2004 CS 481/681 4

Review:Particles [1/4]

A particle is an object that has a time-dependent position. That’s essentially all it has. So it can be somewhere, and it can move.

In CG, particles are used in many types of modeling. Particles may interact with each other in complex ways. We can render a particle however we want.

Particles are most interesting when they form groups in which each particle moves (somewhat) independently. This is called a particle system.

24 Mar 2004 CS 481/681 5

Review:Particles [2/4] Code for a particle, with no force acting on it, might look like this:

Global:

Particle p;

In the idle function:

static double previous_time = get_the_time();double current_time = get_the_time();double elapsed_time = current_time – previous_time;p.position += p.velocity * elapsed_time;glutPostRedisplay();previous_time = current_time;

In the display function:

render(p);

24 Mar 2004 CS 481/681 6

Review:Particles [3/4] Suppose the force on a particle is small.

Then its velocity will not change much between two frames. And we can approximate its changing velocity by its current velocity.

vec force = compute_force(p.position);

p.position += p.velocity * elapsed_time;

p.velocity += force / p.mass * elapsed_time;

This is based on a simple method for solving differential equations, called Euler’s Method.

This method has two problems: Accuracy

• The velocity is not constant, after all. Stability

• Small initial errors in position can quickly turn into large errors.

24 Mar 2004 CS 481/681 7

Review:Particles [4/4] We can do better if, instead of using the current velocity of the particle to

update its position, we use the average of its current velocity and its next velocity.

Except we do not necessarily know what the latter is. So, we approximate it, the same way we have been:

vec force = compute_force(p.position);vec next_velocity = p.velocity + force / p.mass * elapsed_time;p.position += (p.velocity + next_velocity) / 2. * elapsed_time;p.velocity = next_velocity;

This is based on a method for solving differential equations, called the Order 2 Runge-Kutta Method.

It has both better accuracy and stability. When the acceleration is constant (e.g., gravity), it is exactly right.

• I mean mathematically, of course. Floating-point computations are always wrong. When the acceleration is not constant, we should do better than the above

code.

24 Mar 2004 CS 481/681 8

Particles — Better Solutions:Varying Acceleration Our use of the 2nd-order Runge-Kutta method was for

constant acceleration (like human-scale gravity). For changing acceleration, we can use the same trick we

used on the position to compute the velocity. What We Did

Instead of updating the position using only the current velocity, use the average of the current and next velocities.

Except we do not know the next velocity, so approximate it using what we know now.

What We Can Do Instead of updating the velocity using only the current

acceleration, use the average of the current and next accelerations.

Except we do not know the next acceleration, so approximate it using what we know now.

Next, some code.

24 Mar 2004 CS 481/681 9

Particles — Better Solutions: Some Code I handle acceleration a bit differently. Assume we have a function that computes

the acceleration on a particle, given its state (position, velocity, mass). This allows for acceleration that depends on velocity, as would happen with air resistance,

for example.

vec current_accel = compute_accel(p.position, p.velocity, p.mass);

pos next_position_guess = p.position + p.velocity * elapsed_time;

vec next_velocity_guess = p.velocity + current_accel * elapsed_time;

vec next_accel_guess =

compute_accel(next_position_guess, next_velocity_guess, p.mass);

p.position += (p.velocity + next_velocity_guess)/2. * elapsed_time;

p.velocity += (current_accel + next_accel_guess)/2. * elapsed_time;

Notes This is the full implementation of the 2nd-order Runge-Kutta method for a moving particle.

(With constant mass! Under what circumstances would the mass be nonconstant?). We update p.velocity after using its value. This matters! We could just pass a Particle to compute_accel. However, this would make it trickier to

compute next_accel_guess. (How would you do this using OO design?)

24 Mar 2004 CS 481/681 10

Particles — Better Solutions:Notes on Error Numerical solution techniques always have some error.

The error is usually proportional to a power of the step size (here, elapsed_time).

• Step sizes are usually small, so higher powers mean better accuracy.• E.g., for step size h, Euler’s Method has error O(h2), while the 2nd-order R-K

method has error O(h3).• Thus, for better solution methods, using a smaller step size can greatly

improve the results. (How can this be done?) The error is also usually proportion to some higher-order derivative of

the state variables.• So accuracy is reduced in places where the force changes rapidly.• E.g., in planetary motion simulation, accuracy is lower near the sun.

Error can be reduced using better techniques (as we have done). However, these techniques generally take more time.

• E.g., in the full version of 2nd-order R-K, we call compute_accel twice.• Reducing the step size also slows things down, of course.• Time-accuracy trade-offs like this are very common in computing.• Of course, we need to consider this is the light of the time taken to render

a frame, which is often much greater than computation time.

24 Mar 2004 CS 481/681 11

Particles — Implementation:Example Program

We looked at particles.cpp, which is on the web page.

24 Mar 2004 CS 481/681 12

Particles — Collisions:Introduction The rules for particle behavior that we have been

discussing are known as soft constraints. A constraint is soft if it does not need to be satisfied exactly.

Other rules, like “particles cannot pass through each other”, are generally considered to be hard constraints. A small error in satisfying such a constraint is unacceptable.

Now, consider a particle bouncing off something (a wall, another particle). This involves both hard constraints and rapid changes in

force. Thus, the simulation methods we have discussed are often

inappropriate for handling collisions.

24 Mar 2004 CS 481/681 13

Particles — Collisions:Detection & Handling

When we deal with collisions, there are two problems: Is there a collision?

• We discussed this briefly last semester. We will not say much about it now.

• This is generally the more computationally intensive part of dealing with collisions.

How to handle the collision, if there is one.• First find out where the collision occurred.• Then alter positions and velocities accordingly.

24 Mar 2004 CS 481/681 14

Particles — Collisions:Elastic vs. Inelastic

An elastic collision is one in which no energy is lost. Think of hard rubber objects bouncing. In an elastic collision with a fixed object, the

moving object will rebound with the same speed.

In an inelastic collision, energy is lost. Think of squishy objects colliding. In practice, kinetic energy is converted to

heat. We look at elastic collisions now.

24 Mar 2004 CS 481/681 15

Particles — Collisions:Object & Wall The most common sort of collision to model is elastic

collision of a moving object with a fixed object, often a plane (a wall?). Think “bouncing ball”.

Where does the collision occur? Assume constant-velocity motion (?) Lirp to find intersection.

How to handle the collision. At the point of collision, the velocity vector of the moving

object changes. Its component in the direction of the normal to the wall is

reversed.

p.velocity -= 2.*p.velocity.component(wall_normal);