CS 460:
Interactive Graphics and Games
Project #2
Synopsis: Pick a component to add to your game engine from
one of the categories below.
Due: This assignment is due April 4.
By Friday Mar
25 (sooner if possible) you should mail me 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 system:
- Light maps: precomputed (or even hand painted)
textures that capture low-frequency lighting information, combined with
surface texture using multitexturing.
- 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 from cinema.
- 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 reflective objects
- Projective texturing: this technique projects a
texture onto a surface like a slide projector. Lots of special
effects possible this way.
- Shaders: use Cg or OpenGL Shader Language to implement
interesting surface shaders in your engine
- Normal maps: see above
- NPR/toon shading:
- 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 Maya
- 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 replay, etc.
There are a few additional constraints. Across the remaining
four assignments:
- 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 one
codebase!
Resources: Same resources as before. Here are a few new
ones. Feel free to amplify this list by sharing your own comments
and pointers on the class forum.
- 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 graphics.
- http://developer.nvidia.com:
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. We also have
access to the ACM and IEEE digital libraries to get papers online (from
inside JHU domain).
Also, don't forget about the optional texts for the course --
they are all on reserve if you have not purchased them.
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. 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.cohen.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. Be sure to include workspace and
project files, along with any libraries/include files/etc, so that I
can compile your code. I will read (and grade you on) your source
code, so follow good programming practices.
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.