Lab Guidelines

Labs

Each new lab assignment will add features to the previous lab.
You must get the central functionality of the ray tracer working in order for it to be viable for later labs - so it is especially important that you code your intial lab in an organized manner.
If you can't get some basic functionality working for a lab and you lose points for it and if you don't get that functionality working for subsequent labs, you will lose points again if the subsequent labs require that functionality.
If you can't get special feature functionality working correctly you will not lose points for it on subsequent labs if the requirements for the subsequent labs do not build on top of that.
The total weight for all lab grades will be 50%.
The number of labs is yet to be determined. There will probably be around 6 labs depending on how finely I break up the incremental development.
What the final lab will look like is pretty set and will include various lighting, shading, and modeling capabilities.

Equipment and Programming Environment

The labs should be written in C or C++. Other languages are possible if and only if the grader approves it.

The official equipment for the course consists of the lab workstations. All programs should be tested on the Sun workstations since they will be evaluated on those machines. Of course, you can develop the code on whatever platform you want to use.

Output from your programs should be an image in ppm (portable pixmap) format. Images are displayed using standard display routines such as gqview or ImageMagick's display.

Grading Criteria

Grading of the labs will be based on the following:

80%: Correctness and adherence to assignment specification. This includes any error checking specified in the lab handout. If no error checking is specified, then you don't have to do it.
10%: Readability and structure of code, use of comments, indentation, etc.
5%: Efficiency and speed (only an issue if its very inefficient)
5%: Adherence to lab procedures (submitting, naming conventions, etc.)

The grader will grade the labs. If you have a problem with the grade you received on your lab, see the grader first. If you can't resolve the dispute with the grader, then see me. However, in order to maintain consistent grading for everyone in the class, I am not very inclined to alter grades that are assigned by the grader.

Late Penalties

There is a 10% per day late penalty for every day the labs are open, up to a maximum of 50%. After that, you get zero. Late penalties are imposed precisely at midnight. I don't give extensions to individuals unless its an extreme case of a proven emergency.

You have more than enough time to do the labs, especially if you start on them right away. If you wait and run out of time, even if there is a small delay in electronic submission, it's your problem. Plan ahead.

I will only consider system delays if the Departmental Computing Staff concurs that there was a significant system problem that caused a significant delay in electronic submission.

I give extensions to the class in case of general equipment failure or other, universal, uncontrollable, devastating circumstances.

Copying Labs

Don't. Discussion of lab assignments is allowed and encouraged. However, do your own work. Labs which are too similar will be handed over to the Committee on Academic Misconduct and handled by them.

Lab Submission

For each lab, submit the source code and makefile that will create the executable (see below for information about 'makefile' if you are not familiar with it). For some of the labs, you will be required to submit one or more sample scene files.
You are to submit lab assignments electronically . For each lab, submit the makefile and all necessary source files. Do not submit the executable. Name the executable lab1, lab2, etc. See the man page on 'submit' if you haven't used it before. The name of the class to use in the submit command changes from quarter to quarter, so check to see what the submission name is for this quarter either on the course newsgroup or class web page.
A sample submission for course cis681 would look like:
submit c681aa lab2 main.c subroutine.c routines_681.h makefile
Or, if all of the files are in a subdirectory called 'lab2DIR', then:
submit c681aa lab2 lab2Dir
In any case, you should create and submit the files so that, once the grader is in the directory to which your files were submitted, the grader can execute your program (for example, lab2) by doing the following:
make
lab2

Makefile

Here is a simple tutorial on makefiles
As an example, here is a makefile that I've used

Suggestions

Don't get behind in the lab assignments.
Probably the biggest reason that some students do poorly in this course is getting behind in the labs and never recovering. Be forewarned, some labs depend partially on previous labs.
Design and implement in a top-down, modular fashion.
Use incremental development of the labs. Get something working that has the skeleton structure of what you need and then add features to it. Each time you add a feature, test it and make sure everything is still working. It can be tough to debug graphics programs if all you know is that the output is wrong and you're not sure any one module is working.
To debug a problem in an image, create the simplest possible scene that still has the problem - including reducing the resolution, eliminating display effects, reducing the number of objects, and simplifying the viewing parameters. The use a debugger or print statements to identify problem variable values.

Last Lab CANNOT be Handed in Late

The last lab CANNOT be handed in late!

Last updated 9/23/09