CS 488/688: Introduction to Computer Graphics

Spring 2022 Assignment Information

CS 488/688 assignments are long and complicated, contain many steps, and require a lot of coding. We do our best to make sure that they can be completed in the time available, and with a minimal chance of losing marks for unexpected reasons. Still, potential issues can and do arise. Here are some additional notes that may help you avoid losing marks, and improve the general state of our assignments in general.

Objectives aren't everything

You can lose marks for things that are not explicitly stated in the assignment objectives. Submission of poorly written code could result in a deduction. Failure to put specified files in their correct locations is another example. You can also lose a mark for submission of a program with a poor user interface. Generally, make sure to read assignment completion and submission instructions in full, and to prepare a submission that is clear, clean, and considerate towards the TAs.

Ambiguity and omissions in assignment specifications

No assignment specification is able to describe every step in perfect detail and eliminate any possibility of ambiguity. Some aspects of CS 488/688 assignments are left to your discretion. Wherever something is ambiguous or omitted, you are to use your own judgment. The essential thing to do is to identify and describe what you are doing and why. Document your decisions and especially any added features you implement if you want them to be recognized.

We always enjoy it when students take assignments in a new direction, adding features or new ideas. But in general, you should avoid changing the default behaviour of the assignment. The TAs will expect to mark assignments quickly, trying out the same sequences of operations to award objective marks. If you add features to assignments, then make them optional whenever possible and document the changes in your README.

If you think some aspect of an assignment specification or donated source code is broken, it may well be. Let us know well before the assignment is due and we may be able to fix it or modify the specification and benefit everyone in the class.

Code credit

Code that is not efficient, well written, well structured, and/or well documented may result in the deduction of points. On the other hand, it is possible for non-functioning code to be given credit. Credit for code that does not work must be requested in writing in the README that accompanies your handin: TAs will not grant code credit automatically.

What you are actually doing when requesting code credit is stating which objectives do not work properly and asking for the TAs to examine code to give you up to 1/2 credit for each nonfunctioning objective. For each missed objective, your request must state the following explicitly:

  1. What code files do not work, and the relevant line numbers.
  2. What execution features of the code in these files do not work (i.e., describe the current behaviour).
  3. What you think the probable cause of the problem is.
  4. What steps you have undertaken and will/would continue to undertake to track the problem down and correct it.

If you fail to provide this information, the TAs may not give you credit for your code.

The code in question must be stylistically good, well organised, heavily commented, and clearly documented. You must make it easy for the TA to understand what you are doing in your code. If the TA cannot understand your code, you cannot expect them to give you any credit for it.

Disclaimer: Requesting code credit does not guarantee that you will get it. It is up to the TA's discretion whether you get code credit. Whether you get code credit will not only depend on the state of your code, but also other factors such as the details of the assignment objective in question.

Academic integrity

The programming assignments are designed to give practice on the topics presented in lectures. It is important that you learn all you can by doing them.

One activity that promotes learning is discussing the assignments, in class, with the instructor, with the TAs, and with others in the class. These discussions are to be preliminary in nature, exploring the possible tools, techniques, and issues involved in the solution. The discussions can take place in class, on Piazza, and in small groups of other class members. Feel free to participate.

The second activity that promotes learning is that each student individually works out a solution and composes their own code to execute the assignment. If you take this course, you agree to be bound by this requirement, along with all the rules for academic integrity found in the course outline. If you are discovered not to have abided by these rules, we will always apply the full expected penalty, which is severe. If you ever have any questions about what may or may not constitute cheating, please ask the instructor first so you don't end up breaking any rules by accident.

Please do not post solutions to assignments in a public place online, such as GitHub, Pastebin, or anywhere else that future CS 488 students might gain access to them.

Use of outside code and assets

The code you submit should be code you wrote. For the project, it may make sense for you to use code or assets (e.g., 3D models, sound files) written by someone else to assist you in your work. Further, you may wish to reuse code you wrote for previous assignments in this course, or even in other courses. In both cases, you should check with the instructor beforehand, and credit the code (even if it was code you wrote) in your documentation for the assignment/project. However, you do not need to give credit for code that we provide for you. See the discussion of projects for more information on using code you previously wrote as part of your project.