More on Particles Glenn G. Chappell U. of Alaska Fairbanks CS 481/681 Lecture Notes Wednesday, March 24, 2004

24 Mar 2004CS 481/6812 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 2004CS 481/6813 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 2004CS 481/6814 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 2004CS 481/6815 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 2004CS 481/6816 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 2004CS 481/6817 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 2004CS 481/6818 Particles — Better Solutions: Varying Acceleration Our use of the 2 nd -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 2004CS 481/6819 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 2 nd -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 2004CS 481/68110 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(h 2 ), while the 2 nd -order R- K method has error O(h 3 ). 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 2 nd -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 2004CS 481/68111 Particles — Implementation: Example Program We looked at particles.cpp, which is on the web page.

24 Mar 2004CS 481/68112 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 2004CS 481/68113 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 2004CS 481/68114 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 2004CS 481/68115 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);