IS-2780 Intaractive Graphics

Wed 6:00-9:10 PM - IS Ground Floor COnference Room

May 14 to July 30, 2008

Instructors: Art Wetzel and Jeff Pferdehirt

Office Hours: by appointment - we try to answer email within ~12 hours
Art's Class Web page: http://www.psc.edu/~awetzel/is2780.html
Art's Email: awetzel@psc.edu
Art's Phone: 412-268-3912
Art's Office: Room 419 (PSC/CMU) 300 South Craig
Jeff's Class Web page: http://www.sis.pitt.edu/~jeffreyp/is2780/index.html
Jeff's Email: jrp13@pitt.edu
Jeff's Phone: 412-624-9410
Jeff's Office: IS Building, Room 707

Required Text

Jeffrey McConnell, Computer Graphics: Theory Into Practice ISBN-10: 0763722502, Jones and Bartlett Publishers 2006
Additional papers and handouts from class will be considered as required reading.

Grading:

Two Exams 15% each
Assignments 50% total
Term Project 20% total

Prerequisites:

For this course we assume college level math skills and some previous programming experience. Ideally everyone would know C/C++ and have a working knowledge of their computing platform.

Goals:

The primary goal of this course is to provide an overview of the theory and practice of computer graphics. Particular attention will be paid to those concepts which have broad applicability, have maintained their importance over a significant period of time, and are expected to maintain their importance into the future. We will use C/C++ as our programming language in conjunction with OpenGL as a standard and widely available graphics API.

Course Content:

The course consists primarily of two components

(1) General theory/principles
(2) Implemetation methods

We will not follow the order of presentation from the book in all cases but will try to choose the most appropriate sections for your reading and to supplement the programming assignments. By the end of the term we should have covered about 2/3rds of the book, having skipped some of the specialized areas. This means we'll try to have an average pace of one chapter per week!

There will be a strong interplay between theory and practice and a variety of presentation levels so that no one should become either lost or bored provided they do the readings and other work outside of class time. Special programming and math skills will be reviewed as needed.

General Class Issues:

All students must have a suitable graphical programming environment before the 2nd week of class. You should also check your email and the class web pages regularly to let us to field your questions and to provide clarification and corrections to class and assignment issues.

There will generally be a programming assignment every week except for the week of an exam. At the end of the term we will drop your lowest assignment score and average the others. This is indended to cover the sick days, travel and other circumstances. If you miss a week please DO NOT ask for a makup assignment as that is to be covered by the dropped score. The only exceptions would be due to extended illness or similar special emergency.

Assignments, template programs, test files etc will be available on the class web pages. This is also where you should pick up information if you miss a class.

Unless we tell you otherwise, all assignment programs should emailed to "awetzel@psc.edu" with the Subject line "IS2780 Final assignment #N" where the N changes weekly from 1, 2, 3 etc. Also, make sure that the first line of your program includes a comment with your name and email address. All assignments must be received in ON TIME in order to obtain a nonzero score since we will hand out solutions for class discussion on the due date! Be sure to turn in what ever you have even if its not working to get reasonable partial credit. Make sure that all programs are in a form that we can recompile and run. If an assignment asks for some particular computed results or written conclusions then please put that into your program source as a block comment. Sent your program as an attachment or as plain text. *** NOT html and do NOT send your compiled binaries ***

Students are encouraged to cooperate in discussing solution strategies and in helping each other with mechanical aspects of editing and programming. However, each student's work should be uniquely their own. NO SOURCE CODES should be duplicated between students! Other that the templates we provide everything you program or write must pass through your own fingertips!

Readings from the texts will be supplemented by additional handouts which cover specific topics not included in the book. For the purpose of exams, all handouts are considered as required reading. The general philosophy of the lectures is based on the fact that you all have the books and can read them. Therefore, the lectures will not always repeat the same material. Usually the lectures/class discussions will provide clarifications/extensions to material in the texts, present alternative views to the texts or cover material which is not in the texts at all.

Policies:
Attendance is your responsibility. If you must miss class, get all handouts and assignments from other students or the class web page or email as soon as you can. Due dates will not be modified except in cases of medical or employment urgency. Get notes from another student.

Tests:
Each exam will primarily cover lectures, readings, and assignments from weeks not covered on the previous exam. Unless stated explicitly otherwise, all material is eligible for testing. Makeup exams will only be given under emergency circumstances. If you know ahead of time that you must be away on the night of an exam, then you should arrange to take the exam early.

Academic Honesty:
It is okay to discuss problems and solutions with others. It is not okay to show someone your program, to copy someone elses work, or to copy solutions directly from other textbooks or materials. All work must pass through your own fingertips!!!

Program Grading:
Grading on programs will be on a 10 point scale based upon the following factors:
  • Solution - Does the program solve the problem presented, using the required tools, and does it run?
  • Correctness - Test normal circumstances, then test for extreme examples - in other words, don't show us just that it works, show that it handles the expected range of possible inputs. (Normally I will provide a set of test cases.)
  • Efficiency - Is your program performing unnecessary operations or using poor implementation methods.