CS 348B - Computer Graphics: Image Synthesis Techniques
Spring Quarter, 1998
Marc Levoy
Handout #30
Demos on Thursday, June 4
Writeups due Monday, June 8
The goal of this assignment is to extend your ray tracer in a way of your own choosing. The next section gives a list of approved extensions, but it leaves plenty of room for creativity. If you have a different extension in mind, we'd love to hear about it. We'll approve all reasonable requests.
You are permitted (and encouraged) to form teams of two or three people and partition your planned extensions among the team members. For a team of size N, you must implement at least N extensions. Extra credit will be given for extra work. The division of work among members of the team should be clear; each extension should be assigned to one student. Your README file must list these assignments. Teams may discuss this assignment with other teams, but each team is expected to implement the extensions independently. In particular, code must not be shared between teams.
(In the online version, the open bullets are links to example images.)
Even if you don't implement adaptive supersampling, I strongly recommend that you add some kind of supersampling to your ray tracer for this assignment. To properly appreciate (and evaluate) many of these extensions, you'll want some way to minimize the jaggies. At the least, compute a large image and average it down, thereby trivially simulating regular, non-adaptive supersampling.
To map a texture onto a surface, you must compute texture indices at each ray-surface intersection. Methods for spheres, quadrilaterals, and triangles are described by Eric Haines in sections 2.5 and 3.3 of chapter 2 in Glassner. A more efficient algorithm for triangles is given by Didier Badouel (Graphics Gems). For a triangle mesh, the methods listed above can be combined with a global mapping scheme based on vertex coordinates relative to a corner of the mesh, angles relative to a projection point not located on the mesh, or another scheme.
Use your texture to modulate something besides just reflectance (i.e. color). Experiment with transparency, specularity, or orientation (i.e. bump mapping). Alternatively, try modulating an interpolation between two other textures or between two entirely different shading models. See Cook's Siggraph '84 paper on shade trees and Perlin's Siggraph '85 paper on texture synthesis (FvDFH, p. 1047) for ideas.
For extra fun, implement texture filtering using direct convolution (section 17.4.2 of FvDFH) or prefiltering (using mip maps or summed area tables, section 17.4.3) to yield properly filtered textures without the need for supersampling. This will require comparing the u,v locations of adjacent rays to locally control the filter kernel size. If you implement this addon, you might need to adjust your sample region subdivision criteria in order not to supersample unnecessarily when rendering a textured surface.
In addition to implementing N extensions, you are required to model and render a scene that includes one real (i.e. physical) object that you can bring with you to the final demo. Mimic the object's appearance as closely as you can. You will be graded on the difficulty of your object and the accuracy of your depiction. Since this is a rendering course, we're looking mainly for rendering complexity, not geometric complexity. On the other hand, the object should be non-trivial, i.e. don't simulate a pane of glass, Some ideas for objects:
Unlike the first two programming assignments, this one will be graded using face-to-face demos. A few days before the demo date, a signup sheet will be posted in the Sweet Hall SGI lab. Each team should sign up for a 15-minute time slot on Thursday, June 4 to demo your program. All demos must be given in the Sweet Hall SGI lab.
Bring the object you have modeled with you to the demo. To expedite demos, be prepared to show precomputed images demonstrating the required extensions and a rendering of the object you have modeled. These images should clearly demonstrate your extensions and the object you have modeled. If we can't see it, you haven't done it. Depending on the nature of your extensions, we may also ask you to generate a (small) image during the demo. To facilitate this, your user interface should include a slider for setting image size prior to rendering.
Grading will be based not so much on the amount of work you have done, but on cleverness, creativity, and correctness.
No late demos!
When you have completed your demo (and gotten some sleep), make a copy of your code and the images you have generated in a directory called project3 in your home directory. Write a README file describing your extensions, and clearly stating which student was responsible for each extension. If you did something especially clever, tell us about it. Be brief but complete; 3-5 pages is about right. Finally, give us a list of image files. Again, these images should clearly demonstrate your extensions and the object you have modeled. Then submit your assignment as before. This submission is due by the end of June 8. Note: you are welcome to compute additional images between the demos on June 4 and the written submission on June 8. However, you will be graded only on the features and images you successfully demonstrated on June 4.
No late writeups!
At 4:00pm on Thursday, June 4, a judging will be held to select the best rendering. Participation in this competition is not required.
Entries may be made by individuals or teams, and may consist of any number of images or animations. You are allowed to use only i3dm, Composer, the ray tracer you wrote for this course, any software you wrote for the course (e.g. procedural modeler or shading languages), and tools available on the Sweet Hall workstations. You may not use GL. If you wish to use other tools, you must obtain approval and be prepared to make them available to all competitors. Your entries must be computed on workstations roughly equal in power to those in the Sweet Hall laboratory. You may use multiple workstations only if it does not interfere with other people's work. If you have any question about what constitutes acceptable computing resources, ask us. Finally, you may import (free) textures or models from the web, but be prepared to enumerate your sources honestly during the competition. We don't recommend heavy use of imported content.
The jury will consist of prominent computer graphics experts from academia and industry. Your prof will preside. During the judging, each individual or team will display their entry and briefly explain any exotic techniques used in its creation. This process is expected to take approximately 45 minutes. The winning submission will then be decided in private by the jury and announced to the gathered multitudes.
While grades for the programming project are based solely on "technical merit", the competition will be judged on both "technical merit" and "artistic impression". In particular, the jury will look for photorealism, creativity, and elegance.
There will be one grand prize - an all-expenses-paid trip to Siggraph '98 in Orlando, July 20-24, one second-place prize - dinner for two at Il Fornaio in Palo Alto and a copy of the Siggraph '97 Film and Video Show on VHS videotape, and three third-place prizes - a copy of the Siggraph '97 videotape. If the grand prize is won by a team, it must be split among the team members. All other prizes will be duplicated as necessary to cover the team.
Immediately following the render-off, there will be a party in the graphics lab and on the terrace outside Sweet Hall to celebrate the winner, your survival of this course, and the arrival of Summer. Refreshments will be provided.