CSCI 441 - Computer Graphics

This assignment is due by Monday, December 9, 2019 by 11:59pm.

At long last construction is done, the Interns have returned to school, and the day has arrived that the park will open. The gates are unlocked and the ticket takers are ready. You step outside and look for your family. They aren't there.

Frantically, you look around. They didn't wait two months for you in the parking lot? You've given up hope. The Man with the clipboard finds you and convinces you to come back into the park. Ra wants to see you one last time.

You follow the man back into the park and he motions for you to go in to the Temple.

You enter Sapa Inka's chambers and see your family joyfully waiting for you. You are overjoyed, your work has not been in vain. They will have the great trip you originally planned!

Sapa Inka passes you an envelope.

For your troubles.

Unsure what to expect, you open the envelope:

For this final assignment, your Team 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 an external 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, 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.

---

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 X - 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.

---

Section Z - Computer Science Fair
The Greatest Show On Earth!

---

For extra credit, and to earn the coveted P.T. Barnum achievement for additional XP, you have the opportunity to show off your amazing work to your fellow students at the Computer Science Fair on Wednesday December 4 6:30p-8p. If able to, it'd be great to show a working demo off of your laptop. If unable to, then creating a poster with screenshots and some text describing the techniques would be great. You will need to inform the instructor you plan to participate so space can be allocated. Specifics will follow.

You look back to Sapa Inka and Sapa Inka begins to take off the mask. As the mask is moved away, you get a clear look at who Sapa Inka has been this whole time.

To learn who Sapa Inka is, type your Hero's name into the box provided in UpperCamelCase and click "Unmask Sapa Ink!"

Students must submit a project proposal via Canvas by November 11th, 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.

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. This will be a separate individual submission.

During the final exam slot on December 10, each Team will present their Hanan Pacha. 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 Teams will be critiquing your presentation (by filling out a scoresheet) and at the end everyone will vote for their favorite Team that will continue development on Hanan Pacha Europe.

As with Roller Coaster Tycoon, each team can 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/podium to present from.

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)

Your submission will be graded according to the following rubric.

GROUP SUBMISSION - Please update your Makefile so it produces an executable with the name fp. When you are completed with the assignment, zip together your source code, Makefile, README.txt, and www/ folder. Name the zip file, TeamName_FP.zip. Upload this file to Canvas under FP.

INDIVIDUAL SUBMISSION - Please zip up your website and upload to Canvas under FP_Website.

This assignment is due by Monday, December 9, 2019 by 11:59pm.