This class has been assigned to the "Storm" laboratory in B240 Computer Sciences. 559 students have priority on these machines, so if the lab is full of CS302 students feel free to ask them to another lab.
You are free to work on other machines (such as your home computer or laptop) subject to the following caveats:
Your programs must be written in C++ and compile with Visual Studio .NET 2003 (the version provided in the Storm lab). For some thoughts on C++, see the C++ hints page.
Computer graphics is (usually) a team sport. In fact, learning computer graphics (and, arguably, learning in general) is best done in collaboration with others. Unfortunately, in a university class setting, we have the unfortunate constraint that we must grade individuals independently, so we need to have people work independently on graded assignments so that we can assess them. Therefore, there is a fine line between "collaboration" and "academic misconduct".
For CS559, we want to encourage collaboration. However, we also need to make sure that each individual gets appropriate credit for there work.
Students are encouraged to discuss class topics and assignments with other students, subject to the following rules.
Written assignments are always due at the beginning of class on a Tuesday. If you aren't going to come to class, deliver the assignment to the TA beforehand, or give the assignment to a classmate to hand in for you. (the beginning of class is to discourage people from skipping class to do the assignment).
When an assignment is delivered to the TA, they will note the time it is turned in on it. The student should make sure this happens.
Written assignments will be graded "check" (acceptable) "no check" (turned in, but unacceptable) or "not turned in." These grades are a qualitative judgement of the TA. The TA may also note exceptional assignments. These notations do not directly count in your score, but may be considered when we do final grading. (see extra credit below).
Late assignments may be handed to the TA. The TA may accept them at his discretion. In particular, the TA will not accept assignments turned in after the assignment has been graded (which may be soon after the due date). Late assignments will be noted and will be penalized.
Details of programming projects will be given when they are assigned.
Projects are always due on a Tuesday, at the beginning of class. The time that a project is considered "handed in" is determined by the timestamps in the student's handin directory.
Projects will be graded in two parts: an in-person demo (where the student will demonstrate their program to the instructor or TA) and the instructor/TA's "reading" of the project.
Late projects will be accepted for a penalty. Projects will not be accepted after the scheduled demos begin. Late projects will be considered either "late" (handed in after 9:30 Tuesday, but before 9:30am Friday) or "very late" (handed in after 9:30am on Friday, but before the first scheduled demo).
A student may turn in one project late without penalty. After that, late projects receive a 1/2 letter grade penalty. Very late projects receive another 1/2 letter grade penalty in addition to any late penalty.
(note: Programming Assignments are distinct from projects)
The purpose of the programming assignments is to make sure that you can use the tools needed for the programming projects.
Note: In all cases, we will provide you with a sample solution. It is actually acceptable to simply turn these in (providing you follow the rules on programming, especially involving documentation and attribution).
What we care about is that you work out the mechanics required to do the upcoming projects. You get the "check" for following the procedures, not necessarily for doing anything interesting.
Assignments turned in after the due date/time may be penalized. Assignments turned in after the TA has graded the assignment will not be counted.
Programming assignments and projects are to be handed in by placing them
in a specified directory. The exact name of this directory will be given
in the assignment, but it will generally have the form:
You must turn in all files required to build your program. This includes the source files, the header files, the visual studio project files, and the vis studio solution files. If you use some libraries other than the ones we provide, please make arrangements with us.
You are NOT to turn in executables. Just the source code (and the project files), documentation, and any extra things explicitly asked for in the assignment.
You must document your code. Everything you hand in should have a "readme.txt" file explaining what each file is. Every file should have a "head" comment explaining what's in it. If you use code written by others as part of your program, you must give proper attribution in both the readme file and the code files themselves.
If you do use code written by someone else (including the instructor or TA or web resource), you should be sure to give that person credit in both your readme file and mark the borrowed code clearly.
Do not work in the handin directory. Copy your files there once the program is working. (there won't be enough disk space for everyone to put all of their working files in the handin directory). You should only copy the following files into the directory:
In short, we need all the files necesary to build your program (and a readme file). We do not want the executable, the debugging information, the .obj files, ...
Also, you need to configure things so they will compile in the CS environment. If you build your programs at home or somewhere besides a CS machine, you will probably need to change your project settings.
Some Standards on Project Evaluation
It is MUCH more important to do the basic/required parts of the assignment correctly than to have bells and whistles. It is very depressing to give someone an F for failing to meet the basic requirements when they have written 5000 lines of code to make a spiffy user interface.
You must be able to use your program. Generally, the main part of grading projects will be a demo session where you drive your program to show us what it can do.
We will look at your code. Therefore, it is important that it is well documented. For example, we might check to see if we can find the place where you implement a certain operation.
A program that dies gracefully (prints an error message) is much better than one that crashes. Do everything you can to make sure your programs do not crash.
Your programs should be robust in the face of bogus inputs. Expect us to test this.
We encourage students to work above and beyond the minimum requirements. For example:
Extra credit does not directly affect your grade. You cannot score better than an "A" on any project or exam (or a "check" on an assignment). Doing something extra on one thing will not make up for a deficiency on another.
You should do extra work because you want to learn more and gain more experience with the topic. Not because it will help with your grade. We will (usually) note extra work and thank you for doing it (since it makes our lives more interesting).