• View
• History
• Print

Main / Policies

1.  Collaboration

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.

1. If you are unsure if something is collaboration or academic misconduct, please ask the instructor or TA for clarification.
2. No collaboration is allowed on the exams, or assignments where it is explicitly prohibited.
3. Ultimately, each student is responsible for the material. Projects and exams will require you to understand the assignments, so be careful not to rely on help since at some point you might need to do it your self.
4. Collaboration must be a two way street. The person giving help must OK it. (e.g. don't look at someone else's work without their permission).
5. It is not OK to broadcast help. Its OK to answer someone who asks for a hint, but its not OK to post a hint to a mailing list. If you have something that you would like to offer to the class, please send it to the instructor.
6. Every student must turn in their own assignment, and is responsible for it. For group projects, specific instructions will be given (generally it is turned in once, and other group members give pointers).
7. Projects must be "substantially" written by the student handing it in. In particular, the "meat" of the project must be completed by the student handing in the project.
8. Any code that you didn't write must be given proper attribution. If you grab a piece of code from the web (including the class sample code!), another student, some book, ... - YOU MUST SAY SO! It is OK to use pieces of sample code - providing that you give proper credit to the author.
9. We will give you large amounts of example code to work with for various assignments and projects. Be sure to give it proper attribution.

So...

• It is OK to ask a classmate for help on one of the questions on a written assignment. It is not OK to "borrow" their assignment and copy it without their permission. It is not OK to just copy it without understanding it (since you won't learn the material).
• It is OK to ask a classmate for help looking over your code to find a bug. It is not OK to use a piece of their code without giving them proper attribution, or if its an important part of a project.
• It is OK to use the provided example code, or a data structure implementation you find on the web PROVIDED THAT YOU GIVE PROPER ATTRIBUTION. It is not OK to use a piece of code on the web for a central piece of an assignment (like a required image processing routine)

2.  Computing Policies

This class has been assigned to the "Storm" laboratory in 1366 Computer Sciences, and the "Starsky&Hutch" laboratory in 1358 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:

1. Your code must build and run on the CSL machines. As far as we are concerned, if it doesn't compile and run on a Storm or Starsky&Hutch machine, it doesn't run.
2. Working in the lab can be a good collaborative experience, and we encourage this kind of collaboration.

Your programs must be written in C++ (since C is a proper subset of C++, that's OK too). For some thoughts on C++, see the C++ for 559 page.

The compiler provided by the CSL for the storm labs is Microsoft Visual Studio .NET 2008. The department has a site license for Visual Studio that allows you to install it on your home machine/laptops. Contact the TA to borrow the disks. You can also download Visual Studio through one of the Microsoft things for students (Dreamspark or MSDNAA) - just be prepared for a large download.

Note: that if you choose to develop your software using another compiler (or on a different machine), you still need to be able to compile your code in the storm labs. We cannot provide any help to you if you choose to use other tools.

We cannot support the sample code on machines other than Windows.

To reiterate: if your program doesn't compile/run on the computers in 1358/1366 using Visual Studio 2008, as far as we're concerned, it doesn't compile/run.

3.  Late Policies

To keep things simple, everything is due on Wednesday, central time. Wednesday means Wednesday. Wednesday night is Wednesday, Thursday morning is not.

In general, if its Wednesday, there's something due. Even if its the midterm exam.

There is some leniency in the late policy depending on what the assignment/project is. Details will be given with the assignment.

4.  Assignments

Assignments are things we ask you to turn in that are not projects. Assignments include surveys, written homeworks, and smaller "practice" programs.

Late assignments may be handed in. The TA may accept them at their 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), and will not be accepted after the answers are posted. Late assignments will be noted and will be penalized. It is better to turn in a late assignment than to not turn in anything.

Some assignments may only be graded on a "check/no check" basis. In these cases, we might not give individual feedback to the student (other to acknowledge that they got the check).

A portion of the exam may be taken from the written assignments. The problems may not be exactly the same (e.g. some of the numbers may be changed).

Some assignments are counted as part of a project. For example, there may be a practice programming assignment to help you get ready for it, or a written assignment after it. These assignments will affect your project grade.

5.  Projects

Details of programming projects will be given when they are assigned.

Projects are always due on Wednesdays (with the possible exception of the final project). 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 three parts: the related assignments, a demo (either in person or the TA running your program), and a grader's "reading" of the code.

Late projects will be accepted for a penalty. Projects will not be accepted after the scheduled demos (or grading) begins. Late projects will be considered either "late" (handed in after 11:59pm Wednesday, but before Saturday (note: to be consistent turning things in on Friday means turning things in on Friday -e.g. before 11:59pm after which it is Saturday) or "very late" (handed in after Friday, but before we begin to grade, which will be announced. Generally, grading begins with the first demos. Note: the first demos might be scheduled such that very late projects will not be accepted.

Note: in 2009, the end of the semester falls mid-week which might cause wierdnesses with the final project scheduling as the University has rules about projects due after class ends.

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.

Students are responsible for coming to their demo appointments. If you cannot make your appointment, make an arrangement before the day of the demo. Students who simply do not show up for the demos will be penalized.

For some projects, there will be "project checkpoints" where you are asked to show that you are making progress on a project (and not waiting until the last minute to start). These will generally be graded check/no check, and won't directly affect your grade: however, in the event that you don't make the checkpoint, don't expect the benefit of the doubt when we grade your project: if your project isn't good, we'll assume that you started late and didn't devote enough time to it.

5.1  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.

6.  Turning in Programs

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:

  p:/course/cs559-gleicher/handin/yourid/a1 

where "yourid" is your CS login id, and "a1" is the name of the assignment (a1 = programming assignment 1, p2 = project 2). If your directory does not exist, or if the permissions are set incorrectly (such that either you cannot write files in it), please contact the TA.

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 should not turn in "object" files (compiler outputs), debugger data files, library files, etc. We may remove these if you submit it. We may penalize you if you do it more than once.

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:

• the C++ source and header files
• the fluid source files (.fl) if you use fluid (if you don't know what fluid is, don't worry)
• your Visual Studio solution file
• your Visual Studio project file
• any other source files (for example, if you use MFC you would have resource files, or if you used fluid, you would have an ".fl")
• a readme.txt file that explains what your program is, what it does, how to build it, how to use it, what pieces you "borrowed," what each of the files is, ...

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.

7.  Extra Credit

We encourage students to work above and beyond the minimum requirements. For example:

• We may give extra readings beyond the standard course material. (This material will NOT be tested on the exams).
• You may submit a programming assignment that does something cool.
• You may add additional features to your projects, or do more parts of the project than required.
• You may participate as a subject in a graphics group research experiment.

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).