CMPS 160: Introduction to Computer Graphics

Pages

• home
• lectures
• assignments
• exams
• labs
• syllabus
• online resources

Links

• staff
• discussion forum
• previous offerings

terrible terrains

Goals

By the time you're done with this assignment, you will have learned:

1. How to read and process image files.

2. How to draw 3D objects with perspective projection using OpenGL.

3. How to texture map a heightfield.

4. How to use transformations to move the camera.

5. How to create simple animations and respond to user feedback.

background

In this project we'll be visualizing terrain data available from the Large Geometric Models Archive at the Georgia Institute of Technology. The terrains are provided as elevation maps: grayscale images whose pixel values are linearly proportional to the terrain's height. Each elevation map also has a corresponding texture.

We're providing two data sets for you to work with, the first being a section of the Grand Canyon. It represents a 245,820 x 122,940 meter area, and each 8-bit pixel unit in the elevation map corresponds to a 10.004 meter increment in height.

The second data set is from Puget Sound. It represents a 163,850 x 163,850 meter area, and each 16-bit pixel unit in the elevation corresponds to a 0.1 meter increment in height.

Getting Started

We've already provided you with a sample OpenGL application. It demonstrates how to get a basic GUI program up and running with our support libraries and how to draw and animate a simple polygon using a 2D orthographic projection. You may want to add menus or toolbars to your program: the support library has documentation that will help you. If you don't read the documentation, you will likely end up wasting time duplicating functionality that has already been implemented for you.

If you run into trouble while working on your project, you have several avenues available to you. Ask questions in lab, post a message on the course discussion group, or come to the instructor's office hours.

Using other systems or frameworks

Because libgfx is extremely platform independent, using it ought to allow you to develop your code on one system and trivially port it to another. However, we only officially support the library on the iMac machines in the College 8 lab, so if you run into machine- or platform-specific problems on another system, we may not be able to help you. In order for your project to be graded in lab, you must make sure that it compiles and runs on the lab machines. If your project does not compile when we attempt to grade it, you will receive very few points, if any.

You may use a different GUI toolkit (e.g., GLUT, SDL) if you like. If you decide to do this you must:

1. Cleanly separate your GUI code from your project implementation so that the graders can easily find it
2. Turn in all the files necessary to compile and run your program
3. Clearly explain in your Readme file how to compile and run your code with your GUI toolkit of choice.

It is also possible to develop your project on another platform. However, you must contact the instructor at least 72 hours before the due date and make separate arrangements for the demo and grading of your program. Generally speaking, the instructor is willing to travel to any room in the Baskin Engineering and Engineering 2 buildings to see your demo, but will not venture any farther from the comfortable confines of his office.

Requirements

All students must implement the following required features.

[25 points] Basic Terrain Display
Your program should be able to read an elevation map and generate a corresponding polygonal mesh. In order for the mesh to be proportional to the actual dimensions of the terrain, you will need to provide a mechanism for the user to specify the height increment of the elevation map, as well as the width and length of the terrain (this mechanism need not necessarily be interactive).

[20 points] Shading and Texture Mapping
You should display your terrain mesh as a solid, diffuse surface with lighting enabled and at least a single point light in the scene. You do not have to calculate per-vertex normals for this assignment: flat shading will be sufficient. Additionally, you should be able to apply the associated texture map to your terrain geometry, and provide an interactive way to toggle texturing on and off. You will have to generate appropriate texture coordinates for your mesh as you construct it.

[25 points] Camera control
Your program should utilize a perspective camera that can be interactively controlled by the user via mouse or key press. You should provide pitch, head, and roll rotations in addition to forward and backwards translation of the camera in its local coordinate frame. You may not use the arcball or trackball classes in libgfx to provide this functionality: you must implement it on your own.

[10 points] Level-Of-Detail Simplification
Modern elevation maps are typically high-resolution images, corresponding to polygonal meshes containing several million polygonal faces. This level of geometric detail is pushing the limits of what our lab machines can display at interactive rates. To combat this problem, your program should be able to create a downsampled version of the current elevation map in memory, and use the downsampled image to generate a smaller polygonal mesh. A simple way to go about this is to repeatedly apply a 2x2 box filter (in which each pixel of the downsampled image is simply the average of the corresponding four pixel square in the original map) until the desired resolution is reached. However, you may use a more complex simplification scheme if you so desire.

You must implement this downsampling directly: you may not link to an external image-processing library or preprocess the elevation maps (although you may wish to do the latter during development to facilitate testing). Note that it is not necessary to downsample the corresponding texture images, since texturing is done on a per-pixel basis and thus has a complexity cost independent of tessellation.

[20 points] Coding and Presentation
Graphics is fundamentally a visual field, so it's important that your project have a clean interface and be pleasant to look at. Likewise, we expect all code to be reasonably well designed and written. In particular, ugly, inscrutable, or ridiculously inefficient code and/or user interfaces will be heavily penalized.

Tips and Hints

• Check this page regularly for hints and updates.
• When setting up perspective projection with gluPerspective(), you'll want to use an aspect ratio that's the same as the aspect ratio of the window.
• If you use the key_press() function to handle camera movement, make sure you call canvas->redraw() to redraw the scene. You should never call setup_for_drawing() or draw_contents() explicitly.
• To make your program more efficient (and thus allow you to display larger versions of the terrains), you may want to experiment with the glGenLists(), glNewList(), and glCallLists() functions.
• When implementing camera control, you'll almost certainly want to use built in OpenGL transformation functions (like glRotate()) instead of constructing the transformation matrices on your own.
• To get smoother key navigation, try moving your key handling code from GUI::key_press() to GUI::update_animation().
• Note that while the Puget Sound data is 16-bit, libgfx image routines such as read_image() convert these to 8-bit images. This will affect the height increment you use for this data.

Reference Implementation

Your incredibly talented and dilligent TA has provided a reference implementation for you to play around with. Note that your program is not required to exactly duplicate all the functionality present in this implementation. Rather, its purpose is to give you a general idea of what your program should do. Binaries are currently available for Windows and OS X.

The controls for the reference implementation are as follows:

• Click+drag with the left mouse button to change pitch and heading.

• W, A, S and D translate forward, backward, left and right respectively.

• Q and E change roll.

• 1, 2 and 3 will toggle a wireframe view, texturing and lighting respectively.

• 4 will draw a red sphere at the light position. When the light is showing, the middle and right mouse buttons (alternatively, ctrl+left button and shift+left button) will move it.

Handing in your Project

Follow all handin instructions carefully. If you do not hand in all of the required files in the proper fashion, your project will not be graded and you will receive no points.

You must turn in the following files:

• All source and header files (e.g., *.cxx, *.h).

• All XCode files, makefiles, project files, etc. needed to compile your program.

• A ReadMe file named README.txt that contains the following information:

  • Your name and MyUCSC ID.
  • If you used a different GUI kit, instructions on setting it up on the iMac machines in the lab.
  • Clear documentation explaining how to use each feature you implemented.
  • A full and complete annotated bibliography of every source that contributed to the development of your project.
  • Anything else you think the grader should know about your work.

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

• Do not turn in executables or other unnecessary files generated during compilation. Doing so will waste disk space and may incur a substantial point penalty.

To actually turn in your finished project, follow the hand-in instructions that we have provided. The assignment name for this project is "MP1".

Grading

During grading, we may test your program with different data sets than those we have provided to you. Therefore, you should ensure that your code is reasonably general and provides a nice interface to load different elevation maps.

Before you begin work, you should make sure that you've read the policies on grading and academic integrity in the course syllabus. Any questions as to what constitutes acceptable behavior during the development of your project should be directed to the instructor via email or the course discussion group.

Late projects will not be graded and will receive no credit. If you believe you will be unable to finish your project by the due date, you should contact the instructor at least 72 hours in advance to discuss the particulars of your situation.

A required part of the grading process will be a live demo of your finished project. You will not receive any points for your project until it has been demoed. Demos will typically occur during your scheduled lab session and will take about 10 minutes per student. However, you may arrange to demo your program to the instructor if you prefer. Such arrangements must be finalized at least 72 hours before the project is due.