In order to get the source code, follow the directions below:

Graphics Lab:

1. Log on to Gitlab, and if you haven't already done so, add an ssh key
2. Navigate to your repository https://gitlab.cs.washington.edu/cse557-15au-animator/YOUR-REPO.git, copy the git project URL.
3. YOUR-REPO is the combination of the CSE login ids of the group memebers. For example, say Prof. Brian Curless (cseid: curless) and his TA Aditya (cseid: aditya) are working on the project together, YOUR-REPO is curless-aditya; and the repository will be at https://gitlab.cs.washington.edu/cse557-15au-animator/curless-aditya.git . If Brian is going to work solo, YOUR-REPO is just curless.
4. Groups can be found here
5. Open 'Git Bash' on Windows (Search for it in the start menu if you are having trouble finding it)
6. Navigate to the parent directory of where you would like your repository to live. We recommend putting it somewhere in your Z: drive
7. Run the following command to make a local copy of your repository named 'animator'. You can find your repository on GitLab under the projects tab on the right side of your dashboard.
   

   $ git clone git@gitlab.cs.washington.edu:cse557-15au-animator/YOUR-REPO.git animator

8. Once each partner has cloned the repository on to their local environments, you're now ready to work!

Working from Home:

• Download the installer ">here.
• Run the installer. It will install FLTK in \.
• Download git on your machine
• Follow steps 1-7 above

If you plan to work from home, you will either need to use the FLTK Installer or point Visual Studio to the correct include and library directories for the FLTK that came in your repository (since normally it points to the local one on each lab machine). Instructions for how to do this.

Here is a summary of the requirements for this project:

• Implement surfaces of revolution with:
  • correct surface normals
  • texture mapping
• Create a hierarchical model
• Add a point light to the Blinn-Phong fragment (pixel) shader
• Implement 3 whistles (1.5 bells) worth of additional shaders
• Implement the following curve types:
• Bezier (cubic beziers splined together with C⁰ continuity)
• Catmull-Rom (with endpoint interpolation)
• B-spline (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 for both the sphere in the scene and another primitive of your choice (such as the ground plane)
• provides control of the restitution constant (e.g a slider)

Some of these requirements are explained in greater detail below.

In OpenGL, all scenes are made of primitives like points, lines, triangles and quadrilaterals. In this project, you will implement a surface of revolution using glDrawElements with GL_TRIANGLES to make a 3D surfaces. For each mesh, you send a list of vertices (the points that make up the primitive) with normals and texture coordinates, and an array indices specifying triangles. A simple example can be found in the help slides.

You can read more about OpenGL here.

Your Task:

Write code to create a 3D surface in the drawRevolution() method in modelerdraw.cpp. Your shape must:

1. have appropriate texture coordinates for each vertex;
2. have appropriate per-vertex normals;
3. have surfaces drawn using only glDrawElements with GL_TRIANGLES as its primitive type input;
4. use the divisions variable that already exists in drawRevolution() to determine how many bands your surface is sliced into.

Texture Mapping

Texture mapping allows you to "wrap" images around your model by mapping points on an image (called a texture) to vertices on your model. For each vertex, you indicate the coordinate that vertex should apply to, using the command glTexCoord2f(s, t), where s is the X-coordinate and t is the Y-coordinate of the point on the texture that should line up with the vertex. You call glTexCoord2f() right before the vertex you want to apply it to:

texture.use();
glBegin(GL_TRIANGLES);
  ...
  glTexCoord2f(0, 0);
  glVertex3f(0, 0, 0);
  ...
glEnd();
glBindTexture(GL_TEXTURE_2D, 0);

Using Textures In Your Model

When you want to use a texture, you'll need to do the following:

1. Add a Texture2D field to your model class
2. In your model class's load() method, call the field's load() method

class MyModel : public Model {
  Texture2D checkers;
public:
  // Constructor for MyModel
  MyModel() :
  checkers("checkers.png")
  {
  }

  // Your load method
  void load() {
    checkers.load();
  }

  // Your draw method
  void draw() {
    // all geometry after this point will have the checkers texture
    checkers.use();
  }
};

If you want to get the texture's ID for more advanced stuff:

GLuint textureID = texture.getID();

If you want to use another texture, just call that texture object's use() method. To stop using textures, call:

glBindTexture(GL_TEXTURE_2D, 0);

Surface Normals

Surface normals are perpendicular to the plane that's tangent to a surface at a given vertex. Surface normals are used for lighting calculations, because they help determine how light reflects off of a surface. Each normal is sent by calling glNormal3f(x, y, z) before the call to glVertex3f(), much like texture mapping.

In OpenGL, we often want to approximate smooth shapes like spheres and cylinders using only triangles and quadrilaterals. One way to make the lighting look smooth is to use the normals from the shape we're trying to approximate, rather than just making them perpendicular to the polygons we draw. This means we calculate the normals for each vertex (per-vertex normals), rather than each face (per-face) normals. Shaders allow us to get even smoother lighting, calculating the normals at each pixel. You can compare these methods below:

Per-face	Per-vertex	Per-pixel

A hierarchical model is a way of grouping together shapes and attributes to form a complex object. Parts of the object are positioned relative to each other instead of the world. Think of each object as a tree, with nodes decreasing in complexity as you move from root to leaf. Each node can be treated as a single object, so that when you modify a node you end up modifying all its children together. Hierarchical modeling is a very common way to structure 3D scenes and objects, and is found in many other contexts. If hierarchical modeling is unclear to you, you are encouraged to look at the Hierarchical Modeling lecture notes.

Your Task:

You must come up with a character that meets these requirements:

1. Uses glTranslate(), glRotate(), and glScale() in meaningful ways.
2. Has at least two levels of branching - There must be at least two instances in your model where you draw something, save the current matrix, apply an affine transformation such as glTranslate(), glRotate() or glScale(), draw something else, then return to your previous matrix, apply a new transformation, and draw something else. You must also use glPushMatrix() and glPopMatrix() to nest your matrix transformations (see below for details). Here's a pseudocode example of a minimal solution, along with a scene graph:

   draw geometry
   push matrix
     translate up
     draw geometry
   
     push matrix
       translate left
       draw geometry
     pop matrix
   
     push matrix
       translate right
       draw geometry
     pop matrix
   pop matrix
   push matrix
     translate down
     draw geometry
   pop matrix
       

3. Has at least 1 multiple-joint slider that controls multiple joints or components of your model. For example, you might have your character waving, which would require that you control the shoulder and elbow joints simultaneously.

Making a Model

You will want to make a model to draw your character, by extending the Model class in model.h:

class MyModel : public Model {
public:
  // Constructor for MyModel
  MyModel() {
  }

  // Draws the model onscreen
  void draw() {
    // ... call your drawing functions here ...
  }
};

The easiest way to get started is to just modify the existing Scene class in sample.cpp. It extends Model, and in the main() method at the bottom, an instance of it is given to ModelerUserInterface to be displayed onscreen. Later on, you can create your own Model subclass and add it to the Scene class, much like the PointLight and DirectionalLight Models are added. See sample.cpp for details.

Adding Properties To Your Model

A property is an aspect of your model that the user can control. Modeler represents different types of properties with Property classes in model.h:

	RangeProperty stores a single number that's within a continuous range.
	RGBProperty stores a color's red, green, and blue components. Modeler lets you set it with a color picker.
	BooleanProperty is either true or false. Modeler lets you set it with a checkbox, making it useful for showing or hiding parts of your model.
	ChoiceProperty has an integer value from 0 to N - 1, where N is the number of choices it has. You can assign names to each choice, and Modeler will show the names in the control panel.

To add a property to your model class, do the following:

class MyModel : public Model {
Make sure protected: comes before properties, unless you want to be able to access them from other classes (in that case, use public:).
protected:
Add the property here:
  RangeProperty height;
public:
  MyModel() :
put constructor here, after the above colon
    height("Height", 0.0f, 10.0f, 0.0f, 0.1f)
  {
Add the property to the model's GroupProperty, which is a group of properties that's a property of every Model.
    properties.add(&height);
  }

  void draw() {
Use your new property's value for something:
    glScalef(0, height.getValue(), 0);
  }
};

Now, when you open Modeler, a control for your property appears on the left panel.

For further details on each property class, look in model.h. To see how they are added to models, look at the skeleton code's sample model in sample.cpp.

WARNING: If you try to set the value of a property of your model by calling setValue(), setRed(), etc., the slider, color picker, or checkbox corresponding to that property will not be updated to show that property's new value. This problem is an oversight in the design of the new Modeler, but will not prevent you from completing the project requirements. If you find yourself needing to set your model's properties, consult your TA's, because you might not be using the Model class the way it was intended to be used.

Affine Transformations in OpenGL

The graphics primitives you have (box, sphere, and cylinder) only accept parameters that define their dimensions. That means you can draw a box, sphere, or cylinder of any size, but it will always be at the origin with the same orientation. What if you want to move it somewhere else, or rotate it to a different orientation -- and you can't edit the primitive's drawing code?

In OpenGL, every vertex is multipled by the modelview matrix, then by the projection matrix:

• Modelview Matrix - transforms a point into eye / camera space, where the camera's eye is at the origin, looking down the -z axis, with its up-vector aligned with the +y axis.
• Projection Matrix - transforms a point from eye / camera space into normalized device space, which is a 2D plane that represents your screen surface. Its coordinates go from -1 to 1 on each axis, and conversion to pixels is done depending on the size of your OpenGL window.

Since Modeler takes care of projection, you'll modify the modelview matrix. OpenGL has several functions that create matrices for common transformations, then multiply them by the modelview matrix:

• glRotatef(degrees, x, y, z) - Rotates all vertices by degrees degrees around a line with slope vector <x, y, z> that passes through the origin. Use the right-hand rule with the vector to determine the direction of rotation.
• glTranslatef(x, y, z) - Add <x, y, z> to all vertices.
• glScalef(x, y, z) - Multiplies all vertices by <x, y, z>, producing a scaling effect relative to the origin.

If you called glTranslatef(1, 0, 0), then called glutSolidSphere(1, divisions, divisions), the sphere would be drawn centered around (1, 0, 0) because all of its vertices had 1 added to their X-coordinates. Each transformation has the effect of creating a "model space" with its own origin and axes. The sphere was drawn at the origin of a model space created by glTranslatef(1, 0, 0).

Hierarchical Transformations in OpenGL

Once you have applied a transformation to the modelview matrix, it will be applied to EVERY point sent to the graphics card forever! To undo the transformation, you need to remember the matrix's contents.

• Use the glPushMatrix() function to push the current modelview matrix onto OpenGL's internal stack.
• Then, use glPopMatrix() to pop the last pushed matrix off that stack and copy it into the modelview matrix.

Make sure you match each glPushMatrix() with a corresponding glPopMatrix(), so that your modelview matrix is returned to its original state. This makes it easy to "nest" your transformations:

// Here, modelview matrix is in world space
glPushMatrix(); // save world space matrix
  // Still in world space
  glTranslate(1, 0, 0);
  // Now in model space (everything translated left by 1).
  glutSolidSphere(1, divisions, divisions);

  // Here's a "nested" transformation.  After the corresponding glPopMatrix(),
  // we'll be back in model space.
  glPushMatrix(); // save model space matrix
    // Still in model space
    glTranslate(3, 0, 0)
    // Now in "model space 2"
    glutSolidSphere(1, divisions, divisions);
  glPopMatrix(); // copy model space matrix into modelview matrix
  // Back in model space
glPopMatrix(); // copy world space matrix into modelview matrix
// Back in world space

A shader is a program that controls the behavior of a piece of the graphics pipeline on your graphics card.

• Geometry shaders can turn a single point into multiple points. They are useful for advanced modeling, e.g., refining a coarse triangle mesh into a smooth surface with many triangles, but require very recent graphics hardware and are not part of the core requirements of this project.
• Vertex shaders are run once for each vertex in your model. They transform it into device space (by applying the modelview and projection matrices), and determine what each vertex's properties are.
• Fragment (or pixel) shaders are run once for every pixel to determine its color.

Shaders determine how the scene lighting affects the coloring of 3D surfaces. In OpenGL, there are two basic kinds of lights:

• Point Light - a light that is emitted from a point in world space. The intensity of the light is attenuated (reduced) based on how far it travels from this point. In the physical world, the intensity of a point light decreases with the square of the distance. We can model this with quadratic distance attenuation: dividing the intensity by some function a*r^2+b*r+c, where r is the distance from the light source and a, b, and c are chosen arbitrarily.
• Directional Light - a light that always hits a surface from a certain direction, no matter where it is. It has no attenuation.

A shading model determines how the final color of a surface is calculated from a scene's light sources and the object's material. We have provided a shader that uses the Blinn-Phong shading model for scenes with directional lights. See lecture notes for details on the Blinn-Phong shading model.

Your Task:

Add support for the scene's point light, by editing the files shader.vert and shader.frag. You need to include quadratic distance attenuation. Please open these files and read the comments for details.

• gl_LightSource[1].position stores the point light's position.
• gl_FrontLightProduct[1] is a structure that contains the material properties of the object (ambient, specular, and diffuse colors) multiplied by the point light's ambient, specular and diffuse colors.
• You can visit this site for a helpful tutorial with code included!
• Hint: you may not have to edit one of the files.

We have provided the sample solution modeler_solution.exe in your repository, which lets you compare your shader to the (correct) sample solution shader. To choose which shader to show, click on "Scene" and click the radio button for the shader you want to use. The sample solution also contains both a point light and a directional light for you to manipulate. Click the "Point Light" or "Directional Light" on the list in the top left corner to edit a light's properties or move it around. The difference feature in the sample solution will compare your shader to the solution shader for you. To use it, select "Difference" under "Shader To Use." Any differences between your shader and the solution shader will become highlighted in the display window. Differences are highlighed by color channel, so if the red is different, then you'll see a bright red pixel, if the green is different, you'll see a bright green pixel, etc. If there are no differences between the two shaders, the entire image should appear black. If there are a few thin highlights along the edges, that is ok since it is probably due to differences in rounding and you will not be counted off for it in grading.

Tips for Using the Sample Shaders

Ashikhmin Anisotropic Shader - This shader uses the Ashikhmin-Shirley lighting model to produce an anisotropic reflection effect. To see the effect, try setting either the Anisotropic X or Anisotropic Y slider close to 0 (0.1), and scale up the other one to see highlighting in different tangent vector directions, then move the camera around the object.

Ward Anisotropic Shader - This shader uses the Ward lighting model to produce an anisotropic reflection effect. Again, to see the effect, try setting either the Anisotropic X or Anisotropic Y slider close to 0 (0.1), and scale up the other one to see highlighting in different tangent vector directions, then move the camera around the object. Additionally, manipulating the "shininess" factor will affect this shader. Manipulate the In(Specular Exponent) slider to see this change.

Schlick Shader - This shader uses the Schlick approximation to the Fresnel term of the specular reflection. The Schlick N1 and Schlick N2 sliders control factors that simulate indices of refraction, with 1 being the index of refraction of a vacuum, and very close to that of air. To see a change in specular highlighting, try setting one of the sliders near 1 and scaling up the other. When the sliders are roughly equal to each other, there will not be much of a highlight (i.e. light doesn't refract much when passing from air to air).

Diffraction Shader - This shader implements a diffraction effect. To see it in action, select a Diffraction Color (convenience of labeling - it is a color that will permeate the object similar to diffuse or specular), then spin the camera around the object to see the diffraction effect.

You can use the sample solution Modeler to develop some of these shaders, but others require texture maps to be provided -- which the sample solution may not provide to your shader.

Using Shaders In Your Model

Shader files are loaded, compiled, and linked by ShaderProgram objects. If you want to add a shader:

1. Add a ShaderProgram field to your model.
2. Call its constructor after the colon for your model's constructor.

The ShaderProgram constructor takes three filenames:

1. Vertex shader
2. Pixel shader
3. Geometry shader (omit this parameter unless you actually have one)

class MyModel : public Model {
public:
  Texture2D texture;
 
 
 
  ShaderProgram shader;

  // Your model constructor
  MyModel() : // after this colon go the constructors for your shaders,
              // textures, and properties:
    texture("checkers.png"),
   
   
   
    shader("shader.vert", "shader.frag")
  {}
};

If you have an error in your shader code, YOU DON'T HAVE TO RESTART MODELER! Instead, fix your shader, then go to File->Reload Textures And Shaders.

Now, if you made a ShaderProgram field called shader, you could use that shader in your draw() method like this:

shader.use();

This shader will be applied to all subsequent geometry.

If you want to use another shader, just call that shader object's use() method. To stop using shaders, call:

glUseProgram(0);

If you want to get the shader program's ID for more advanced stuff:

GLuint shaderProgramID = shader.getID();

You will need to implement each of the following curve types:

• Bezier (splined together with C⁰ continuity)
• Catmull-Rom
• B-spline

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.

Skeleton code for 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, B-Spline, and Catmull-Rom.  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 and B-spline curves should be endpoint interpolating. This can be done by doubling the endpoints for Catmull-Rom and tripling them for B-spline curves.

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.

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 the sphere in the default scene (or a sphere you create) and at least one additional primitive of your choice in your scene. A natural choice for the additional chosen primitive is the ground plane of your scene. Your particles should bounce off of the sphere and 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. Note that the sphere should be able to be moved and the particle collisions should collide with the sphere's current position, not just its original position. The sphere collision should be "natural" - i.e. the particles colliding with the sphere should reflect off the sphere dependent on the sphere's normal at the point of collision and the particle's incoming velocity direction.

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.

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; }  

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.

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.)

Each group should turn in their own artifact. 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 the final submission (an H.264 MP4 file). You can play with settings to produce different encodings for your own purposes, but the final submission must be an H.264 MP4.

• 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 and a snapshot) by copying it into your turnin/artifact directory, and uploading it to the Catalyst.

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