Due: Friday, Dec 16, 2011
This assignment was modeled after the Final
Project of Stanford's Image Synthesis class.
- Late Submission:
- There is no option to be late for the final project.
- November 03 - you need to have a wiki up with your project proposal.
December 15 - your wiki page needs to be finalized
December 16 - presentations
For your final project we ask you to produce a realistic image of a
real object or scene. The scene or object should be challenging enough
to require you to design and implement an advanced rendering
algorithm. The final project is your chance to investigate an area
that interests you in more depth, and to showcase your creativity. To
see what your peers at Stanford did, check out
Here are some things
to think about following when choosing a project:
- What are your goals? Try and phrase this as specific questions
that you would like to know the answers to, e.g. How do I model
reflection from surfaces with fine geometric structure, such as
- What unique imagery would convincingly demonstrate that you have
accomplished your goals? Try and keep this in mind throughout
your project, since in computer graphics our work is often
judged by the images we make.
- What has already been done in this area? You probably won't have
time to completely investigate this, but you should definitely
spend some time reading research papers. We can help you with
finding appropriate references. When you read a paper, look for
what has not been done as well as what is already understood;
think about new things that you could try.
- Depending on the scope of your goals, you may want to work in a
group. We encourage two person groups; larger groups will only
be allowed to take on very, very challenging projects. Does your
project split naturally into several pieces? Look for projects
where each person's work is separable, and yet everyone
contributes toward a shared goal that could not be accomplished
Some Project Ideas
Here are some examples of challenging projects.
- Fancy primitives. Implement a class of more complicated
primitives from Hanrahan's chapter in Glassner's book. but
choose wisely. Quadrics are too simple; deformed surfaces are
much more challenging. Recommended are bicubic patches (display
directly or by meshing), CSG models, or fractals. Fractals are
relatively easy to implement and fun to use. For extra fun, map
textures onto your patches or fractals. For lots of fun, try fur
modeled as geometry (as opposed to as a volume).
- Exotic wavelength-dependent effects such as dispersion
and thin film effects. We can give you some references.
- Adaptive stochastic supersampling. Use any sample
distribution, subdivision criteria, and reconstruction method
you like. Allow interactive control over key parameters of your
sampling scheme. In a separate window alongside your rendered
image, display a visualization of how many rays were cast per
- Subsurface scattering. Look at Hanrahan and Krueger's Siggraph
'93 paper for examples of applying subsurface scattering to
plants and faces. For the more ambitious, model the
microgeometry of the surface. For example, consider an explicit
geometric model of the warp and the weft of cloth, the pits in
plaster, the scratches in metal, and the structure of velvet or
satin. Ray trace the microgeometry in order to compute the
brdf. Look at Westin et al. in SIGGRAPH '92; they describe
methods for modeling carpet and velvet.
- Shading language. Develop a language for programmable
shading formulas akin to (but simpler than) RenderMan's language
(Hanrahan and Lawson, Siggraph '90). At a minimum, your language
should allow the specification of a shade tree that includes mix
nodes driven by textures as in Cook's Siggraph '84 paper on
shade trees. Don't spend a lot of time on the interpreter - a
simple syntax will do. For extra fun, implement (in conjunction
with texture mapping) a nontrivial 2D or 3D texture synthesis
method. Examples are spot-noise or reaction-diffusion equations
(see the two papers on this subject in Siggraph '91).
- Advanced volume rendering. Start by implementing spatially
inhomogeneous atmospheric attenuation. Divide each ray into
intervals. For each interval, interpolate between the ray's
color and some constant fog color based on a procedurally
computed opacity for that location in space. Experiment with
opacity functions. Once you get this working, try defining a
solid texture (probably procedurally) that gives color and
opacity for each interval. See Perlin and Hoffert's Siggraph '89
paper on solid texture synthesis and Kajiya and Kay's teddy bear
paper for ideas. If you want to make your volume renderer fast,
use hierarchical spatial subdivision (e.g. an
octree). Volumetric photon mapping is currently not implemented
in pbrt. You could add it.
As a first step you should write a one page project proposal and
email me your webpage. The proposal should contain a picture of a real object
or scene that you intend to reproduce. We suggest that you first pick
something that you would like to simulate, and then investigate what
techniques need to be used. A real object that you can carry around
with you is best, but a good photograph or painting is almost as
good. In addition to having illustrative pictures, your proposal
should state the goal of your project, motivate why it is interesting,
identify the key technical challenges you will face, and outline
briefly your approach. If you are implementing an algorithm described
in a particular paper, provide the reference to the paper. Please list
all group member's names clearly at the top of the page, and if you
plan on collaborating with others, briefly describe how each person's
piece relates to the others.
Here is a good example of a project proposal.
The purpose of the proposal is to get everyone organized early, and
it will give us the opportunity to provide feedback as to whether we
think your idea is reasonable, and to offer some technical guidance,
e.g. papers you might be interested in reading.
On the day of the rendering competition (see dates at the top of
the page), each group will be given 15 minutes to demonstrate their
system to the class and rendering competition judges and show some
images that they produced. You can show off your images on any machine
you see fit. Remember to bring the object/images that you are modeling
and reproducing. The goals and technology that you developed should be
obvious from the image itself. After all, this is graphics. Keep in
mind that you absolutely need to have your rendering done by this
date. Late days are not allowed on the final
As there is a tendency for these presentations to go long, here's
some guidelines on how to prepare for the final presentation so
everyone remains entertained and the judges get an adequate impression
of your work.
1 minute -- Motivation: describe the image you were trying to
create, and why the image you are trying to create is both cool
and technically challenging.
9 minutes -- Technical: give a brief description of the
algorithms/techniques you implemented in your project. You can
assume that the judges probably have heard of the techniques
before, and thus want to brief, precise summary of how they were
incorporated into your project (how you used to technique to
meet your needs). It is often helpful if you can display images
contrived to demonstrate that your algorithms indeed work as
claimed (test shots, etc). This is also a good time to let the
audience know if a technique was tried, and didn't work (again,
test images work great here)
1 minute -- Show off your final image that you are entering into
the rendering competition. Each project may enter only a single
image into the rendering competition.
4 minutes -- Allow 4 minutes for questions
It is useful (but not required) to get a web page or Powerpoint
presentation prepared (look for
alternatives to powerpoint )
to keep your presentation organized.
Your final project writeup should be added to your project page by
December 15 (no late days allowed). The writeup should
be roughly 3-4 pages, and contain the following:
A 2-3 page summary of the algorithms/techniques used to produce
your images (use references to academic papers for extra
detail). Please highlight how your implementation differed (was
a subset of, augmented) the technique described in your
A description of problems encountered (techniques that did not
work?) and how they were overcome.
A clear description of what work each team member performed.
A results/conclusions section containing your final images,
additional images you didn't have a chance to show on demo day
that might be especially cool or good illustrations of your
All images should be attached to your final writeup wiki page
and not linked from external websites (we like to archive final
Please take the time to create a high quality writeup for your
project (think about it as writing a tech report you'd like to keep
permanently on the web). We will be archiving the final project pages
and they will be viewed for years to come.
Example final writeups from Stanford students:
- initial wiki page: part of Lab3 (Nov. 03)
- 10% - final wiki page (Dec. 16)
- 15% - presentation (Dec. 16)
- 75% - implementation and results
- did you get something working?
- did you indicate the problems involved?
- how did you deal with the problems?
- how well can you answer my questions?
I will consider strongly the novelty of
the idea (if it's never been done before, you get lots of credit),
your technical skill in implementing the idea, and the quality of the
pictures you produce. Tons of coding does not make a project
good. When you are finished with your project you should post the
source for your system and any test scenes and images that you have
created. As stated above, you are permitted to work in small groups,
but each person will be graded individually. A good group project is a
system consisting of a collection of well defined subsystems. Each
subsystem should be the responsibility of one person and be clearly
identified as their project. A good criteria for whether you should
work in a group is whether the system as a whole is greater than the
sum of its parts!
The final project can be a lot of fun. Good luck!
Last modified: October 21, 2011
Torsten Möller /
torsten AT sfu DOT ca