CS 488/688: Introduction to Computer Graphics

Spring 2022 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. Note that this first proposal is worth about half as much to your final grade as a homework assignment. 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 chapter 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. LaTeX is the absolute standard for scholarly writing. You can download the file proposal.tex to use as a starting point, and use the command pdflatex proposal.tex to compile it into a PDF. 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 or have unrealistic objectives, 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.

By the time the revised proposal is due, you should have received your graded Assignment 4. If you intended to build an extended ray tracer and did not get at least 9/10 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. Projects will be returned (in some form) and prizes will be awarded at a session before the final exam.

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 only, a short report on the main points of the most important bibliographic reference(s) used for the project.

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. Graduate documentation is to be done in 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. For example, if you do not have shading, you may get -1 in a category such as graphics techniques.

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. I.e., if you feel your user interface is easy to use, 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 can not receive any for user interface issues. You should therefore pay particular attention to the following categories: Visual Design and Aesthetics (make a very nice image) and Documentation. 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". 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 demonstrate their projects at the end of the term; either a sign-up sheet will be posted on the instructor's door or an online sign-up system will be used.

The purpose of such a demo 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. Your objective points will be awarded during the demo. The subjective points are determined by the Instructor and the TA(s) as they explore your project again at a later time.

Only the TA, the instructor, and the student giving the demo will be allowed in the lab during the demonstration. Approximately 10–15 minutes will be given for each demo. You should rehearse your demonstration ahead of time, and make sure all your data files and executables are set up properly beforehand.

Project demo requirements

Collected wisdom

The following are our thoughts on various projects: 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 or Graphics Interface—both of which are in the library.

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 walk through a L-system forest on a fractal terrain", it'd be better to say "I want to write a golf game with trees and hills". The objectives are (roughly) 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 other projects. Here's some projects that we won't accept unless you extend them in a novel way:

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

OpenGL or ray tracing?

One of the big decisions you need to make when deciding upon a project is whether to do an OpenGL interactive project, 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. 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.

Both are acceptable as projects. And while students have won awards (see below) for both types of projects, past experience indicates that interactive projects (on average) receive higher grades. Although this may in part be a reflection upon the type of students (in general) who choose ray tracing projects, there is one definite difficulty with ray tracing projects: You have to write an excellent ray tracer to get a good subjective score. And here is a hint of what we mean by excellent: You cannot do a ray tracer project unless you got at least 9/10 for Assignment 4.

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 CSG and some form of texture mapping to make a nice picture—and you can't get good subjective mark without one. However, to be a project with substance, you would need to make fairly complete/general implementations of CSG and texture mapping. And texture mapping (mapping a 2D pattern or image onto a surface) is difficult to do well, without objectionable distortion. Hence, it may be quite 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.

As discussed later, a nice scene is critical for the subjective marks of a raytracing project. We don't want to just see shapes, we want to see an actual scene. If you don't have a fine arts background, we recommend against doing scenes with just a few simple objects, i.e., you should model real life objects in a real life scene.

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. For raytracing projects, include the commands that must be added to the input language.

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. For raytracing projects, explain how your objectives will be used in your scene.

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 spline surfaces
  2. Add anti-aliasing

The first objective is too difficult and should be broken down. Both are too vague, although if adequately described in the Technical Outline then they might be okay. In this particular project, the person who wrote those objectives (no, we did not make them up) is revealing that he/she hasn't a clue about what any of those words means.

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:

Can't you be a bit more specific? What is the meaning of "interesting"? Who decides what is "useful" or "good"? How does the TA assess what goal has been reached?

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. We commonly allow one of each of the following as objectives

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.

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.