/ CMSC 435/634 Assignment 1

Overview

For this assignment, you must write a C++ program that will render spheres and triangles using ray tracing. The input is in a subset of the Polyray (.pi) text file format, containing information about the view and objects in the scene. You will read a .pi scene from a file, and ray trace the single image described there. Rays that hit an object should be rendered in the object's "diffuse" color, while rays that do not hit any object should use the background color of the scene. Do not try to include any of the more advanced ray tracing features you may read about (shadows, reflection, refraction, lights, etc.), we will get to those later. Your output should be an image file in PPM format.

Assignment Goals

The primary goals of this assignment are:

  1. Get experience converting vector equations into code
  2. Parse input file into appropriate data structures
  3. Compute ray directions over an image
  4. Compute ray-sphere and ray-triangle intersections
balls -s 3 -r 5 with random sphere colors

Input

All of the sample input files mentioned here have been checked into your trace/data directory. Do a git pull to get them.

Take the input .pi file as a command-line argment to your program. If that command line argument is an absolute path, starting with a "/" or a drive letter and a colon (e.g. C:), open it directly. Otherwise, build the path to the file to use from PROJECT_DATA_DIR plus the command-line argument. This will allow you to just use command line arguments like "balls.pi". In Visual Studio, set the command line argument in the Debug tab of the project properties. In XCode, set it under "Edit Scheme".

For the base assignment, you should be able to trace balls3-color.pi and color each intersection by the diffuse color of the object hit. While polyray format is relatively simple, even the subset we will be using this semester contains many features we will not be using in this assignment. For the basic assignment, you should only handle the following keywords: background, from, at, up, angle, resolution, define/.../diffuse, object/sphere and object/polygon. You can assume any polygons with more than three vertices are convex, and can be split into a fan of triangles (0,1,2; 0,2,3; 0,3,4; ...). For anything in the file that you do not handle, just keep reading until you find one of those keywords.

Additional .pi format scenes can be generated using a set of programs called the 'Standard Procedural Databases', using the "-r 5" command-line option to generate polyray-formatted output. A compiled copy of these programs can be found in ~olano/public/spd3.14/ on the UMBC GL Linux systems. The balls3-color.pi file was created using a simple script make each sphere a random color. Generate the original balls3.pi file with all spheres the same color on GL with this command:

~olano/public/spd3.14/balls -s 3 -r 5 > balls3.pi

In this command, the "-s 3" option sets the complexity level, and "-r 5" sets the output format. Complexity level 3 for this model consists of 820 spheres, The default balls.pi at level 4 has 7381 spheres, which can be quite slow to ray trace:

~olano/public/spd3.14/balls -r 5 > balls.pi

Other test files you should be able to render can be generated using the SPD commands mount (four spheres and a bunch of triangles), shells (tons of overlapping spheres), and tetra (tons of triangles).

Output

Your output should be a file named "trace.ppm" in the PROJECT_BUILD_DIR directory. Once you are happy with this file, copy it into the trace directory and commit it.

We are using the PPM image file format because it is exceedingly simple to write. See the specification for details. You are free to use the trace assn0 code as a basis. PPM colors use unsigned bytes, but colors in the .pi files are floating point numbers between 0 and 1. I recommend using floating point colors until it is time to assign the color into an image pixel. At that point, you should clamp the color to the 0-1 range (to avoid overflow), multiply by 255, and cast to unsigned char.

gears -s 2 -r 5

634 only

Students who are taking this class as CMSC 634 should also add the ability to trace arbitrary concave polygons. The "gears" SPD program will generate some concave polygons for the top and bottom of each gear. To do this, you can either use the test probe ray method of determining ray/polygon intersection; or research and implement a convex polygon triangulation algorithm (e.g. the ear clipping algorithm), then using the barycentric coordinate method on the resulting triangles.

Other people's code

Ray tracing is a popular rendering technique, and the internet contains lots of resources for ray tracers in general and things like ray-object intersection in particular. Other than the assn0 sample code, YOU MAY NOT USE ANY OUTSIDE CODE. All code that you use must be strictly your own.

Strategy

This is a big assignment. Start NOW, or you will probably not finish. No, really, I promise you will not be able to do it in the last two days. Even before we get to all of the details of the ray tracing itself, you can still start working on your file parsing.

I have created a separate page with some additional development suggestions.

What to turn in

Turn in this assignment electronically by pushing your source code to your class git repository by 11:59 PM on the day of the deadline and tagging the commit assn1. Do your development in the trace directory so we can find it.

Submit an image of your output for balls3-color.pi, replacing the trace/trace.ppm file. If you are a graduate student, also include a second ppm file in your trace directory with your output for gears2.pi.

Include a gfx26/assn1.txt file at the top level of your repository telling us about your assignment. Tell us what works, and what does not. Also tell us what (if any) help you received from books, web sites, or people other than the instructor and TA.

You must make multiple commits along the way with useful checkin messages. We will be looking at your development process, so a complete and perfectly working ray tracer submitted in a single checkin one minute before the deadline will NOT get full credit. Individual checkins of complete files one at a time will not count as incremental commits. Do be sure to check in all of your source code, but no build files, log files, generated images, zip files, libraries, or other non-code content.