Summary

Purpose

• Demonstrate your grasp of computer graphics.
• Implement a (set of) graphics algorithms of your own choosing.
• Use these graphics algorithms in an interesting context.

This assignment is the culmination of your efforts. Its primary purpose is to allow you to plan and execute a project of your own creation. Do something interesting. Write a program that does something graphical:

• Invent a lighting or appearance model…
• Make an innovative use of the hardware features…
• Simulate the {physics,dynamics,behaviour} of something…
• or…

Project breakdown

The project is broken into three goals. The first two goals are project proposals. As the first goal, write and submit a proposal. The second goal is to resubmit your project proposal, revised based on our comments or on what other students are doing. We will use your proposal to grade your project. The third goal is the final project itself, which will receive both an objective mark and a subjective mark.

What we want in your proposals is an objective list (like those found in the assignments) and supporting information that clearly defines these objectives. The objective mark for your project will be based on this list of objectives. The rest of this page describes what we expect for a project and what we want in the proposals.

First goal: proposal submission

You submit a statement of what you intend to do in the format of a course assignment.

You should submit your proposal via the provided link on Piazza, and your proposal should include the following sections:

• Summary of the nature of the project in a general and introductory tone.
• Technical Outline section surveying the important data structures and algorithms that will be necessary to achieve the goals.
• Objectives sheet containing EIGHT different points upon which the achievement of the stated goals is to be judged. Do not list anything that has already been done and claimed for the extras in the assignments.

Second goal: revised proposal

If you received any feedback from the TA and/or Instructor, you must revise your proposal, including a revised objective list.

Third goal: project completion

You obviously need to complete your code. Besides, your README should now contain

1. A brief description of your program. What does it do?
2. The usual README content telling us how to run your program.

3. An extra implementation section that describes some software considerations, where appropriate, about

   • Algorithms, data structures, and complexities,
   • Platform and system dependence or independence, global constants and configurability,
   • Input/output syntax, pre- and post-processing,
   • Data and code sources, the re-use and adaptation of existing code, and any acknowledgment of external sources.
   • Caveats, bugs, cautions, assumptions.
4. At the end of your README, you should list your objectives.

For graduate students (688) only, include a short report on the main points of the technical details used in the project. We expect something like methods sections in technical papers. Write it as if it were a short paper. We generally apply higher standards for graduate students.

Demo video

Students will provide a video demonstrating their projects as part of their project submission. Using capture software to create a video will probably give you better quality. Avoid using your phone to capture your monitor whenever possible.

We're not looking for a production-quality video here. We're guessing most demo videos will be around 3 to 5 minutes long, but if you can demonstrate your objectives in less time, that's definitely preferred. If you find yourself going well over 5 minutes, then you need to rethink your demo.

If time permits, we may have "intermediate demo" sessions for students to showcase what they have done so far.

The purpose is for you to show that you have met your objectives, to show any extra features you have added, and to make clear what particular strong points you feel your project offers in any subjective categories. Therefore, you should base your demonstration on your objectives and on its subjective merits.

Be sure that your demo illustrates that your objectives have been met. For example, you should provide data and graphs in both your README and your video to demonstrate non-graphical objectives, such as optimization.

• Ideally, demonstrate your objectives in the order in which they appeared in your revised proposal. Likewise, if you didn't complete an objective, state that in your demo.
• Make sure you've tested your program.
• There should be no reason to recompile or edit things during the demo.
• For interactive projects:
  • You may want to toggle features such as texture mapping, shadows, reflection, etc. in your program, rather than making a separate program for each.
  • You may want to implement a cheat/god mode to demonstrate some objectives, if your program is like a video game. For example, if you implement some advanced rendering effect that shows up when you hit 5 moving targets in a row, a cheat mode where you never miss will be useful and maybe even necessary. Remember that it is a graphics course, not a game course.
• For non-interactive projects:
  • Each objective should have 1 or 2 images (for comparison) to illustrate that you have completed that objective. These images should not be your final scene and should preferably demonstrate only 1 objective. Rehearse showing your images. You don't want to search for the image that shows your objective during the demo.
  • Be sure to explain what you implemented and what to look for in each image.

What to submit

Prepare and upload a ZIP file, omitting unnecessary files (e.g., executables, build files). Make sure to include at least the following additional files:

• README file, as usual. Your README needs to include a description of how to run your project (command-line options, etc.), a brief description of the user interface (so we can run your project if we so desire), and your objective list. If you use external models, images, etc., credit where you got them from.
• Screenshot, in the file screenshot.png. The screenshot should be the best image of your project. You may submit additional images depending on the nature of your project.
• Demo video, in the file video.mp4 (or whatever appropriate extension) as described above.
• Report, in the file report.odf for 688 students only.

Grading

Your project will have both an objective mark (based on your objective list) and a subjective mark. The weights for objective and subjective marks are to be determined based on discussion among the TAs and the Instructor, but you can expect that the objective mark will have a larger weight in general.

The subjective grade for your project will be based upon a subjective assessment by us, the Instructor and TA(s), of how your project ranked against the others submitted this term, as well as projects like yours submitted in past terms. The subjective mark will be assigned somewhat like the judging in Olympic figure skating (minus the bribes). Your list of objectives provides the scores for the "required elements", and our assessment provides the scores for the "individual merit". The individual merit judgment will be based on the four components: "artistic and/or innovative content", "technical depth", "software design", and "quality of documentation". This judgment will, necessarily, be subjective, given the wide diversity of projects. In the past, we have used such criteria as:

• Technicality: Algorithms, mathematics, physical or optical simulation, data structures.
• Performance: Performance optimization of the code beyond those in the assignments.
• Documentation: Quality, thoroughness, and depth of documentation, background references, literature summaries, and breadth of resources employed.
• Difficulty: This category is used to reward exceptionally difficult projects.

These criteria are examples and may change to suit the content mix of each term's projects. No one's project is expected to meet all these criteria. The TA and Instructor will be as fair as possible, but standards will be high, and a "perfect subjective mark" will not be given lightly. We are looking for polish, depth, and professionalism. We are trying to find the remarkable and locate evidence of care, thought, effort, and skill that puts the project above one that just managed to get its technical objectives.

The Instructor will tell you how your subjective mark was determined if you ask. However, the subjective mark is just our opinion, so you'll likely disagree with us. If we overlooked something in our marking, then we may increase your subjective mark. However, if it is a matter of your opinion versus ours, we won't change your subjective mark. If you feel your project is the coolest-ever, but we don't, then we won't change your mark.

A note about pure image synthesis (e.g., ray tracing) projects: In addition to written documentation, you are expected to have test images that exhibit the features you have implemented. It is insufficient just to submit your "nice image". Further, if you implement an optimization technique, you should give timing comparisons for the renderer running both with and without your optimizations. Your documentation should state where in your code these efficiency improvements are implemented. If any background references were used, summarize these in your documentation.

Collected wisdom

The following are our thoughts on various projects: what worked, what didn't work, etc.

Finding a project

There are several ways to find a project. First, you may have seen something in the course that you want to learn more about. This is the ideal case: just follow up on what you are interested in and see if you can make it into a project. The second way to find a project is to look for an interesting topic in a textbook or through papers published at computer graphics conferences such as SIGGRAPH, SIGGRAPH Asia, and Eurographics. You can often find such technical papers online.

In both cases, you should try to find a project that is neither too hard nor too easy. The first step in deciding if a project is just right is to make up a list of objectives. Further, you should look at the list of subjective marks upon which we grade your project, and try to decide what subjective marks you could hope to get from your project.

As a general comment, think of the final overall effect you want from your project and come up with objectives for that effect, rather than think up objectives and build a project around them. For example, rather than saying "I want to add various relevant features to my ray tracer," it'd be better to say "I would like to render realistic cloths, and here is a list of required features that I plan to implement. "The objectives can roughly be the same, but the latter results in a cohesive project, while the former results in an unsatisfying project, even if all the objectives are met.

If you have questions about what makes a reasonable project, ask the Instructor or the TA. In the past, students who discussed their project with the instructor before submitting their first proposal would generate much better proposals and ultimately have better projects than those who did not see the Instructor.

Projects to be wary of

In the past, some projects have worked better than others. Here are some projects that we won't accept unless you extend them in a novel way:

• Game without any new graphics features: You do not get a point by making a fun game. Make graphics the central theme, not the gameplay itself.
• Procedural modeling: While it is fine to use procedural modeling in your project, generally, there isn't enough to make a full project. Providing lots of examples via procedural modeling does not really count.
• Non-physics-based animation: Animation that is driven by some heuristic rules is more of an art. Examples include (fake) fireworks and solar systems. Make it physics-based instead.

Here are some examples of projects that often (but not always) fare poorly when it comes to grading:

• Character animation: It's harder than it looks to support animation. Moreover, making such an animation by yourself takes a lot of time, and it does not really count technically.
• Extended ray tracing: It's not that it is bad, but we've seen a lot of them, so our standards are high. We at least expect a working light transport simulation of some form (e.g., path tracing).
• Modeling system: A general-purpose modeler is hard to implement. If you want to implement a modeler, design it to build something specific, and expect to spend a lot of time using your modeler to make an interesting model (which, again, does not count much technically).

Rasterization and ray tracing

One of the big decisions might be whether to do rasterization or ray tracing. In general, rasterization is suitable for interactive projects and ray tracing is suitable for non-interactive projects, but this division is not as clear as it used to be. There are, in fact, many recent examples of interactive ray tracing programs as of 2023. You can also do both at the same time, which is very common in some AAA video games as of 2023.

Proposal

The goals of your proposal are (a) to tell us what your project is and (b) to convince us that your project is reasonable in the sense that it's not too hard and not too easy.

Technical outline

In this section, you need to explain the important data structures and algorithms that will be necessary to achieve your objectives.

How well do you need to explain the data structures and algorithms? Well, you must convince us that you understand what is involved with each objective. For example, if you have bump mapping as one of your objectives, you must explain to us how you intend to map the bump map to each primitive, how the normals are perturbed, etc. If you are implementing something from a paper, it is not enough to refer to the paper; we expect you to list the steps of the algorithm and include the necessary equations.

When we review your list of objectives, we will refer to your technical outline for details. A good technical outline will tell us exactly how you intend to achieve each objective.

Objectives

Briefly, an objective is a unit that contributes one fundamental, essential goal to your project. With a 2- to 3-week development time, each objective may require 1 to 2 days of planning, implementation, checking, and correction. A poorly done proposal is often characterized by attempting way too much, and that derives from not understanding clearly what is involved, either in terms of objectives or in the difficulty of each objective. You should also think about what kind of subjective marks you can get. If a project is too difficult, you may have trouble getting your objective marks.

Examples of poor objectives for extending the ray tracer follow:

1. Add light transport simulation.
2. Add anti-aliasing.

Both are too vague, though if adequately described elsewhere, they might be okay. Make sure you have some ideas about what it takes to achieve each objective. The first objective is also too general and should be broken down.

Here are some other things to avoid in your objectives list:

• Reorganize the code.
• Make the code well-commented.
• Program executes correctly.

These are expected to be true as a minimum or should be taken care of by yourself, not as objectives worth special mention. You should also avoid objectives that talk about things you did not complete in the earlier assignments. Of course, you can fix and complete them, but you cannot count them as objectives in the final project. Finally, here are some examples that are too vague:

• Interesting interaction.
• Useful visual feedback given on screen.
• Good use of color.

What is the meaning of "interesting"? Who decides what is "useful" or "good"? The Instructor and the TAs will have no clue what to look for.

In short, an objective should be precisely stated, clearly understood, and capable of unambiguous determination about whether and to what degree it has been met. If you are using words like 'nice', 'easy', 'useful', 'simple', 'interesting', or 'realistic' in your "objective", it's probably subjective and should be changed. Your objectives should not rehash objectives of earlier assignments, and they should not address basic software engineering issues that every good CS student should have mastered by now. Concentrate on objectives that are specifically addressed to the unique aspects of your project. An objective is given as a short, simple, declarative statement.

One other thing to be careful of when making goals: your goals should have some technical graphics content. We commonly allow one of each of the following as "easy" objectives

• A modeling objective: This can be just something you want to render in the end.
• An animation objective: if you are implementing an animation system, creating animations with it can be one objective.
• A user interface objective: this objective can be used for some slightly complex interaction, such as editing a triangle mesh. Manipulating the camera or saving images cannot count in your UI objective since they are already covered in the base code.
• A game engine objective: this objective may not really have technical graphics content, but may be useful for games. Examples include a visual effect with particles.

Unacceptable objectives are "feature" goals without any graphics content. This commonly happens with game projects. For such projects, playing sound, displaying a numeric score, or giving the player extra life when a food pod is consumed may be nice game features, but none of them are acceptable.