Project 4 : Animator

Assigned : Tuesday, February 26, 2013
Due : Tuesday, March 12, 2013, 06:00 PM

Artifact Due : Tuesday, March 19, 2013, 10:00 AM
Artifact voting: Tuesday, March 19, 2013 during class (6:30pm-9:20pm)

How to turn in!
Direct link to Catalyst for turnin

Quick Links

1. Skeleton Code
2. Sample Solution
3. Help Slides
4. Witkin's and Baraff's Physically Based Modeling: Differential Equations Basics
5. Witkin's Physically Based Modeling: Particle System Dynamics
6. Pseudocode for connecting Particle Systems to hierarchies
7. John Lasseter's article on Animation Principles
8. Demos:
• motion blur
• billboard
• particle system: cloth
• particle system: fire
• projected textures
9. Putting together your final artifact
10. Inspiring projects from previous quarters

Project Objectives

In this project, you are required to extend a spline-based animation system to support multiple curve types, and implement a particle system simulation engine. After building a working system, you will use your (robust and powerful) program to produce a (compelling and arresting) animation.

Overview

The skeleton code provided is built on top of the same architecture as the Modeler, and is designed so that you can re-use your models.  If you replace robotarm.cpp with a working model file from Project 2, you should be able to compile the program and play with the interface. As with the Modeler, this application has two windows: a viewer for the model, and a main window that allows you to manipulate the various model and camera parameters.  If you click on the "Controls" tab in the main window, you will essentially get the Modeler interface, with sliders for controlling components of your character.  The second mode, where you'll be spending most of your time, is the "Curves" mode.  Curves mode is where you edit a time-varying curve for each model parameter by adding and moving control points.  Selecting controls in the left-hand browser window brings up the corresponding curves in the graph on the right.  Here, time is plotted on the x-axis, and the value of a given parameter is plotted on the y-axis.  This graph display and interface is encapsulated in the GraphWidget class.

Project Requirements Summary

Here is a summary of the requirements for this project:

• Implement the following curve types:
• Bezier (cubic beziers splined together with C⁰ continuity)
• Catmull-Rom (with endpoint interpolation)
• Implement a particle system that:
• is attached to a node of your hierarchy other than the root node
• has two distinct forces acting on the particles
• solves the system of forces using Euler's method
• includes collision detection and response
• provides control of the restitution constant (e.g a slider)

Some of these requirements are explained in greater detail below.

Project Requirement Details

• Bezier Curves
  When we say "cubic beziers splined together with C⁰ continuity" it means that you'll need at least four control points to make a single bezier curve. Adjacent Bezier curves share control points so that the last control point of one Bezier curve will be the first control point of another. In this way you can have two complete Bezier curves with only 7 control points. Note: In the lecture slides, you were shown an adaptive recurrsive algorithm for creating bezier curves as well as a straight forward method that simply samples at a consistent rate. The adaptive Bezier curve generation is not required (but is a bell of extra credit). Feel free to sample the curve at a constant rate to fulfill the project requirments.

• General Curves
  It is possible to make parametric curves that "double back" on themselves (x is not monotonically increasing as a function of t). It must be possible to interpret the curves that your solution produces as a function of time, so you'll have to think about and solve this case.

• Two Distinct Forces
  Create at least two distinct types of forces that act on your particle system.  The three most obvious distinct forces are gravity (f=mg), viscous drag (f=-k_d*v), and Hooks spring law. Other interesting possibilities include electromagnetic force, simulation of flocking behavior, and buoyant force. If the forces you choose are complicated or novel (or listed in the Bells and Whistles) you may earn extra credit while simultaneously fulfilling this requirement.

• Collision Detection & Response
  Perform collision detection with your particles and at least one primitive in your scene. A natural choice is the ground plane of your scene. Your particles should bounce off of that primitive, and you should provide a control for the restitution constant that determines how much the normal component of the reflected velocity is attenuated.

  To control the restitution, you can add a RangeProperty field to your ParticleSystem class, just like you did for your model class in Modeler. The difference is that you will add the field to your ParticleSystem class, then add it to your model's property list in your model's constructor. This way, you can easily access your field both from inside your ParticleSystem and inside your model!

  1. Add #include "properties.h" to particleSystem.h, before class ParticleSystem. This lets you use sliders in ParticleSystem.
  2. Add a RangeProperty named restitution to your ParticleSystem. Make it a public field.

               // in particleSystem.h
               #include "properties.h" // you added this, right?
               class ParticleSystem {
                 public:
                   RangeProperty restitution;
               };
               

  3. In your ParticleSystem constructor, call your RangeProperty's constructor by adding the highlighted code:

               // in particleSystem.cpp
               ParticleSystem::ParticleSystem() : restitution("Restitution", 0.0f, 2.0f, 1.0f, 0.1f) {
                 // ... constructor code
               }
               

  4. Then, in your model's constructor, add the property to your model's property list.

               // in sample.cpp (or whatever file your model is in):
               class MyModel : public Model {
                 ParticleSystem ps;
     
                 // ... other stuff ....
     
                 MyModel() : // ... constructor calls for your sliders, textures, shader, etc ...
                 {
                   // ... calls to properties.add() for each slider, checkbox, etc. ...
                   properties.add(&ps.restitution);
                 }
               }
               

  5. To obtain the slider value inside your computeForcesAndUpdateParticles() method in ParticleSystem, call restitution.getValue().
  6. Now, the restitution slider will appear with the rest of your model's controls, and will also be a curve you can animate.

Graph Widget Interface

After selecting a model parameters in the tree on the left, the parameter's corresponding animation curve is displayed in the graph. Each spline is evaluated as a simple piece-wise linear curve that linearly interpolates between control points.  You can manipulate the curve as follows:

Note that each of the displayed curves has a different scale. Based on the maximum and minimum values for each parameter that you specified in your model file, the curve is drawn to "fit" into the graph. You'll also notice that the other curve types in the drop-down menu are not working. One part of your requirements (outlined below) is to implement these other curves.

Controlling Time

At the bottom of the window is a simple set of VCR-style controls and a time slider that let you play, pause, and seek in your animation. The The Simulate checkbox relates to the particle system which is discussed below. 

Controlling the Camera

Camera motions can be edited in two ways: 

• Setting Keyframes:  You will use the camera keyframing interface to define some basic camera movements.  The Plot Keyframe button will take the current camera parameters from the viewport and save them as control points in the graph widget.  Typically, you will move the time slider, adjust the camera pose in the viewport, then click Plot Keyframe.  If you want to remove a keyframe, use the time slider to seek to the approximate time of the keyframe, then click "Clear Keyframe" button.  This button will delete all camera control points in a narrow range around the current time.
• Editing Curves:  There are 7 camera parameters that appear as the last 7 items in the Model Controls list.  Clicking on one of these properties will cause the control points for this curve to appear in the graph widget interface.  From here, you can edit control points and curve types as you can with any other model parameter.

Animation Curves

The GraphWidget object owns a bunch of Curve objects. The Curve class is used to represent the time-varying splines associated with your model parameters.  You don't need to worry about most of the existing code, which is used to handle the user interface.  However, it is important that you understand the curve evaluation model. Each curve is represented by a vector of evaluated points.

mutable std::vector m_ptvCtrlPts;
mutable std::vector m_ptvEvaluatedCurvePts;

The user of your program can manipulate the positions of the control points using the Graph Widget interface. Your code will compute the value of the curve at intervals in time, determining the shape of the curve. Given a set of control points, the system figures out what the evaluated points are.

This conversion process is handled by the CurveEvaluator member variable of each curve. 

const CurveEvaluator* m_pceEvaluator;

In the skeleton, only the LinearCurveEvaluator has been implemented. Consequently, the curve drawn is composed of line segments directly connecting each control point.  You should use the LinearCurveEvaluator as a model to implement the other required curve evaluators: Bezier and Catmull-Rom.  B-Spline and C²-Interpolating curves can be added for extra credit. 

Adding Curve Types

For each curve type, you must write a new class that inherits from CurveEvaluator. Inside the class, you should implement the evaluateCurve function. This function takes the following parameters:

ptvCtrlPts--a collection of control points that you specify in the curve editor
ptvEvaluatedCurvePts--a collection of evaluated curve points that you return from the function calculated using the curve type's formulas
fAniLength--the maximum time that a curve is defined
bWrap--a flag indicating whether or not the curve should be wrapped (wrapping can be implemented for extra credit)

To add a new curve type, you should look in the GraphWidget constructor and change the following lines to use your new set of evaluator classes.

m_ppceCurveEvaluators[CURVE_TYPE_BSPLINE] = new LinearCurveEvaluator();
m_ppceCurveEvaluators[CURVE_TYPE_BEZIER] = new LinearCurveEvaluator();
m_ppceCurveEvaluators[CURVE_TYPE_CATMULLROM] = new LinearCurveEvaluator();

For Bezier curves (and the splines based on them), it is sufficient to sample the curve at fixed intervals of time. The adaptive de Casteljau subdivision algorithm presented in class may be implemented for an extra bell.

Catmull-Rom curves should be endpoint interpolating. This can be done by doubling the endpoints.

You do not have to sort the control points or the evaluated curve points. This has been done for you. Note, however, that for an interpolating curve (Catmull-Rom), the fact that the control points are given to you sorted by x does not ensure that the curve itself will also monotonically increase in x. You should recognize and handle this case appropriately.  One solution is to return only the evaluated points that are increasing monotonically in x.

Also, be aware that the evaluation function will linearly interpolate between the evaluated points to ensure a continuous curve on the screen.  This is why you don't have to generate infinitely many evaluated points.

Particle System Simulation

The skeleton code has a very high-level framework in place for running particle simulations that is based on Witkin's Particle System Dynamics.  In this model, there are three major components:

1. Particle objects (which have physical properties such as mass, position and velocity)
2. Forces
3. An engine for simulating the effect of the forces acting on the particles that solves for the position and velocity of each particle at every time step

You are responsible for coming up with a representation for particles and forces.  The skeleton provides a very basic outline of a simulation engine, encapsulated by the ParticleSystem class.  Currently, the header file (ParticleSystem.h) specifies an interface that must be supported in order for your particle system to interact correctly with the animator UI.  Alternately, you can try to figure out how the UI works yourself by searching within the project files for all calls to the particle system's functions, and then re-organizing the code.  This second option may provide you with more flexibility in doing some very ambitious particle systems with extra UI support.  However, the framework seems general enough to support a wide range of particle systems.  There is detailed documentation in the header file itself that indicates what each function you are required to write should do.  Note that the ParticleSystem declaration is by no means complete.  As mentioned above, you will have to figure out how you want to store and organize particles and forces, and as a result, you will need to add member variables and functions. 

One of the functions you are required to implement is called computeForcesAndUpdateParticles:

virtual void computeForcesAndUpdateParticles(float t);

This function represents the meat of the simulation solver.  Here you will compute the forces acting on each particle and update their positions and velocities based on these forces using Euler's method.  As mentioned above, you are responsible for modeling particles and forces in some way that allows you to perform this update step at each frame.  

Particles As Part of a Hierarchy

One requirement of your particle system is to attach it to a node of your model other than the root.  This requires that you think carefully about about how to represent the positions of your particles. 

Suppose you want to attach a particle shower to your model's hand.  When you apply the force of gravity to these particles, the direction of the force will always be along the negative Y axis of the world.  If you mistakenly apply gravity along negative Y of the hand's coordinate space, you'll see some funky gravity that depends on the orientation of the hand (bad!).  To solve this problem, we recommend that you attach a particle emitter to the model's hand, but store all the particles positions as coordinates in world space.  This means that you'll need to calculate the world coordinates of the particle emitter every time a particle is spawned.

Please read the following pseudocode, which contains an in-depth discussion of using particles in your hierarchy.

The function getModelViewMatrix is used in the file above.  We are also providing the C implementation for it:

Mat4f getModelViewMatrix()
{
    GLfloat m[16];
    glGetFloatv(GL_MODELVIEW_MATRIX, m);
    Mat4f matMV(m[0], m[1], m[2], m[3],
        m[4], m[5], m[6], m[7],
        m[8], m[9], m[10], m[11],
        m[12], m[13], m[14], m[15] );
    return matMV.transpose(); // because the matrix GL returns is column major
}

Hooking Up Your Particle System

Animator obtains your model's particle system by calling the getParticleSystem() method of your Model subclass. If you don't override it, this method returns NULL (and Animator may crash as a result). So, to add your particle system, do the following:

1. Add the following field to your Model subclass:
   

   protected:
     ParticleSystem ps;
     

2. Add the following method to your Model subclass:
   

   public:
     ParticleSystem* getParticleSystem() { return &ps; }
     

Animation Artifact

You will eventually use your program to produce an animated artifact for this project (after the project due date – see the top of the page for artifact due date). Under the File menu of the program, there is a Save Movie Frames option, that will let you specify a base filename for a set of movie frames.  Each frame is saved as a png or jpg, with your base filename plus some digits that indicate the frame number. Use a program like Adobe Premiere (installed in the labs) to compress the frame into a video file. (See Quick Links for more detail.)

We may give extra credit to those that are exceptionally clever or aesthetically pleasing. Try to use the ideas discussed in the John Lasseter article. These include anticipation, follow-through, squash and stretch, and secondary motion. 

Finally, plan for your animation to be 30 seconds long (60 seconds is the absolute maximum).  You will find this is a very small amount of time, so consider this when planning your animation.  We reserve the right to penalize artifacts that go over the time limit and/or clip the video for the purposes of voting. Refer to this guide for creating your final .avi file.

• Absolute time limit: 60 seconds...shorter is better!
• Animation will count toward final grade on animator project.
• The course staff will grade based on technical and artistic merit.

Then, you must turn in your completed artifact as a video through catalyst. DO NOT submit the artifact with your code and binary. The due dates are different!

See due dates/times at the top of this page.  Do not be late!

Bells and Whistles