CSCI 441 - Computer Graphics

Fall 2016 - Final Project - Key to the Kingdom



|   Home |  Syllabus |  Assignments |  Leaderboard |  Schedule |  Resources   |
This assignment is due by Sunday, December 11, 2016 by 11:59pm.

At long last, you look around. Every enemy has been defeated and you are left standing. You did it, you are truly the Ruler of Olympus and have conquered the mountain. You make your way back into the city and head towards the Guild Hall.

As you wind through the streets, a crowd slowly gathers and follows you to the center. When you get to the Guild Hall, the robed woman is already waiting outside. Once you begin climbing the stairs, the woman removes her hood and greets you.

Before you can finish your thought, she gestures towards the spires and fireworks shoot out from each one. When the flames subside, you recount the spires and notice one is much greater in height than the others. The woman speaks.
"Yes, I have been following you for some time now. We had known at a very young age you would be the one to claim Olympus. The travelers you met along the way were not by chance, but messagers sent forth to aid you and help convince you of your powers. Now, fulfill the prophecy and accept this key to the Guild Hall."
To thunderous applause and cheers, you take the key and process into the Hall.


Part I - Accept Your Throne


Inside the Guild Hall, there is a great feast prepared. You are ushered to the head of the table underneath the central shield hung on the wall. You remember this shield as the shadow passing through a flame, but it has changed. The shadowy figure is no more and you see yourself. The flame has been extinguished and a great aura radiates around your silhouette.

All these people surely expect you to do or say something. They quiet down and slowly take their seats. Not knowing what to do, you take out your book and begin scribbling furiously. When you are finished, you walk to the raised platform and post the new Guild Hall rules.
For this final assignment, your Guild will implement...whatever you want! The final project for the course is an open-ended, student specified project that demonstrates skilled usage of the graphics techniques we've discussed over the course of the semester in lecture and homeworks. Most students choose to create a short interactive game, although some students write visualization tools or projects more directly related to other work (such as research). Although the constraints of the project are relatively open-ended, the project itself must contain an intelligent and meaningful application of a number of skills, described in more detail below, including animation, lighting, texturing, and shader programming.

It is recommended that you implement the configurable components of your application (objects in the scene, gameplay parameters, etc.) from file, so that you can greatly extend the usability of your program by simply providing multiple configuration files. (For a shooter, this might include a texture for a skybox, models for the enemies, health, etc.) It also allows you to more quickly experiment with different material and lighting properties - don't worry about constantly recompiling; just change a text file and re-run.

This is the final project! Feel free to use all the tools you've developed so far in the semester, including (but not limited to): minimaps, HUDs, menus, picking, billboarding, particle systems, stenciling, cloth, collision detection, and Bézier curves - which, as you know, can work very well for smooth, guided animation (objects moving along a Bézier curve make for hard targets to hit!), Bézier Patches, and everything else!

Unfortunately, in contrast to the previous two points, there's limited time for the final project; make a plan, divide work up among your team members early and meet often, and most importantly, start simple! Get the basics working and expand from there. This is particularly true with gameplay - even simple mechanisms can be particularly bug-prone and occupy a lot of your time. Sadly this is not a game design course (though there is one next semester!): your priority is incorporating the different graphical skills you've learned over the course of the semester, and making something fun and sophisticated is a secondary objective.

All projects must contain a number of required components, to demonstrate that students have learned and can apply in a practical context the main techniques that we have discussed in the course. If you have questions about whether any aspect of your project satisfies the conditions listed here, please contact the professor. The required components cover five major aspects that are prevalent in realtime graphics applications: (1) user interaction, (2) animation, (3) texturing, (4) lighting, (5) shader programming; plus sound additionally.


Section A - User Interaction

The final project must contain some non-trivial component of user interactivity. This should be a non-issue for most projects. The user must be able to influence the state of the application via keyboard and/or mouse interaction, and must be able to influence the camera position (directly or indirectly, should the camera be attached to a virtual object). Interactivity must be more sophisticated than a single button press - as a realtime application, the resulting feedback from user interaction with your program is the primary means of communication between your virtual world and the user. Your program's ability to respond to interaction must be sophisticated enough to showcase and communicate everything that your application has to offer.

Additionally, your program must allow the user to view the scene from at least two different cameras. These could be both displayed simultaneously (via viewports and stenciling), or the user can have the option of switching between them.


Section B - Animation

Your project must include some component of structured animation. This means that you must use some form of hierarchical modeling (if you are using the provided Object models, then this will suffice for modeling). If you have the resources to implement pose-based animation (or skeletal animation), this will satisfy the animation requirement - but it must be more sophisticated than the back-and-forth-oscillating Waddles animation used in class (i.e., must move between poses based on events in the virtual world, with speeds varying accordingly -- the Camel fully galloping would be great!).


Section C - Texturing

The final project must use at least two different texture applications in some meaningful way. This means that filtering must be enabled if it makes sense, including the use of mipmaps if the object is expected to be far from the camera. Textures can be transparent; texture coordinates can be manually specified or part of an OBJ; particle systems can (and should!) be used to satisfy one of the texture requirements. A skybox (or any environment color besides black, for that matter) can give your scene a totally different feel as well. A skybox would count as a single texture application (even though it is made up of 6 individual textures).

NOTE: in addition to textures, you should also make strong use of OpenGL materials -- you can combine a material with a high specularity and a marble texture to get a more authentic feel, for instance. In situations where a texture doesn't fit, use non-textured materials - sometimes they may look best! There are several texture repositories to browse linked on the Resource page.


Section D - Lighting

Your application must include a meaningful application of lighting. It must include at least two lights, and one of them must be animated or dynamic in some way. (Light position can be tied to objects in the scene; brightness can be tied to user events such as objects colliding; color could be tied to the player's performance or health - maybe a flashing red light slowly becomes brighter as the user's health diminishes.) Remember that lights exist not only to communicate shape and depth but also contribute substantially to the feel of the scene! Experiment with light positions, colors, and intensities to get a particular look and feel. Generally, you can get good results with slightly off-white lights of complementary colors - check out COLOURlovers for some nifty color palettes, as well as tools to help you choose sets of complementary colors.


Section E - Shader Programming

Your final project must contain custom shader programs to enhance the visual quality of your presentation and increase your ability to communicate information to the user. Your program must contain at least two shader programs (that is, two pairs of vertex shader + fragment shader), and these shader programs must be meaningfully different from the code examples posted on the webpage. In other words, no copy+paste of the available shader code, and your shader code must produce meaningfully different results. Your shaders can provide a large variety of interesting behaviours; by having player-characters flash a certain color when low on health, or altering the color of the rendered frame after consuming a powerup, by slightly randomizing vertex positions to create a glitchy object appearance, or through more traditional shading models, such as reading specularity color from a texture (specular mapping). One of your shader programs must contain a non-trivially different vertex shader and one of your shader programs must contain a non-trivially different fragment shader. We have covered many different applications of vertex and fragment shaders - pick and choose your favorites. You're encouraged to use some multipass rendering techniques but the shader programs chosen is up to you.


Section Y - Sound

Your final project may contain sounds using OpenAL/FMOD. These sounds can be triggered to some event or ambient. There's a lot of fun stuff that can be done with audio!


Section Z - Easter Eggs

For added fun, add in some sort of hidden easter egg that can be found in your program. Perhaps it's some secret combination of movements, or being in a certain location and performing some action, or whatever you want. Don't make it easy to find (e.g. a bright red X on the ground you need to move on top of) but perhaps make it easier than some of the previous achievements have been to find. For good measure, add to your README.txt how to find your easter egg if you add one so I can verify it exists. I'll try to find it without reading the walkthrough.
With peace in the land, Guilds are no longer needed to train and protect the portal within the city. You've set the Guilds free.

I looked at my kingdom
I was finally there
To sit on my throne as the Prince(ss) of Bel Air Olympus.


Part II - Guilds & Proposal


Students must submit a project proposal via hardcopy in class November 18th, containing a list of team members and a brief description of the intended project. The description only needs to be a couple of paragraphs long, and should describe the project at a high level and anticipated technical challenges, if any. Describe what shaders you plan to implement, how you'll use lighting, etc. It should be clear where each requirement will be in your program. It is primarily intended for the professor to provide feedback and recommendation, and establish requirements for the final submission.


Part III - Website


Update the webpage that you submitted with A7 to include an entry for this assignment. As usual, include a screenshot (or two) and a brief description of the program, intended to showcase what your program does to people who are not familiar with the assignment.


Part IV - Presentation


During the final exam slot on December 12, each Guild will present their Kingdom. They will have five minutes to showcase their work and demonstrate all the features available. There will then be two minutes for other students to ask questions about your implementation. During this time, the other Guilds will be critiquing your presentation (by filling out a scoresheet) and at the end everyone will vote for their favorite Guild that should be rulers of Olympus.

As with Guild Wars, each team will use their own laptop to present from. Be sure to have the necessary connectors to hook up to the projector in the room. If needed, please let the instructor know if you'll need to use his laptop to present from.


Documentation & Submission


With this and all future assignments, you are expected to appropriately document your code. This includes writing comments in your source code - remember that your comments should explain what a piece of code is supposed to do and why; don't just re-write what the code says in plain English. Comments serve the dual purpose of explaining your code to someone unfamiliar with it and assisting in debugging. If you know what a piece of code is supposed to be doing, you can figure out where it's going awry more easily.

Proper documentation also means including a README.txt file with your submission. In your submission folder, always include a file called README.txt that lists:
  • Your Name / email
  • Guild Name / Guild Members
  • Assignment Number / Project Title
  • A brief, high level description of what the program is / does
  • A usage section, explaining how to run the program, which keys perform which actions, etc.
  • Instructions on compiling your code
  • Notes about bugs, implementation details, etc. if necessary
  • NEW: A description of the file format that your program reads as input
  • NEW: A rough distribution of responsibilities / contributions of each student
  • How long did this assignment take you?
  • How much did the lab help you for this assignment? 1-10 (1 - did not help at all, 10 - this was exactly the same as the lab)
  • How fun was this assignment? 1-10 (1 - discontinue this assignment, 10 - I wish I had more time to make it even better)


Grading Rubric


Your submission will be graded according to the following rubric.

Percentage Requirement Description
10% User interactivity is well-implemented and meaningful; allows the user to explore the various aspects of the program.
15% Project contains models which are animated with some form of hierarchical animation.
10% Project contains at least two different texture applications, used as described above.
10% Project contains at least two different lights and materials, used as described above.
50% Project contains at least two different shaders, used as described above.
2.5% Proposal submitted on time.
2.5% Submission includes source code, Makefile, and README.txt.
Source code is well documented. Webpage named <afsid>.html submitted and updated with screenshot from latest assignment. Submission compiles and executes in the lab machine environment.


Experience Gained & Available Achievements


Assignment Attribute
Assignments +150 XP
Web Attribute
Web +150 XP
School's Out
School's Out


Submission


Please update your Makefile so it produces an executable with the name keyToTheKingdom. When you are completed with the Final Project, zip together your source code, textures, models, shaders, anything needed to run your program, Makefile, README.txt , and www/ folder. Name the zip file, GuildName_FP.zip . Upload this file to Blackboard under KeyToTheKingdodm.

Everyone is expected to submit a README.txt file, although the files may be the same. Each team member must also update their Hero's webpage. In your README.txt , be sure to specify who submitted the full source code (you all may do so, but make sure at least one of you does).


This assignment is due by Sunday, December 11, 2016 by 11:59pm.
Last Updated: 01/01/70 00:00


Valid HTML 4.01 Strict Valid CSS! Level Triple-A conformance, W3C WAI Web Content Accessibility Guidelines 2.0