More on Particles

1. More on Particles Glenn G. ChappellCHAPPELLG@member.ams.org U. of Alaska Fairbanks CS 481/681 Lecture Notes Wednesday, March 24, 2004

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. 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.  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. 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); 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. 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. 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. 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.velocityafter 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?) 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. CS 481/681

11. Particles — Implementation:Example Program • We looked at particles.cpp, which is on the web page. 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. 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. 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. 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); CS 481/681