CS 488/688: Introduction to Computer Graphics

Assignment 5: Course Project

Summary

Purpose

Statement

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. So, do something interesting---write a program that does something graphical:

Project breakdown

The project is broken into three goals. The first two goals are project proposals. We will grade and comment your first proposal and return it to you. The second goal is a resubmission of your project proposal, revised according to our comments. We will keep this version of your proposal and use it 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 project proposals is an objective list (like those found in the assignments) and supporting documentation that clearly defines these objectives. The objective mark of your project will be based on this objective list. The rest of this document describes in detail what we expect for a project and what we want in the proposals.

First goal: proposal submission

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

We encourage you to use LaTeX to prepare your proposal. You may want to use Overleaf if you do not have a LaTeX environment installed. Note that you do not need to use Overleaf Professional and can just sign up for free. You can download the file proposal.tex to use as a starting point. Of course, LaTeX is big and complicated. You can find lots of documentation online if necessary. But in the end, LaTeX is not required for the project.

Your proposal should including the following sections:

Proposal grading

The TAs and instructor give points to your first proposal subjectively, by comparing the proposals against each other and against expectations. What we want to see in your proposal is that you have investigated what you plan to do for your project, and that you have decided upon a reasonable project. To receive full marks for the first proposal, you need to have

If you are vague about your plans or objectives, if you are too ambitious ("I'll implement everything that was mentioned in this course") or have unrealistic objectives ("I'm going to implement real-time path tracing that produces perfect images for any scene with 60 FPS", which is not realistic yet in 2021), or if it is clear that you have not read up on your chosen subject, you will lose points.

Second goal: revised proposal

Based on the feedback you receive from the TA and/or instructor, you must submit a revised copy of your proposal, including a revised objective list. While no points will be explicitly assigned to the revised proposal, the objective list of the revised proposal will be used to determine the objective mark of your project. No changes to your objective list will be allowed after you submit your revised proposal.

If you intended to build an extended ray tracer but did not do well on Assignment 4, you should switch to an OpenGL project. If you have to switch projects, make sure you discuss your new objective list with the instructor.

Third goal: project completion

You will submit a final report for your project. This report should should be submitted as an electronic copy, included with the code for your project in LEARN.

The documentation you hand in should comprise:

  1. The standard material listed in the Documentation Submission portion of this handout, with particular attention being given to the Manual section, which should contain a comprehensive guide to the running of the project's program and to the formats, where appropriate, of its input, command line, interaction, output, and procedures for creating/viewing images.

    You are also required to have the usual README telling us how to run your program. In addition, at the end of your README, you should list your objectives.

    As usual, be sure to include a signed copy of the declaration.

  2. An extra Implementation section that describes the software design considerations, including brief descriptions, where appropriate, about

    • Algorithms, data structures, and complexities,
    • Modularity, data abstraction and encapsulation,
    • Platform and system dependence or independence, global constants and configurability,
    • Input/output syntax, Lua extensions if any, pre- and post-processing,
    • Data and code sources, network and literature resources, system and local utilities, the re-use and adaptation of existing code,
    • Intercommunication, shell scripts, pipes, sockets, intermediate files, parallelism and task delegation,
    • Coding style, debugging approach and utilities, version management, testing and verifying practices,
    • Caveats, bugs, cautions, unexplored areas, assumptions, future possibilities.
  3. For graduate students (CS 688) only, a short report on the main points (summary) of the most important bibliographic reference(s) used for the project should also be included.

The documentation you submit strongly influences your subjective mark on the project. In the past, the projects receiving the highest subjective marks had excellent documentation. Often, two projects would have approximately the same technical merit, but one would receive a much better mark due to differences in documentation. Here's a brief rundown of what we look for in documentation:

To give you an example of a reasonable level of documentation, you can download an old but worthwhile sample report. The students in CS 688 should follow the same style, but it has to include more extensive details on implementation and a summary about any related prior work in the published literature.

Deliverables

Prepare and upload a ZIP file of the A5/ directory, omitting unnecessary files (executables, build files, etc.). Make sure to include at least the following files:

Previously written code, use of other people's code

Your final submission should consist of code that you have written expressly for the project. As such, you should not in general use code you wrote in previous terms, nor should you use other people's code in your project. However, there may be cases where you want to build on pre-existing code, use functions in an external library, or build on top of game engines or other 3D environments.

Generally speaking, such cases will be tolerated, but you will not receive credit for work that you didn't do specifically for this project. If you find yourself in such a situation (whether it is code you wrote in previous terms or if it is someone else's code), you should discuss the matter with the instructor. Further, you should document in your project write-up any previously written code or code you get elsewhere. Failure to document use of such code will be considered cheating, even if you wrote the code yourself.

In particular, if you wrote something in previous terms that seems appropriate for your CS 488/688 project, you may not simply submit it as your CS 488/688 project. You may, however, use it as a starting point for your project; you should discuss such a matter with the instructor for the course before submitting your project proposal.

Grading

Your project will have both an objective mark (based on your objective list) and a subjective mark. 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 on 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 arrived at by considering the four components of "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:

These criteria are an example, and they may change to suit the content mix of each term's projects. Nobody's project is expected to hit all these criteria, so we are prepared to give up to 3 points in any category. We will stop when we get to 10 subjective points, although achieving 10 points is extremely rare. On the average, good projects receive 4–6 subjective points, and only unusually, outstandingly, remarkably excellent projects are in the 8–10 range. The TA and instructor will be as fair as possible, but standards will be high, and a "perfect 10" will not be given lightly. We are looking for polish, depth, 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.

Note that we may also give out -1 points in any category. This is for things you have learned during the term that you should have applied to your project, but didn't.

The instructor will tell you how your subjective mark was determined if you ask. However, the subjective mark is subjective; it's our opinion. If we overlooked something in our marking, then we may increase your subjective mark. However, if it is a matter of your opinion vs. our opinion, then we won't change your subjective mark. For instance, if you think your shading algorithm is quite advanced, but we don't, then we won't change your mark. If your friends thought your project was the coolest thing they've ever seen, great! But we won't change your subjective mark.

The highest three total achievements (objective plus subjective) will be distinguished by the special award of "gold", "silver", and "bronze" prizes to be given out at the final exam. Honorable mentions may be awarded to other projects that we feel deserve special recognition.

A note about pure rendering (i.e., ray tracing) projects: if you look at the above list, you will see that you will easily receive points for algorithms, etc., but cannot for hardware (unless you implement GPU ray tracing). You should therefore pay particular attention to the other categories. In addition to written documentation, you are expected to have test images that exhibit the features you have implemented. It is insufficient to just submit your "nice image" since it's not an art class. Further, if you implement an optimization technique, you should give timing comparisons for the renderer running both with and without your optimisations. Your documentation should state where in your code these efficiency improvements are implemented. If any background references were used, summarize these in your documentation.

Demonstrations

Students will provide a video demonstrating their projects as part of their project submission in LEARN. While making a video from your cellphone or a camera might be fine, using video capture software such as kazam or RecordMyDesktop to create a video will probably give you better quality. You should call your video video.ogg (with a different suffix if it's not in ogg format; ie, kazam creates .mp4 or possibly .movie files).

We're not looking for a production quality video here; you'd be surprised at how low of a resolution will be more than adequate for demonstrating your objectives. We're guessing most demo videos will be at most 5 minutes long (ray tracing demo videos should be more like 1 minute long), but if you can demonstrate your objectives in less time, that's definitely preferred. If you find yourself going over 10 minutes, then you need to rethink your demo.

If you're on a linux box with ffmepg installed, try running ffmpeg -i video.mp4 videoS.mp4; depending on how you created your video, this may reduce the file size significantly. If you want to see how a lower resolution file looks try ffmpeg -i video.mp4 -vf scale=534:300 videoS.mp4, although you may wish to adjust 534:300 to match the aspect ratio of your video.

The purpose of this demo video 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 around your objectives and around any of its possible subjective merits.

Be sure that your video illustrates that your objectives have been met (you should provide data and graphs both in your report and your demo to demonstrate non-graphical objectives such as optimization code).

Project demo video requirements

Collected wisdom

The following are some thoughts collected over the past terms of this course: what worked, what didn't work, etc., based on previous projects.

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 past issues of the conference proceedings for SIGGRAPH/SIGGRAPH Asia for example.

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 (Goal 1 of the project). 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 it. For example, rather than say "I want to implement a microfacet shading model and path tracing", it'd be better to say "I want to write a ray tracer that supports photorealistic renderings of glossy metallic surfaces". The objectives are (roughly) the same, but the latter results in a cohesive project, while the former may result in an unsatisfying project even if all the objectives are met since you might not have thought about what to do with those new features.

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 other projects. Here's some projects that we won't accept unless you extend them in a novel way:

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

Rasterization or ray tracing?

One of the big decisions you need to make when deciding upon a project is whether to do an OpenGL project (thus probably with rasterization), or a ray tracing project. It is simpler to think up a ray tracing project: You just have to make a list of extensions to the ray tracer in A4. Interactive projects are a bit harder to devise: You need to think of an idea, determine what's interesting, and work it into a project.

For a rasterization project, you should be aware of the fact that it will involve a lot of GPU-related coding. Such a program might be difficult to debug than CPU-only program and getting a good performance can require a lot of low-level tuning and deeper understanding of how GPUs work. Be also aware that using advanced GPU features might make your project incompatible with the provided Virtual Machine, so you might need to be ready to develop and run your project on you own PC with a GPU.

For a ray tracing project, you should think of an image/scene you want to render. Then develop your project around this scene: What features does the ray tracer need to render this scene? What features will you need to make it look realistic? Then, as you extend your A4 ray tracer, you can develop the model for your scene as you go. You should mention your scene in your proposal, and while it will be ideal if you show us a picture of the scene at your demo, it is not a requirement that you do so.

Most ray tracers will need some form of light transport simulation to get a nice picture. For example, if you implemented path tracing incorrectly, your image might look extremely bad and might not demonstrate well that you worked on path tracing. Hence, it may be difficult to get good subjective marks without close attention to considerable mathematical and implementation detail. Be sure you know what the issues are before you promise to do something, particularly in rendering projects.

Note that it's entirely possible to make an interactive application with GPU ray tracing. Such a project can be challenging because it basically has all the challenges mentioned above. As of 2021, just because your project uses ray tracing doesn't mean that it's going to be non-interactive, and just because your project is based on rasterization doesn't mean it's interactive.

About the proposal

The goals of your proposal are (a) to tell us what your project is and (b) convince that your project is reasonable in the sense that it's not to 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 out the steps in the algorithm and include necessary equations.

When we read your objective list, 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

What are good, reasonable objectives? Briefly, an objective is a unit that contributes one fundamental, essential goal to your project. On the average, an objective is roughly 1/10 of your work. In a 2–3 week development time, it represents 1–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 follows:

  1. Add light transport simulation
  2. Add filtering

The first objective is too broad and should be broken down. The second objective is unclear what it actually means (filtering textures, pixels, or it might mean denoising?). Both are too vague, although if adequately described in the Technical Outline then they might be okay.

Here are good things to avoid in your objectives list:

These are expected to be true as a minimum, not as objectives worth special mention. You should also avoid such objectives as

We went through these in the earlier assignments. Of course you can do this. It's not worth including as an objective. Finally, here are some objectives that are too vague:

What is the meaning of "interesting"? Who decides what is "useful" or "good"? How does the TA assess what goal has been reached? Perhaps you actually have more concrete ideas, but have not written them down properly.

In short: an objective should be precisely stated, clearly understood, capable of unambiguous determination about whether and to what degree it has been met. If you are using words like 'nice' or 'easy' or 'useful' or 'simple' or 'interesting' or 'realistic' in your "objective", then it's probably subjective and should be changed. Your objectives should not rehash fundamental objectives of past 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 addressed specifically to the unique points of your individual project. An objective is given as a short, simple, declarative statement. For example, we can rewrite the two raytracing objectives given earlier as such:

  1. Bézier surfaces are subdivided into polygon meshes.
  2. Phong shading is added.
  3. Super sampling is used for anti-aliasing

One other thing to be careful of when making goals: your goals should have some technical graphics content. Unacceptable objectives are "feature" goals without graphics content. This commonly happens with game projects. For such projects, displaying a numeric score, or giving the player extra life when a food pod is consumed may all be nice game features, but none of them are acceptable as objectives for a graphics project. Keep in mind that the main point is to demonstrate your understandings of computer graphics, not video game development or digital arts.

Bibliography

An excellent way to prepare for a good proposal, and to continue from there to a successful project, is to give evidence that you have informed yourself about the issues and the techniques. You do this through reading some reference material. An ideal preliminary source of ideas can be provided by looking in the index or table of contents of the texts, both required and recommended, for topics of interest. These texts will often point off to the literature for further reading. Including specific pertinent references to the literature in your proposals is a good way to show that you know what you are doing. For example, on 3D textures,

Bad bibliography:

Computer Graphics, C Version, Second Edition, Hearn and Baker, Prentice Hall, 1997

(This just lists a book containing information on hundreds of topics.)

Good bibliography:

(This lists specific pages on the subject in a reference text, and it additionally lists two landmark conference articles on the subject.)

If you use reference material on the internet, you should certainly list it in your bibliography, but a website alone is not an acceptable reference. Websites detailing algorithms often list the source, so make sure you check those out as well.