COMP360/560 Lab 4 : Hidden Surface Removal

Due Date: December 2, 2016, 11:55pm

1  Overview

In this project you will write a program to load and display 3-dimensional polygonal models. You will be provided with a viewer that performs rendering with the OpenGL library. You will implement two other renderers for hidden surface removal: one using Z-buffers, and one using binary space-partition (BSP) trees. This project is worth 100 points.

This project is required for those taking COMP560 but optional for those taking COMP 360 (as extra credits).

You may work with a partner on this lab. Each pair only needs to submit one completed lab.

Important: If you find any bug in the project that you think was already there in the starter code and for which you are not responsible, report the issue to the TA ASAP.

2  Program Overview

We will provide you with a framework upon which you can build your project. By default, the program will load in a scene file called default.txt and render a polygonal representation of the model.

The user can interact with the program by pressing certain keys as specified below. Pressing keys allows the user to switch renderers or switch shading models. The user can also rotate the model or zoom in on the model by using the mouse.

2.1  Polygonal Model Viewer using OpenGL

The first renderer using OpenGL has been provided for you. You can use this renderer as a comparison for the other renderers. The OpenGL renderer should respond to the following keys:

• o: Enable the OpenGL renderer (disabling whatever renderer was active previously).
• f: Enable flat shading, overriding the previous setting.
• g: Enable smooth (Gouraud) shading, overriding the previous setting.

2.2  BSP Trees Algorithm (50 Points)

The second renderer is based on BSP trees. Whenever you load a polygonal model (including when you start the program), you should calculate the BSP-tree representation of the model. The algorithm and data structures you need will be covered in class.

To render a BSP tree, you should project polygons onto the viewing plane and draw them in two-dimensions using the GL_TRIANGLES primitive and glVertex2d(). The BSP tree should also handle all depth issues between different polygons, so GL_DEPTH_TEST should be disabled as well. In addition, your BSP tree renderer must perform its own lighting calculations and set the color of each vertex manually. Thus GL_LIGHTING should be disabled while this renderer is active.

The BSP tree renderer should respond to the following keys:

• b: Enable the BSP tree renderer (disabling whatever renderer was active previously).
• f: Enable flat shading, overriding the previous setting.
• g: Enable Gouraud shading, overriding the previous setting.

2.3  Z-Buffer Algorithm (50 Points)

In the Z-buffer renderer, you will duplicate in software what OpenGL does in hardware. You will also implement the third shading model, Phong shading. The algorithm and data structures you need will be described in class.

Within the Z-buffer renderer, you may only use OpenGL to draw a buffer of pixels (with glDrawPixels()).

The Z-buffer renderer should respond to the following keys:

• z: Enable the Z-buffer renderer (disabling whatever renderer was active previously).
• f: Enable flat shading, overriding the previous setting.
• g: Enable Gouraud shading, overriding the previous setting.
• n: Enable Naive Phong shading (as described in the textbook), overriding the previous setting.
• s: Enable Phong Shading with spherical linear interpolation (as described in the textbook).

2.4  Summary

The following table summarizes the shading models and features that must be supported by each renderer:

2.5  Implementation Notes

• Remember that constructing a BSP-tree involves splitting polygons and that splitting a triangle may result in a four-sided polygon. You should further split four-sided polygons into triangles to maintain the invariant that your BSP-tree nodes represent triangles only.
• For both BSP and Z-buffer, you will need to project points from 3D space to the 2D viewing plane. This projection can be done with the pseudo-perspective projection as described in the textbook. However, in the given code, we have provided you with a projection matrix (_view->getProjection()) that is OpenGL's equivalent to pseudo-perspective projection. For a 3D point x and the projection matrix P, you just need to multiply x*P and divide by the mass to get the projected point x'. The third component of the x' (the z-component: x'[2]) is the pseudo-depth. Additionally, OpenGL keeps a modelview matrix (M) for modeling purposes. So the actual multiplication is x'= x*M*P and remember to divide by the mass of x'. In the projected space, the viewing window corresponds to the square with two opposite corners at (-1,-1) and (1,1).
• To compute the specular component of the Gouraud and Phong shading models, you need to know the position of the eye in 3D space. The 3D eye position can be computed by taking the 2D point (0,0) with pseudo-depth 0 and undoing the projection as described above.
• When rendering using BSP trees with the Gouraud shading model, sharp lighting differences may occur at the edge and point where a triangle is split. This artifact, caused by the specular lighting, is the limitation of the rendering model, but you may ignore this issue. Although this issue usually rarely happens, it can be hand-created easily.
• The OpenGL specular component is not the same as the specular component as described in the textbook (see OpenGL reference on Lighting). You can try the OpenGL implementation as a way to see if your shading is consistent with OpenGL's shading. However, you should use the textbook's equation in your final submission.
• Since this lab is implementation-intensive, you should keep your code clean and organized.
• Once you have the program working correctly, try to optimize your code for efficiency. In particular, make sure your program does not leak memory over time. Also remember that running in Release Mode is faster than in Debug Mode.
• Your program may assume that input files are well-formed.
• A normal is a 3D vector so its fourth component is 0. Make sure when you are normalizing a vector in 3D, that the fourth component of the homogenization of the vector is 0.
• To debug or visualize normal vectors, you may use their coordinates as actual object colors. In this case, you may have to adjust value ranges from [-1,1] to [0,1]. Then the colors should vary smoothly on smooth surfaces and correspond to correct directions. For example, points on the surface facing the positive x-direction might appear red if we map the x-coordinate of the normal to red in RGB.
• Common and potential mistakes:
  • forget to reset homogeneous coordinates correctly (1 for points, 0 for vectors),
  • normalize some vectors when you shouldn't,
  • forget to normalize vectors when you should (e.g., normal vectors),
  • use exact equality for floating-point numbers (precision errors).

3  What To Turn In

Use the given lab_hidden_surface directory. This directory should contain your source code and all files needed to build your program in Visual C++. You need not submit any image file as in the previous labs. Also include a README file containing:

• The names of you and your partner.
• A brief overview of any major modification to the code.
• Any known bugs or incomplete features.
• Any other implementation details you think your grader should know.

Zip up this folder and follow the instruction on the course web page for submission.

4  Model File Format Overview

The code for reading the model has been completed for you. The following is for your reference in case you would like to create your own test model file. Input files are ASCII text files containing a series of numbers separated by spaces. The input file has three parts:

1. Material Attributes
2. Lighting Attributes
3. Polygon Data

4.1  Material Attributes

The first seven values in the input file specify the material properties of all polygons in the model. These properties appear in the input as follows. As usual, colors are specified by their red, green, and blue (RGB) components.

1. The object's ambient coefficients (three floating-point values between 0 and 1).
2. The object's diffuse coefficients (three floating-point values between 0 and 1).
3. The object's specular coefficients (three floating-point values between 0 and 1).
4. The object's specular exponent (one floating-point value).

4.2  Lighting Attributes

After the description of material properties, the input file describes the definition of at least one light source. The scene's lighting attributes are given in the format identical to the lighting information in the ray tracing lab's input files.

1. The scene's ambient light color (three floating-point values).
2. The number of point light sources in the scene - must be at least 1 (one integer).
3. For each point light source:
   1. The light's position in space (three floating-point values).
   2. The light's color (three floating-point values).

4.3  Polygon Data

Polygon data is given in two sections. The first section enumerates the coordinates for all the vertices that will be used in the polygons. Coordinates are given as floating-point triples (x,y,z). In class we called this data the geometry of the model.

In the second section, the polygons are given as sets of integers, with three integers per polygon (our models consist only of triangles). Each integer is an index into the array of vertices defined in the geometry section. Note that indices start from zero. In class this data was called the topology of the model.

Formally, the polygon data are given as follows:

1. The number of unique vertices in the model (one integer).
2. For each vertex:
   • The vertex's position in space (three floating-point values).
3. The number of polygons in the model (one integer).
4. For each polygon:
   • The indices into the vertex array of the vertices of the polygon (three integers).

Below is an example of the polygon data for a small model. (Our input files do not contain comments.)

4          // Number of vertices
0 0 0      // Coordinates of 0th vertex
0 0.1 0.1  // Coordinates of 1st vertex
0.1 0 0.1  // Coordinates of 2nd vertex
0.1 0.1 0  // Coordinates of 3rd vertex
4          // Number of triangles
0 2 1      // First  polygon, consisting of 0th, 2nd, and 1st vertices
0 1 3      // Second polygon, consisting of 0th, 1st, and 3rd vertices
0 3 2      // Third  polygon, consisting of 0th, 3rd, and 2nd vertices
1 2 3      // Fourth polygon, consisting of 1st, 2nd, and 3rd vertices

Note that triangle vertices are ordered counterclockwise. That is, a polygon's vertices are listed in counterclockwise order around the outward-facing normal of the polygon. You will need to use this information to determine the normals of each polygon.

The files folder in the given code contains several test models. You may add more models as desired.