Computer Science 22C:251, Spring 2007

Tuesdays & Thursdays 9:30-10:45am, 110 MacLean Hall

[ Download the Syllabus ]

Professor: Chris Wyman
E-mail: cwyman@cs.uiowa.edu (Preferred contact method)
Office: 101J MacLean Hall
Phone: (319) 353-2549 (Please use e-mail when possible)
Office Hours: TTh 10:45-12:15, or by appointment.
Office Hours:(Note: Some days office hours may end early due to meetings)

Required Textbooks:
----1) Advanced Global Illumination (2nd Edition), P. Dutre, K. Bala, and P. Bekaert. AK Peters, 2006.
----2) Realistic Ray Tracing (2nd Edition), P. Shirley and R. Morley. AK Peters, 2003.

Alternative Textbook: (See syllabus for more information)
----Physically Based Rendering, M. Pharr and G. Humphreys. Morgan Kaufmann, 2004.

• (4/9/2007) -- An alternative method for implementing complex BRDF materials in your path tracer is to design a single material type that works for all BRDFs, allowing you to plug in new BRDFs as you design/implement them. Here is a simple class for doing this, though you may need to tweak things a bit to work in your code structure.
  • An abstract base class for BRDFs.
  • A concrete LambertianBRDF class that implements simple diffuse materials. [Header File (.h) ] [ Code File (.cpp) ]
  • The class BRDFMaterial (derived from the Material class) that implements shading for arbitrary BRDFs derived from the abstract class above. [ Header File (.h) ] [ Code File (.cpp) ]
• (4/2/2007) -- A pdf discussing the final project has been posted. If you haven't discussed ideas with me, you should talk to me about your thoughts for a final project. This will make sure I think your project is substantial enough (but not too large).
• (3/30/2007) -- Since a number of you are implmenting the Ashikhmin-Shirley BRDF for Homework #4, I thought I'd post an example scene and my result (using 4096 samples per pixel, explicit direct lighting on all surfaces, and a output gamma of 2.0). Also, the same scene with nu=nv=10, nu=nv=100, and nu=nv=1000.
  • Note: I used uniform random sampling of the hemisphere, not the sampling scheme proposed by Ashikhmin & Shirley. If you use their sampling scheme, you should get less noisy images as the n_u and n_v values increase.
• (3/29/2007) -- Sample code snippets from class for kd-tree construction and traversal.
• (3/22/2007) -- A modified Image.h and Image.cpp that allow you to pass the Image::Save() function not only a filename, but also a gamma value (for gamma correction as shown in the comparison below). The default gamma is 1.0, so you can directly replace the old image class with this one and see no difference. But it allows you to pass a second parameter to change the gamma of your saved image. You should be able to read and understand the code to modify your interactive ray tracer in a similar way.
• (3/22/2007) -- Here is a comparison between naive path tracing and explicit direct lighting (with 64 primary rays per pixel). Note that the reason most of the images look too dark is because they have not been gamma corrected to account for the non-linearity in standard display devices. Performing gamma correction with a gamma of 2.0 (see the image) brightens the result so you can compare it with the image on the Cornell Box web page. If you use spectral colors, it should be identical to the Cornell image. If, like me, you're only using RGB, it should just be "close".
• (3/22/2007) -- Here are links to papers about the Ashikhmin-Shirley BRDF, the Ward BRDF, and the Lafortune BRDF.
• (3/19/2007) -- I have posted Homework #4. It is due Tuesday, April 3rd. This should be a little easier than previous assignments, as there is only one problem, and you get to choose what to implement. Examples of the different choices to implement:
  • Object instances: 40 randomly oriented Buddhas, 500, 100000
  • Motion blur: a single ball with sinusoidal motion, one ball moving in front of another
  • Ashikhmin-Shirley BRDF: anisotropic 1, anisotropic 2, isotropic (Note: you should be able to get rid of the white dots)
  • Texture mapping: texturing in a "complex" scene, volume texture (taken from ATI web page), bump mapping (taken from Wikipedia)
• (3/19/2007) -- Performance tip: Use the Intel compiler instead of gcc. Using only the -O3 flag, the Intel compiler icc gave me about a 15% speed bump over gcc. The Intel compiler is installed on all the lab machines (though, sadly not on dpmlh045 yet), and you can use it simply by changing the line in the makefile that says "CC=g++" to "CC=icc"
• (3/14/2007) -- Notice the difference between the pathtraced Cornell Box at 64 samples per pixel if paths exceeding the maximum depth return black versus if they return white. Both scenes have a background color of white (1,1,1) and use the RGB values I've given you for the white, red, and green paints
• (3/7/2007) -- Greg has fixed the nanosecond-resolution timer code so it runs on MacOS X. Note that there are linking instructions down in the OS-specific part of the header.
• (3/5/2007) -- Here's a few of the issues we discussed on Thursday that you should think about if you implement object instancing.
• (3/2/2007) -- Scott reminded me that I haven't posted my list of C/C++ optimizations. Here it is.
• (2/27/2007) -- I have posted Homework 3, which is due Thursday, March 8th before class.
• (2/23/2007) -- I've posted a copy of one of my bounding volume hierarchies, for those of you who might still be having difficulties getting yours to work. I've named it ``NaiveBVH,'' though it actually uses an array representation internally. Get the files here: [ c++ file ] [ header file ]
• (2/16/2007) -- I've posted the updated classes for Mutexs, Barriers, and Threads below. I've also posted the snippets of code I showed for modifying your main routine, your display callback, and adding a worker thread fucntion for your multi-threaded ray tracer.
• (2/12/2007) -- Homework 2 is now available, and will be due before class on Tuesday, Feb 27th. The assignment covers ray packets, path tracing, and (for groups) spectral colors.
• (1/29/2007) -- An example scene rendered with a bounding volume hierarchy (The expected result, and a link to the OBJ model).
• (1/26/2007) -- Here is a copy of the fast ray-bounding box code we discussed on Tuesday.
• (1/22/2007) -- I have posted Homework #1. Before starting this, I would like you to e-mail me telling me who (if anyone) you plan to work with. If you do not have a group, but would like one, please tell me that as well.
• (1/17/2007) -- Here's a good paper about ray tracing efficiently. In particular, it discusses how to build and traverse the type of bounding volume we'll discuss in class tomorrow.
• (1/16/2007) -- We'll be talking about improving ray tracing performance with bounding volumes on Thursday (1/18). For next Tuesday (1/23), I'd like you all to write a simple ray-bounding box intersection routine. You can use whatever technique seems most obvious to you. Fill in the routine in this program, and them profile your results. We'll compare in class. Here are my results. This is throw-away code. I do not expect you to turn it in.
• (1/10/2007) -- This simple C code exhibits machine- and compiler-dependent results. We'll talk about why, but you might want to test it out yourself to see what I mean. Incidentally, the lab machines in 301 MLH (using gcc/g++) give boring results (i.e., what you'd expect), so you might want to try it out elsewhere. Visual Studio.NET 2003 gave the most interesting results (I bet 2005 would give the same behavior).
• (1/3/2007) -- I have updated the syllabus (which is mostly final, now) and the ray tracing framework I posted previously.
• (1/3/2007) -- Here is information about how to profile your code.

Student Web Pages:

• Noah Abrahamson and Rajeev Penmatsa
• Scott Davis
• Junjun Deng
• Jason Fries
• Jonathan Hall
• Patrick Kellen
• Dat Nguyen
• Greg Nichols and Qi Mo
• Michael Merickel
• Keith Perry
• Uday Verma and Thomas Hansen
• Yangfan Zhang

Code For Your Use:

This semester, you are welcome to build your assignments off a reasonably well designed ray tracing framework I've written. I also plan to give you various other classes, functions, and code snippets over the course of the semester, and I expect they will all work with this framework in a straightforward manner.

• A basic ray tracing framework. (Basic class descriptions available here and here.)
  • Provides functionality roughly equivalent to Homework #10 from 22C:151.
  • The framework contains both a Visual Studio.NET 2003 project and a Unix Makefile that compiles in MLH 301.
  • The framework loads scenes from a file, with the basic format demonstrated by: HW9_Scene and HW10_Scene.
  • A simple version of the Cornell Box. For the actual box data, see the Cornell web page. Also note that as given, the EPSILON value in the framework's "Definitions.h" is too small for this scene. You may wish to modify the code so the EPSILON can be specified in the scene file!
• A class encapsulating the XYZ spectral matching curves, sampled at 5 nm intervals: XYZSpectrum.h
• A random number generator class: Random.h and Random.cpp.
  • Useful for multi-threaded applications, where the use of drand48() becomes slightly less obvious.
  • Provides functions for uniformly randomly choosing points on a sphere, triangle, hemisphere, and disk.
  • Note: Only the RandomHemisphereVector() and [d/f/s]Random() functions have been exhaustively tested!
• Simple, self-explanatory semaphore and barrier classes, built on top of pthreads.
  • Mutex/Lock class: Mutex.h and Mutex.cpp.
  • Barrier class: Barrier.h and Barrier.cpp.
  • On Windows, download and install pthreads-win32 to use pthreads instead of native Windows threading.
    • Recommended! (Since your code must compile on Linux too).
    • You probably want to install and link to the pthreadVC2.[dll|lib] version of the library.
• A very simple thread class, built on top of pthreads: Thread.h and Thread.cpp
  • Usage:
    1. Thead newThread( < appThreadID > );
    2. newThread.Create( < threadEntryPoint > );
       • threadEntryPoint is of the form void *func( void *arg )
       • arg is a pointer to the current thread (i.e. "Thread *currentThread = (Thread *)arg;")
    3. Each instance of func does it's work independent of the calling process and other threads.
    4. func exits by returning (or by calling currentThread->Exit();)
    5. Other process can kill the thread by calling newThread.Kill( signal );
• A pair of functions to control the precision of your x86 floating point unit.
• A simple bounding box class.
• A header file defining functions for getting high-resolution (nanosecond) timings under Windows, Linux, and (untested) MacOS X.
  • Note: Under Windows, kernel32.lib must be linked with your executable, however this should be done automatically for you.
  • Note: Under Linux, librt.a must be linked with your executable. To do this, change the Makefile to include ``-lrt'' to the line defining the variable ``LIBS'' (which should now look like LIBS = -lrt -lpthread -lglut -lGL -lGLU -lX11 -lXmu -lXi -lm ).

Last Modified: Wednesday, January 3, 2007

Chris Wyman (cwyman@cs.uiowa.edu)