CS 446: Real-Time Rendering
Final Project

Synopsis: Again, you will pick a component to add to your game engine from one of the categories below.  Since the result of this project is the group's final game, the entire group will get the same grade as in project 1.  This is to encourage you to work together on bringing your individual contributions and the entire game into a coherent, playable whole.  The group will present their game to the class and other invited spectators during our final exam slot.

Due: This assignment is due 9 AM May 5  (our final exam slot), when you will demonstrate your game to the class.  By Tue  Apr 27 (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 final assignment will follow the same pattern as the last two, with a couple of caveats.  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.

1. 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.
2. 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 pick 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.
3. Shaders: use Cg to implement interesting surface shaders in your engine
   • 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. 
4. 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.
5. 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:

1. Every group must implement a shadow algorithm
2. Every group must implement at least two acceleration or tuning projects from the "Performance" category.
3. Every group must employ multitexturing at some point
4. 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)

As before, 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.  This is especially important for this assignment!  It is thus vital that you work together with your teammates to pull your contributions and your game together.  The group will turn in only a single final project, and will all get the same grade with no exceptions and no negotiating.  If you aren't able to complete your contribution, or to work with your teammates to integrate your contribution, the entire group's grade will suffer.

Resources: See the previous projects.  Also, I have a spare copy of the new book GPU Gems which I am going to place in the lab.  You may find this a very useful book for ideas and example code!  Check it out.

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 posted.  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: The group should bring to our final exam two copies of a CD containing the game code, along with a compiled executable and all the data files, .DLL files, etc. necessary to run the game.  The idea is that I put your CD into my computer and it just works.  If you absolutely must have some library etc. installed on my computer, let me know ahead of time.  Each group will give a 20 minute presentation of their game, describing the various features members have added and demonstrating them in the game.  As before, include 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 this project in particular, 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. 

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.  To encourage you to work together as a group, the entire group will get the same grade for the final project.