CS 651-4/551-3: Real-Time Rendering
Assignment #1

Synopsis: Build the basic underpinnings of a 3D scene-graph engine.  Your program should be able to import 3D models with hierarchical transformations, place them into a scene graph, and render the scene (preferably in an efficient fashion).

Due: This assignment has multiple components, each quite challenging in its own right.  To help you organize your effort, I will check your progress midway through:

    Sept 17, 2002    Checkpoint: Load and display a single model (40%)
    Sept 24, 2002    Final assignment: Everything else (60%)

Details: This is where you start: in this assignment you will build a basic scene-graph renderer that will become the base of your game engine.  Your renderer should support:

• Importing 3D models - your program will support loading multiple 3D models in one or more file formats.  Suggested file formats include .obj (alias/wavefront objects), .md2 (QuakeII), .md3 (QuakeIII), .3ds (3D Studio Max), .ma (Maya ascii).  These formats are listed roughly in order of complexity.  The .obj file format is quite simple, but it may be difficult to find interesting models.  The .3ds format is fairly complex, but many, many models are publicly available. 
• Hierarchical transformations - your program should support hierarchical transformations in the organization of objects within the scene; for example, if a status sits on a table and the table is moved, the statue should move with it.  Your program may optionally support hierarchical transforms within a single model, i.e. for articulated characters.  Note that only some of the file formats above support hierarchical models.  If you choose not to implement such a file format, you will probably need to write your own scene description file that describes the objects in the scene and their organization.
• Instancing - your program should support instancing, in which a single model can be represented (instantiated) multiple times with different transforms.
• Moving objects - your program should allow the user to pick an object and translate or rotate it within the scene (of course, hierarchical transformations should be respected, so that any children of the selected object are also affected by the user's actions on the parent object).  You will not be graded on the interface; for instance, using keystrokes to select and move objects is fine.
• Simple texturing and lighting - You should be able to load and display models with simple texturing and/or lighting.  The user or scene file should be able to specify the rendering state (texture on/off, lighting on/off, wireframe on/off) for each object or instance.  Again, the interface is less important than the functionality here.  Directional lighting and simple texture modes are fine.

Doing all of the above correctly will earn you an A- on the assignment.  To improve your grade further, you should include some extra functionality.  Examples include:

• Animation - Several of the file formats above support animation of the model over time, or several different animations (for example, the Quake models include animations for walking, jumping, dying, etc).
• Advanced texturing - Some model formats include multitexturing, detail textures, light maps (all basically the same idea); you could also include support for normal maps, environment maps, etc. 
• Advanced lighting - For example, you could include more light sources in the scene graph
• Efficient rendering - We will discuss several techniques in class to achieve efficient rendering of geometry: vertex arrays, sorting by graphics state, triangle strips, etc. 
• Skinning - Some file formats support skeletal animation with skinning, in which vertices are transformed by multiple "bone" matrices and the result interpolated according to a weight associated with each vertex.

Resources: There are many places you can go to look for advice, tutorials, details, and source code for loading file formats.  This can be frustrating, however, as many of the resources on the Web are the results of enthusiastic amateurs rather than paid professionals.  Some good places to start are:

• http://www.gametutorials.com: a soup-to-nuts series of source code "tutorials" on game programming, written for beginning programmers but containing a great deal of 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 models.
• http://lib3ds.sourceforge.net: a library for reading .3ds files, seems fairly complete.
• www.planetquake.com/polycount: lots and lots of models for various games.  For example, this is where I found the "legoman" QuakeIII models. 
• 3D Studio Max files: I have purchased a collection of over 5000 models in 3D Studio .max  format (not the same as .3ds) and will shortly be sending out a link to the repository.  I also hope to get copies of 3DSMax for the Olsson 002a lab, with which we could export these models (for example, to .3ds format...) and create new ones. 
• www.gamasutra.com: Lots of useful information on game programming here, along with the usual chaff.
• http://www.iseran.com/Win32/CodeForSpeed: a lot of important and useful info on how to write efficient code.  I will post a handout summarizing some of the lessons from this site, but it is worth your reading in full.  Note that this site is not graphics-oriented.

Lab: We are sharing Olsson 002a this semester.  Most of you will need to get a key from Ginny Hilton at the CS front desk.  There are 13 machines and 20 students in this class, plus 30-some students in CS 650 using the lab...so be courteous and don't assume you will always get a computer exactly when you were planning to work.  The machines in 002 have modern processors and high-end GeForce3 graphics cards.  If you would rather work on a personal machine, that's fine too -- in fact it will take the pressure off the lab machines.  Let me know any issues you encounter -- this is a new lab and there will undoubtedly be software, hardware, and availability issues to work out.

Policy on code reuse: In general you are welcome to use code that you find elsewhere.  For example, you are welcome to use the functions given in the QuakeII loader handout, or 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.  Obviously if you reuse a significant amount of code that raises the bar for the assignment, and you will be expected to do something beyond the basics mentioned above even to get the base grade of A-.  If you have any questions about code reuse or attribution, please ask me.

Platform: I would prefer that your code compile and run under Microsoft Visual Studio 6 or 7 (.NET).  If you really want to use Linux, talk to me about it first.  You are welcome to use GL extensions supported by NVIDIA GeForce3 and GeForce4 cards; if you want to use other extensions or other hardware, talk to me first (we also have an ATI Radeon 9700 in the lab, so that is a possibility...but you'd have to own your own card for development).  If you want to use a particular input device, talk to me first...you may have to lend it to me so I can grade your assignment.

Turning in the assignment: Put all your code and models in a folder, along with a detailed README.txt file that describes what you did, what code you wrote and what code you used from elsewhere, and how to run your assignment.  Zip up the file and e-mail it to me, or put it somewhere I can download it.  Be sure to include workspace and project files so that I can compile your code.  I will read (and grade you on) your source code, so follow good programming practices.

Advice: If this sounds like a lot for a two-week assignment, that's because it is a lot.  This will probably be the hardest assignment in terms of the sheer amount of code you need to write.  It is particularly important to start early because you will be building on this code for the remainder of the course; a careful and thoughtful design now will simplify everything down the road, whereas a rush job will introduce bugs and design flaws that will continue to bite you throughout the semester.  Now is the time to follow good careful software engineering practices: think carefully about your design BEFORE you start, test your classes and functions early and often, and back up your work for disaster recovery and revision control.