MP1: War of the Meshes

Assigned: Thursday, February 9, 2006

Due: Monday, February 27, 5:00pm

In this project, you'll be implementing a simple program for displaying terrains along with mesh objects , such as an animal or a spaceship. After completing this project, you should have learned:

How to set up and interactively update a 3-D camera model.
How to perspectively draw 3D mesh objects in OpenGL.
How to light 3D objects with the simple Phong illumination model.
How to texture map a surface.
How to move 3D objects according to user control.

We are providing you with a simple starter kit. It demonstrates how to get a basic GUI program up and running with our support libraries. It also shows you how to draw a single polygon that can respond to user command(mouse input). Reading through the comments in the demo will be very helpful. Included in this archive are build files for Linux. This starter kit is built on top of the ligfx support library. You may need to add menus or text file support to your program as needed, and the support library has documentation that will help you. We encourage you to read through it. In the "Online documentation" section, the "Minimalist GUI framework" (MxGUI) part and the Simple GUI Program part maybe a good place to start.

If you have trouble with any part of the project preparation, please see an instructor or TA during their office hours. Alternatively, post a message on the course newsgroup (news.cs.uiuc.edu/class.cs418). We usually check the newsgroup regularly and will attempt to respond promptly to questions posted there.

Using other systems or frameworks

Because libgfx runs on a number of different platforms, using it ought to allow you to develop your code on one system and port it to another. However, we only officially support the library on the Linux machines in 0216 Siebel, so if you run into machine- or platform-specific problems on another machine, we may not be able to answer your question. Additionally, you must make sure your code does compile and run on the machines in 0216 Siebel.

Sample Models

To help you in preparing an interesting project, we are providing you with a selection of sample mesh models. You are free to use all, some, or none of them. We are also providing you with some sample code for reading OBJ files. This is a very limited OBJ parser, but it should be able to handle all of the OBJ files we have provided.

Terrain Data

We are providing you with two sample datasets for this project: one for the Grand Canyon and one for Puget Sound. The data itself consists of two parts: a grayscale height map and an RGB color map. These are both just TIFF files.

Each dataset is described by a ".terrain" file. Here is an example:

60 40 4096
data/gc_z.tif
data/gc_tex.tif



This file describes the Grand Canyon data set.  The first line provides 

the dimensions of the data set, specifically the:


- pixel_spacing of original data (s)    [60m between samples]

- height_unit (h)                               [40m per unit gray level]

- width of original data (w)            [4096 pixels]


Following this information are the filenames of the height field and the

texture image, respectively.


Since the terrain data we use is a downsampled version of the original data,

so the actually pixel_spacing need to be calculated from the original spacing

like this:


Suppose the width of gc_z.tif is w'. Then we know that the current data is 

downsampled from the original data at a rate of r=w/w'. So the current pixel 

spacing should be s'=s*r, and h is unchanged. This means for a pixel (i,j), 

its world coordinate should be:


( s'*i, s'*j, h*z(i,j) )



You can find the original data at:

http://www.cc.gatech.edu/projects/large_models/gcanyon.html

gc.terrain

puget.terrain

Requirements

All students must implement the following required features.

[30 points] Terrain Display

You should render one terrain during every run of your program. The terrain should be displayed as a 3D triangle mesh constructed by yourself. When drawing the terrain mesh, use the filled polygon mode. You may use any polygonal primitive of your choice (e.g., triangles, triangle strips, etc.).

You must apply the texture image accompanying each terrain as a texture map on the surface instead of as colors for the polygons, and you may assume that the image's dimensions will always be powers of 2.

[30 points] Object Rendering

Your program should be able to load and render multiple (at least three) aforementioned sample models in addition to the terrain during every run of your program. The rendered models should be scaled to the right size and be placed appropriately. For example, a CAMEL model should stand on the terrain while a SPACESHIP should fly over the terrain. The models should not intersect with each other.

When drawing the sample models, use the filled polygon mode.

You should be able to draw the mesh surface with lighting enabled, with a minimum of two point lights. Make sure that your surface exhibits both diffuse and specular reflection. You should implement both flat shading and smooth shading. For flat shading, one normal is needed for each face. For smooth shading, calculating normals at mesh vertices is necessary. This can be done by averaging the normals of the faces surrounding a vertex.

[30 points] Camera Control
You should use a perspective camera model. The user should be able to interactively move the camera around this world. The following camera motions should be supported:

Move camera Forward/Backward.

Spin the camera Left/Right (turn your head left and right).

Tilt the camera Forward/Backward (tilt your head to look up and down).

Rotate the camera around its viewing direction.

All camera movements should be controlled interactively, either via the mouse or via key presses. You can use controls that is most natural to you, and need not follow those in the demo program. Make sure to document them clearly in your README file.

In order to receive full credit, 1-unit graduate students must also implement the following additional features.

[25 points] Object Manipulation
The user should be able to choose one of the displayed objects, not including the terrain, and control the motion of that object only. The viewpoint and the viewing direction should remain fixed during such manipulation. The following user interactions must be supported:

Define the velocity vector of the selected object. The object should start to move along the velocity vector.

Adjust the velocity of the selected object. The magnitude of the velocity can be either increased or decreased.

Adjust the direction of motion by applying rotation to the velocity vector. The same rotation should also be applied to the object so that the object appears to turn. We do not have a unified interface for this part. What matters is that you have a way for the user to perform arbitrary rotations around the center of the object while it is moving. Rotation around the coordinate axes only would NOT be sufficient. You may choose a reasonable method for specifying rotations, such as CTRL-dragging the mouse.

The final components of your grade will be the following. Notice that this brings to total number of points for this project to 125 for 1-unit graduate students and 100 for everyone else.

[10 points] Code Design
Your code should be well designed and well written. It should be easy to follow the logic of your program.

Tips and hints

Check back here often. Commonly asked questions on the newsgroup may be posted here in the future.
When setting up the perspective projection (e.g., with gluPerspective()) you'll want to use an aspect ratio the same as the aspect ratio of the window.
We recommend avoiding quad/triangle strips and fans, unless you already feel comfortable with OpenGL drawing code. While your project will be marginally more efficient, it is slightly more difficult to implement correctly.
If you used the key_press() function, don't forget to call "canvas->redraw()" to redraw the scene so that the changes will show up. You SHOULD NOT call setup_for_drawing() or draw_contents() explicitly, since the framework will do this for you automatically.

Handing in your Project

Important: Follow all handin instructions carefully. You may lose most or all points for failure to follow these instructions or if you do not hand in all required files.

You must turn in the following files:

All source, header and Make files (e.g., *.cxx, *.h) whether or not you have modified them.

A README file named README.txt. It should contain the following information:
- Your name and NetID
- Whether you are an undergrad, 0.75 unit grad, or 1 unit grad student.
- Clearly document how to use each feature you implemented, including inputting constants for equations if necessary.

Any other files (e.g., libraries, data files) needed to compile and run your program. If you've used the provided libraries, do not turn those in.

To actually turn in your finished project, follow the hand-in instructions that we have provided.

Grading

Code-sharing, working together with peers, and copying code from other sources are only allowed under restricted conditions. Make sure you read the code-sharing policy for details.

Significant reductions will be imposed for projects that do not compile. If a project is handed in late, there will be a 20-point reduction (25 points for 1-unit grads) for every 24-hour period after the deadline.