CS 446: Real-Time Rendering
Synopsis: Just like project 2. Pick a component to add to your game engine from one of the
Due: This assignment is due Mar 18 (Thursday after Spring Break).
By Tue Mar 2 (sooner if possible) you should mail me and Ben a
description of what project you plan to do and how it will fit into your game.
This is important!
Details: The rest of the assignments in the class will follow the same
pattern. Each student must pick one project from the following categories,
with the constraint that no student can pick more than one project from any
category (but note that some projects fit multiple categories), and with the
additional constraints noted below.
- Lighting effects: add some interesting lighting effects to your
- Light maps: precomputed (or even hand painted) textures that capture
low-frequency lighting information, combined with surface texture using
- Shadows: shadow maps, shadow volumes, others. Note: every group must
implement a shadow algorithm at some point during the semester.
- Flare and glare effects: lens flare, optic glare, and chromatic aberration
effects lend a sense of "photorealism" by simulating camera effects familiar
- Volumetric light effects: add "shafts of light" using techniques similar
to shadow volumes.
- Texture effects: add texture-related effects to your system:
- Light maps: see above
- Decals: these are things like bullet holes, char marks, and spattered
blood (to pixk typical if violent examples) that get dynamically added to the
scene by player actions.
- Normal maps: write shaders to add visual detail to your polygons by
perturbing the normal used in lighting according to a texture.
- Imposters: add image-based imposters (dynamic or preprocessed)
- Environment maps: use environment maps to get convincing glossy or
- Projective texturing: this technique projects a texture onto a surface
like a slide projector. Lots of special effects possible this way.
- Shaders: use Cg to implement interesting surface shaders in your
- Normal maps: see above
- NPR/toon shading: per our discussions in class.
- Skinning: implement skinning on articulated characters.
- Particle systems: write a vertex program to create time-varying
particles: since vertex programs can calculate the vertex position as a
function of time, they can be used to implement simple physical or
non-physical particle systems. For example, a vertex shader can compute the
effects of gravity and wind on falling sparks. Games use this technique
frequently to implement explosions, fire, water, grass blowing in the wind,
hair, "swarming points of light" magic effects, and yes, splashing blood.
You will probably want to combine such particle systems with the
NV_POINT_SPRITE extension, which allows you to draw each vertex as a
screen-aligned quadrilateral with a (possibly animated) texture applied.
- Deferred shading: if you want to use a VERY VERY complicated shader
on lots of geometry in the model, it can be expensive to run that shader on
pixels that eventually get depth-buffered away. Deferred shading
instead writes the shader parameters (e.g., normal, texture coordinates) to
the framebuffer, then makes a pass over the entire screen (by drawing a
screen-sized quad with the framebuffer applied as a texture, and running the
very complicated shader on just those pixels that survived the depth test.
- Performance: Speed up your engine using acceleration techniques or
just careful tuning.
- Visibility: add portal culling, PVS managment, or
some other form of occlusion culling.
- LOD: add LOD preprocessing or run-time LOD management for objects,
terrain, or shaders.
- Imposters: add image-based imposters (dynamic or preprocessed).
- Performance: profile, optimize, and tune your game engine to make
it go as fast as possible.
- Other stuff: a catch-all final assignment for some of the many other
things that go into a good game.
- Tools: build some tools for artists or level builders in 3DS Max or
- Physics: add some physical simulation to your game.
- AI: add some AI to your game.
- Special effects: fur, npr edge-based effects, water effects, clouds
and fog, transparency, etc.
- Camera control: intelligent "cinematic" camera control, instant
There are a few additional constraints. Across the remaining four
- Every group must implement a shadow algorithm
- Every group must implement at least two acceleration or tuning projects
from the "Performance" category.
- Every group must employ multitexturing at some point
- Two group members may not do the same project (though some projects
allow for sufficient variation that they would not really be the same
project. Just use common sense)
Furthermore, I explicitly do not want four individual assignments that
don't work together. Your project must be fully integrated with the
group's game engine. If your project doesn't work with the rest of the
group's work, it will be considered late until it does. The group only turns in
Resources: Similar list as before, with a couple new bullets.
Feel free to amplify this list by sharing your own comments and pointers on the
- http://www.gametutorials.com: a
soup-to-nuts series of source code "tutorials" on game programming, written
for beginning programmers but containing some useful information.
The tutorials are in the form of heavily-commented source code. In
particular there are fairly good tutorials on loading Quake .md2 and .md3
a library for reading .3ds files, seems fairly complete.
www.planetquake.com/polycount: lots of models for various games.
- 3D Studio Max files: I have purchased a collection of over 5000 models in
3D Studio .max format (not the same as .3ds), available at
\\eirene.cs.virginia.edu\3dEnc2000 in Windows. You can export these
models (for example, to .3ds format...) and create new ones using 3D Studio
Max, which is available in 002a. Note that we also have Maya, another
modeling package; right now it does not appear to work in 002a. If you
want to use Maya we should be able to accommodate you.
- www.gamasutra.com: Lots of useful
information on game programming here, along with the usual chaff.
- www.cgshaders.org: Plenty of
sample shaders, some of them simply gorgeous, and forums where people will
help you with dumb or not-so-dumb questions about Cg and programmable
Tons of presentations, white papers, tools, and demos (with code!)
explaining how to achieve various effects, or how to tie them together in a
game engine. Poorly organized but lots of great information.
- Papers! Many algorithms are best described in the papers where
they were first presented. Browse the programs and proceedings of
conferences like SIGGRAPH, the Symposium on Interactive 3D Graphics,
Eurographics and it's subsidiary workshops/symposia, Graphics Interface, and
Pacific Graphics. Look on researcher's web pages for copies of the
papers; sometimes you'll also find slides, movies, or even code
demonstrating their techniques.
- I recently got a beta version of the book "Essential mathematics for
games". It's a very thorough yet readable introduction to the math
underlying computer graphics techniques, ranging from affine transformations
to quaternions and splines to the lighting equation to rigid-body dynamics.
Come check it out if you like.
Also, don't forget about the optional texts for the course like the Cg
Tutorial and the Game
Programming Gems series!
Policy on code reuse: Same policy: In general you are welcome to use code that you
find elsewhere. For example, you are welcome to use the lib3ds library mentioned above,
and you are strongly encouraged to use the in-house software tools that Ben has
However, you will not get credit for what you didn't write. Therefore, it
is critically important that you describe in detail what code you wrote
yourself and what code you imported or adapted from elsewhere.
Furthermore, if you find a particularly helpful library, tutorial, loader, etc.,
you should post it on the forum. Obviously
if you reuse a significant amount of code, that raises the bar for the
assignment: you will be expected to do something beyond the basics mentioned
above. If you have any questions about
code reuse or attribution, please ask me.
Turning in the assignment: Again, the group should turn in a single
working program that demonstrates the various features added by individuals. Put all your code and models in a folder,
along with a detailed README.txt file that describes what your group did, who in
the group did what, and any code or features added that aren't specifically part
of an individual assignment (I expect that during every project, there will be
some effort on the general game engine that is not reflected in an individual
assignment. You will get credit for these efforts as a group, and yes,
general work on the game outside of the individual assignments will benefit the
group's grade as a whole. Each student in the group should include a
separate document, e.g. README.luebke.txt, that describes in detail what you
did, how you did it, what code you used from elsewhere, and how to demo your
contribution in the game engine. Zip up the folder and e-mail the .zip file (or a link) to me and the TA.
Be sure to include workspace and project files, along with any libraries/include
files/etc, so that we can compile your code.
We will read (and grade you on) your source code, so follow good programming
Grading: You will be graded on the difficulty as well as the success
rate of your projects. Not every project has to be a killer, but I expect
every student to take on at least one substantially difficult project, and no
more than one comparatively easy project. Part of the reason you need to
mail me a description of what you plan to do is to so that I can give feedback,
if necessary, on how difficult I judge a project to be.