Overview

In this final phase of the course, you have great freedom to craft a project that excites you and that you can be proud of, perhaps even as a reference in industry interviews. Over the past twelve weeks, you have acquired hands-on experience with image processing, mesh processing, raytracing, rasterization, and cloth simulation. Additionally, you have learned through course lectures and readings about many fundamental tools and techniques used in the computer graphics field to engineer solutions for a breadth of complex visual applications. Now, as a capstone to this course, you will synthesize your graphics knowledge and extend your hands-on experience by working in small groups to build a large graphics-based project for the web.

For the final project, you will work in teams of two to four to build an extensive system that incorporates one or more ideas from this course. As long as the foundation of your project is graphics-based, its precise focus can really be anything of your choosing. Over the past few years, almost all students used ThreeJS to create mini games, interactive art demos, or occasionally technical extensions; however, this should not discourage you from trying something different! Note that the most successful projects are often slightly-innovative and highly-polished games or art demos.

At the end of this project, you will have the culmination of your hard work available online as a live demo for anyone to try out! Because graphics projects are generally entertaining and visually impressive, students often choose to share their finished projects with friends, family, and even recruiters. Regardless of what you do with your project after this semester, we hope that you find this final project to be a rewarding experience!

Requirements

As outlined above, this project is fairly open-ended, but there are a few hard requirements:

• You must work in groups of two to four. Naturally, we will hold larger groups to a higher standard when evaluating their final project, although we will take diminishing marginal returns somewhat into account. If you have an extremely compelling reason to either work alone or work in a group of five, please make a private post on Piazza and we will consider your case. In our experience, solo projects struggle to get off the ground, whereas projects from groups of five or more suffer from having too many cooks in the kitchen.
• The source code for your project, as well as your project’s written report, must be published to a public GitHub repository — no exceptions. We also expect you to use the repository for version-control and project collaboration, but we will not enforce this. If you are not familiar with git protocol, now is an excellent time to learn!
• You must host a live demo of your project online, preferably through GitHub pages (which is lightning fast to set up if your source code is already in a repository). As we expect most projects to be built on ThreeJS, this should be fairly straightforward for most of you. If, however, you are really drawn to a project that cannot be integrated into a browser runtime, please make a private Piazza, and we will consider your case.
• You must submit the link to your live demo, repository, and finalized writeup on Dean’s Date. You are permitted to continue editing your demo and source code after Dean’s Date in preparation for your final presentation, but your written report should be locked-in.
• You must give an elevator pitch during the in-class proposal lecture, and you must present during the final project presentation session. If extenuating circumstances renders your presence impossible for either of these presentations, please make a private post on Piazza explaining your situation, and we will do our best to find a solution.

Note that while almost all of the points you accrue through this final project will count towards your Final Project grade in this class, there will be a couple opportunities to improve your Participation grade for this course as well through peer-to-peer feedback (more on this later)! Finally, we will be holding an art contest for the final project, and as usual, the contest winners will be awarded a small amount of extra credit. The top projects from this semester will also be honored with an induction into the Final Project Hall of Fame.

Policy on Sources

Whereas you were asked to build programs from scratch for assignments in this course, we encourage you to leverage existing resources available through online communities in your final project. While we will provide some simple ThreeJS starter code for this project (since many students will be using ThreeJS), you might find that your project needs a little more help getting off the ground. At the very least, you are welcome to source infrastructure, tools, and even bits of code from the extensive list of ThreeJS examples. Sometimes, students even choose to start with a ThreeJS example and build from, with great success.

In addition to borrowing from ThreeJS tutorials and examples (both official and informal), you are welcome to borrow basic resources like object files, animations, textures, and more from open-source asset libraries (emphasis on “open source” due to copyright protections — this should go without saying, but do not commit copyright infringement while working on your final project). Finally, the lenient policy on sources for this project means that you are not required to write all the difficult code yourself. In particular, we highly recommend that you use leverage existing JavaScript libraries to abstract away parts of your project that are tangent to your focus. For instance, if you are creating a music-based art demo, you should use a library that provided a MIDI controller abstraction. Likewise, if you are building some mini-game that requires some complex collision handling (beyond, say, a handful of sphere-to-sphere collisions), you should look into integrating a physics engine into your project. However, if you were instead cooking up a final project where the physics is your point of focus, it would be highly inappropriate to use a physics library to directly solve your physics problem, since then you would not be making any meaningful contributions.

At the end of the day, please do not take advantage of our leniency. Unfortunately, we have had cases in the recent past where students made very small contributions to existing (yet niche) projects, and then they tried to pass it all off as their own. We have also had cases where students relied too heavily on existing code, and did not make a sufficiently meaningful contribution themselves. While it is permissible to use existing libraries and infrastructure you find elsewhere, it should not dwarf your own code in terms of its role in the project. For example, if you are making a game, do not build on a highly polished and complete game engine like Unity. If you are building a ThreeJS project off of an existing project or example, you should still be writing a substantial amount of code yourself, and the end result should bear little resemblance to where you started from.

As always, you should be very clear about which parts of your submission is your own contribution, and what parts were borrowed from elsewhere. Please cite any borrowed code, infrastructure, or frameworks in both your source code and your writeup. Your writeup should also include citations for any libraries that are leveraged by your project.

Deliverables

Dean’s Date

The main submission deadline for this project is Dean’s Date. By midnight of that day, you must submit links to your live demo, repository, and finalized written report. After Dean’s Date, you should not modify your report, although you are allowed to make slight modifications to your source code and live demo in preparation for the final presentation. This said, these should really only be finishing-touches and bug-fixes. While we will look through your code, we are only directly grading your written report and final presentation; thus, if you want to receive credit for a feature, it must be included in your report (and therefore finished before Dean’s Date).

Miscellaneous Forms

Over the next few weeks, there will be occasional forms posted to Piazza. A couple of these forms will help us manage logistics, such as identifying groups and scheduling presentations. Other forms will be used to collect peer to peer feedback, which factors into your Participation grade. In any case, please check Piazza regularly, and keep an eye out for these forms.

Scoring

Your grade will primarily be determined from the quality of your written report and your final presentation, adjusted for your group size. While we will not share our rubric, we will be measuring the quality of your work, the ambition of your goals, the difficulty of your project, the clarity of your presentation, the effort manifested in your progress, and the overall polish of your final product, among others. Beyond these metrics, you should expect for the project proposal presentation to account for 5% of your entire project grade.

Note that whereas assignment averages are generally high, projects scores are often more reflective of the exam distribution. While we would love to give everyone full marks, we generally see a wide spread of effort put into these final projects, and we must grade accordingly. This said, if you put the time in, work effectively, and create a meaningful project over these two to three weeks, you will almost certainly score well. If you find that you are struggling early on, please seek help from TAs as soon as possible! The course staff will be available for project consultation and advice throughout the duration of the final project. We strongly encourage that all students leverage this valuable resource.

Project Phases

This timeline of this final project breaks down into five phases:

• Phase 1: Ideation
• Phase 2: Proposals
• Phase 3: Implementation
• Phase 4: Presentations
• Phase 5: Evaluation

Note that these phases do not all require the same time investment, nor do they share the same influence on your final grade. Additionally, some of these phases might bleed together. For instance, most groups should plan to have started the implementation phase before the in-class project proposal session. Likewise, it is recommended that groups begin the writeup while wrapping up the implementation of their final project, as opposed to strictly beforehand.

I. Ideation

Brainstorming

The final project begins with a critical brainstorming stage. Spend time coming up with a few ideas, and for each of them, think about how to expand or extend the idea. Additionally, think about how you would structure the actual implementations for each idea, and then evaluate some major roadblocks you might run into. Once you have completed this process for your potential project topics, start to cut the weakest ideas from consideration until you have whittled down the list of directions for your project to just a couple choices. Put some extra thought into these remaining ideas, and then, after sleeping on the decision, it’s time to settle on your project topic.

Please note that we considering project novelty/creativity when evaluating your project, but this does not mean you need to come up with a completely original idea. Even slight innovations can be significantly creative given the limited scope and timeline of the final project. In particular, you do should not feel obligated to reinvent the wheel — for instance, if you are building a mini game, it would be perfectly acceptable to adapt gameplay from existing physical games, such as Jenga, Ping Pong, Foosball, et cetera. Perhaps you could even develop a creative spin on such ideas!

If you ever find yourself completely stumped, or if you have a rough idea but aren’t sure how to develop it into a project, please reach out to instructors via Piazza! The course staff is more than happy to help you brainstorm, as well as provide early feedback for any proposal ideas you already have.

Scoping

Realistically, there is only so much you can tackle in two to three weeks. As such, we recommend that you tame your ambitions from the start by setting an attainable baseline goal. From there, set a series of stretch goals that expand this baseline into a more ambitious project. Note that your series of stretch goals will also be useful for pacing and organizing your project’s implementation.

During this ideation phase, please do not forget that less is often more. Simple geometries, simple materials, and simple textures are simple to work with, but can still look great. Instead of aiming for realism, instead consider flat shading or cell shading. Adding a post-processing Bloom effect can also make wireframe-based projects look amazing. This said, if you do want to proceed down the realism route, you should consider using a physically based rendering (PBR) material.

Suggestions

The best thing you can incorporate into your final project is a bit of yourself! Computer Graphics intersects with almost every other field — from Music and Math to English and Entomology. See if you can find a meaningful and unique project that sits at the intersection between graphics and your personal interests! Infusing your passions into your topic will also help keep you motivated and invested in the project during the long grind of the implementation phase. After all, you are expected to individually spend more time with this project than you did on any of the preceding assignments.

Another possible brainstorming direction is to connect this final project to current events. Perhaps you could use the project as an opportunity for social and cultural commentary. Alternatively, consider how you could use your project to visualize and simulate an important effect or discovery that is relevant to your world. For example, during the COVID-19 pandemic, a final project could investigate the effects of social distancing by simulating contagion across populations with differing behavioral patterns.

Note that your project does not have to be rooted in entertainment (aesthetic or otherwise). If you want to pick a very tricky research project (let’s say “pose estimation” or “localization using differentiable Monte Carlo ray tracing”), we will not penalize you if you make great progress on the problem through your implementation but do not end up solving the research question at hand. Diving deep into research questions can be rewarding by itself.

Finally, we cannot recommend it strongly enough that you spend some time drawing inspiration from existing graphical projects on the web during the brainstorming process. At least very least, try clicking through a bunch of the projects posted to the ThreeJS homepage! There are a plethora of awesome demos, including this, and this, and this, and this — just to list a few! The ThreeJS examples page, which showcases all the features of the library, is also a great resource inspiration, and it can help you better understand the tools you will have at your disposal, if you decide to implement a ThreeJS project for the final project.

Examples

The best examples from years past are already listed in the Final Project Hall of Fame, which we highly recommend you check out! You should be able to view both the live demos and the source code for these successful projects.

II. Proposals

The Elevator Pitch

You will give a brief elevator pitch for your project during the final lecture of this class, which has been reserved entirely for project proposals. Each group will have just over one minute to quickly pitch their project, followed by about a minute of instructor feedback. This timing is a bit tight, and so to keep things moving and ensure that every group presents, we may need to interrupt you if you exceed your allotted time. Note that your attendance during the entire proposal session is compulsory, and that project proposals account for 5% of your final project grade.

During your group’s elevator pitch, please include your names, your project title, and a brief description of what your project is about. You should also outline your planned approach (i.e. how you will implement the project, touching on framework, tools, libraries, assets, languages, etc.) and state the minimum results and deliverables you will ideally achieve by the deadline. We would also like to hear about the reach goals you will tackle if everything goes smoothly and you finish the baseline implementation of your project on time or ahead of schedule.

Finally, you are asked to prepare a handful (literally a handful) of slides as a visual aid that pertains to your idea and maybe some related examples, but please do not spend too much time preparing for the elevator pitch. After a certain point, that time would be better spent reading tutorials and starting the implementation phase of the project itself.

If you have pressing questions about your project idea that need to be answered before the proposal session, please do not hesitate to reach out on Piazza, or consult with TAs after precept or during office hours.

Feedback and Participation

After the proposal session is over, each group will receive light feedback from instructors regarding their proposed project idea. Generally, our notes are a mix of encouraging comments, implementation advice, potential extensions, and reference examples that you may want to consider; occasionally, however, we might voice concerns about your proposal and either suggest an alternative direction, or, vary rarely, a total project switch.

In addition to receiving feedback from instructors, you will also receive feedback from your peers. Reciprocally, you are asked to provide brief proposal feedback to your peers via a short Google form that you should fill out during each group’s elevator pitch. For every group you provide sufficiently-meaningful feedback and suggestions to (i.e. not empty and not repeated), you will earn credit towards your Participation grade in this course.

III. Implementation

ThreeJS Tutorials

While we do not expect you to become ThreeJS experts (that is, if you are using ThreeJS to build your final project), you will probably need to be fairly comfortable using this library in order to build a system that will score full points.

As far as learning ThreeJS from scratch goes, we highly recommend the ThreeJS Fundamentals Tutorial, although we actually discourage reading the “Start Making a Game” section because its more confusing. contrived, and overcomplicated than it is helpful. We also are not fond of their “Responsive Design” section because it is not optimized for full screen games (which should just use event handlers). Conversely, we cannot highly recommend enough that you read their guide on how to dispose of objects and how to optimize lots of objects by merging geometry.

Although there will be some overlap with the ThreeJS fundamentals tutorial, you also might want to quick peruse through the relatively short official ThreeJS Manual. The “Next Steps” section of the manual in particular contains some important information, including how to update objects, how to dispose of objects (again), and how to use post-processing. If you are looking for additional tutorials, references, or examples, the Useful Links page of the manual is an excellent resource.

Once this is all done, read through this fantastic list of ThreeJS tips and tricks, which we highly recommend you keep on hand while working on your project. Finally, now that you have strong foundational knowledge of ThreeJS, you should take twenty minutes or so to look through the entire the ThreeJS examples page so you have a complete knowledge of your toolset for the final project. You might also want to look under the hood of Assignment 5 to see how we use ThreeJS to animate the cloth simulation.

Getting Started

Because a majority of groups will pursue ThreeJS projects, we are providing some basic ThreeJS starter code to jumpstart your project’s implementation. Although you are welcome to start from scratch or even draw from existing frameworks or skeletons, we have designed our starter code such that you will have a far easier time building a modular and elegant project implementation, which will pay off in the long run.

If you would like to use our starter code, please download this zip file and follow the instructions in README.md. Note that you will have an easier time reading the readme markdown if you dump the starter code into your project’s GitHub repository, push your updates to the GitHub servers, and then view README.md on GitHub’s website (which automatically renders markdown files).

Divide Et Impera

Divide and conquer this assignment; you will not get very far if everyone is responsible for a bit of everything. We recommend that you assign everyone on your team to relatively independent roles. This will allow your collaboration workflow to parallelize well, and it will reduce the likelihood of any one group member being unable to proceed because they are waiting on a feature from (i.e. blocked by) another group member. Additionally, if you are careful about how you assign roles, a divide-and-conquer group structure will allow each group member to really focus on and master their own one or two domains of the project.

As an example, for a group of four building an art demo: one person could be dedicated to building the physics pipeline; another person might be responsible for both designing the interactive component of the project (i.e. the art demo equivalent of “gameplay”) and implementing user interaction handlers; a third teammate could be assigned to assemble and populate the project scene (geometry, materials, and lighting); and finally, the last group member might not only take care of dynamic object behaviors, but also be the point-person for synthesizing everyone’s individual contributions into the finished product.

Building an MVP

The very first goal for your group should be to build a working minimum viable product (MVP). While you should make an effort to keep your code clean, the actual interactive output for the MVP should probably be quite messy. The aim here is for you to take your project idea, reduce it to its absolute barest bones, and just get something working. Once you have your “something”, it will become much easier to improve, extend, and polish it into a shining gem of a final project!

As an example of what an MVP might look, say we are building a foosball simulator. At its very core, foosball is just cylinders knocking around a ball on a field; thus, our foosball MVP would probably only involve a simple, untextured sphere rolling around on a basic plane, as well as basic collisions against static, non-spinning cylinders. More MVP examples include: a box moving around under keyboard input for a car game; a spherical mesh with a deformable surface for a planet builder; direct illumination for a path tracer; et cetera.

Improving the MVP

Congratulations! If you have made it this far, you have gotten through the most difficult step; however, there is still a long road ahead

Now that you have an MVP, it will be much easier to improve upon and extend your code, even if you only do so in small increments. During this stage, you should aim to make your project more or less feature-complete. Additionally, you should start to add some moderate polish to your project, such as basic textures, user interactions, and visually attractive geometries (even if they are just basic ThreeJS geometries merged together — e.g. representing a car using two boxes for the body and four cylinders for the wheels). At the end of this step and before you move on, you should be satisfied enough with your working product that you would be willing to put your name on it and share it with a friend (not that you have to do that… yet).

Every final project group will face major implementation decisions and challenges that are specific to their project topic. You can think of these as the big “questions” — unique to your group — that your project alone is investigating. It is critical that you answer these “questions” during this stage, and you should also make sure to address them in your written report.

Polish and Final Touches

By this point, your project should be functionally complete, but perhaps not cosmetically complete. Now that all of your features in, you should dedicate at least a day (if not as many as three or four) to making your project look amazing.

If you’re using simple geometries to represent geometries, you might consider stylizing projects with a post-processing pass, such as bloom. If you’re instead aiming for realism, spend time with your materials and look into getting physically-based rendering (PBR) into ThreeJS. If you have a significant interactive component, you might want to design a custom user interface — see if you can use HTML to provide a GUI beyond the dat.Gui interface included in the starter code.

Finally, if you have time in the last few days of reading period (even if your project isn’t quite finished), we highly recommend that you post your live-demo, along with a feedback form, to Piazza. User feedback is priceless; we cannot understate this. Historically, groups that solicited user feedback not only scored higher on the project itself (because they were able to make revisions and improvements in response to the feedback), but also scored higher on the writeup (because they were able to meaningfully incorporate the field data into the results and discussion sections of their written report).

General Advice

We cannot emphasize enough that you start working as soon as possible. Experiment a lot, and don’t be afraid to just try things, as wild as they may be. You can’t be certain that an approach won’t work until it crashes your browser tab!

Here are some additional tips, some of which are more obvious, but warrant repeating:

• If you are blocked, reach out. We are here to support and guide you. Additionally, your peers may all be blocked on a similar problem, so posting your problem to Piazza can be extremely helpful (especially for communicating the solution or fix).
• Comment your code! Keep it code clean and well-organized!
• Modularizing your code from the start will only make your life (and your partners’ lives) much easier.
• Try to use appropriate object-oriented abstractions for your project whenever possible. This will help keep you focused on core logic, rather than on the boring details (and potential bugs) of individually updating and moving meshes.
• Operate on groupings within the scene graph rather than on huge lists. Take advantage of local reference frames if you need coordinated movement.
• Read the ThreeJS docs carefully! They are relatively concise, yet contain buckets of useful information.
• For a project of this scope, the best projects are often stylized to take advantage of the simple geometries and materials ThreeJS provides off the bat. Consider stylizing your own project to speed your implementation along.
• As mentioned earlier on this page, consider using a physics engine, or look into using a Web Worker to take physics off the main thread (since they can be resource intensive).
• Familiarize yourself with the many geometries, materials, and shaders that ThreeJS provides! An engineer should know their toolset like the back of their hand.

Resources

We know that this project really throws you into the deep end, but trust us — it will be worth it. While we have already provided a number of links in the sections above to help you navigate the final project, here is a condensed list of resource links that you might find helpful:

• ThreeJS Docs
• ThreeJS Examples
• ThreeJS Fundamentals Tutorial
• ThreeJS Tips and Tricks
• ThreeJS + ReactJS
• ReactJS Flavored ThreeJS
• dat.GUI Tutorial
• TweenJS Animation Guide
• ThreeJS + TweenJS Tutorial
• CannonJS Physics Library
• CannonJS Tutorial #1
• CannonJS Tutorial #2
• Google Poly Model Library
• ThreeJS Character Animation Tutorial
• A Collection of Fantastic Tutorials for General Web Graphics

IV. Presentations

Live Demo

As mentioned in the requirements section, you will need to host a live demo of your project on the web. The easiest and preferred way to do this is using GitHub Pages; if you happen to need a backend (e.g. for a leaderboard), then it is fine to host your demo on services such as Heroku (as this may be easier than linking a separate backend to GitHub Pages).

If you are using the provided starter code, publishing to GitHub Pages is extremely easy. First, ensure that (1) your project is part of a repository, and (2) you have correctly set up your project’s package.json file (see the starter code’s README.md for details on how to do this). Finally, run npm run deploy, and if everything went well, your project will be live at https://USERNAME.github.io/REPONAME/.

Written Report

Each team will submit a written report on Dean’s Date. The report must hosted live in the GitHub repository for the project, and it should be formatted as either a PDF or an HTML file. Ideally, the writeup should measure about four to six single-spaced pages in length (roughly two single-spaced pages for each teammate in your group), before images, diagrams, charts, code blocks, or other vertical-space hogs are accounted for. Note that a longer written report is not necessarily better written report.

At the very least, your report should begin with a short abstract (a brief description of your project and what you accomplished) and contain descriptions of your project’s goals, execution, and outcome. Make sure to document and justify (where appropriate) the approach you chose, the implementation hurdles you encountered, the features you implemented, and the results you generated. Additionally, you should briefly touch on related work when introducing your topic. We welcome you to also include simple diagrams of your project’s overall architecture, as well as the occasional code block wherever they might provide any illuminating information. Finally, please touch on future directions for the project and any known issues as well. Please also provide a breakdown of each group member’s specific contributions to the overall project, and include an informal works cited section (no specific/official format required).

The following is a brief outline you might follow; however, this is just a guideline to help you think about what to say, and these specific items may not match your topic.

• Abstract
• Introduction
• Goal
• What did we try to do?
• Who would benefit?
• Previous Work
• What related work have other people done?
• When do previous approaches fail/succeed?
• Approach
• What approach did we try?
• Under what circumstances do we think it should work well?
• Why do we think it should work well under those circumstances?
• Methodology
• What pieces had to be implemented to execute my approach?
• For each piece...
• Were there several possible implementations?
• If there were several possibilities, what were the advantages/disadvantages of each?
• Which implementation(s) did we do? Why?
• What did we implement?
• What didn't we implement? Why not?
• Results
• How did we measure success?
• What experiments did we execute?
• What do my results indicate?
• Discussion
• Overall, is the approach we took promising?
• What different approach or variant of this approach is better?
• What follow-up work should be done next?
• What did we learn by doing this project?
• Conclusion
• How effectively did we attain our goal?
• What would the next steps be?
• What are issues we need to revisit?
• Contributions
• Works Cited

Final Project Presentations

As scheduled on the course materials page, final projects will be presented over a couple sessions shortly after Dean’s Date. Each team should bring a short presentation (preferably slides) describing their final project, as well as either a live demo or a demo video (please still link your live demo to the class, if presenting a video).

Your goal should be to demonstrate and describe for the class in a few minutes what you have done and why it is interesting. You should describe the guts of your project, identify what external resources you leveraged, explain the overall architecture/design/program flow of your project, and highlight your most exciting and meaningful contributions. Your team will have a total of (2N + 1) minutes where N is the number of students in your team. (So 5 minutes for pairs, 7 minutes for teams of three, etc.)

V. Evaluation

Peer Review

As part of your participation grade for this course, you are asked to provide final presentation feedback to a selection of other project groups. The feedback does not have to be long — just a sentence or two. At the very least, you are asked to be present for the final presentations of the groups to which you are assigned as a reviewer, but you are welcome to attend even more presentations and review even more of your peers for additional participation credit. Expect the form for this peer to peer feedback to appear on Piazza shortly before final presentations begin.

Journey’s End

A few days after the final presentation sessions, you will receive your final project grade via email. We will do our best to summarize the notes that instructors took while scoring both your presentation and writeup into some modest, constructive feedback.