Kurt Akeley
Gates Computer Science Building, Room 364
kurt@graphics.stanford.edu
http://graphics.stanford.edu/~kurt
(650) 725-3728
Office hours: Tue/Thu after class (2:15 - 3:15 pm) and by appointment
Andrew Adams
Gates Computer Science Building, Room 376
abadams@stanford.edu
http://www.stanford.edu/~abadams
(650) 723-1604
Office hours: T 10:30-12:30, W 2-4, and by appointment, Gates 376
Justin Talbot
Gates Computer Science Building, Room 398
jtalbot@cs.stanford.edu
(650) 725-7784
Office hours: W 12-2, F 10-12, and by appointment, Gates 398
David Black
Office hours: F 4-6 in Gates B24B
Joint email address:cs248-aut0708-staff@lists.stanford.edu
TA office hours may be canceled on days the TAs are grading projects or exams, or performing other time-critical course-related administrative work. We'll send out email to the class emailing list whenever this happens, so check your email before visiting office hours.
Ada Glucksman
Gates Computer Science Building, Room 368
ada@graphics.stanford.edu
(650) 725-3724
Required: Foley, van Dam, Feiner, and Hughes,
Computer Graphics: Principles and Practice,
second edition in C, Addison-Wesley.
Click here for errata
Required: Shreiner, Woo, Neider, and Davis,
OpenGL Programming Guide,
sixth edition, Addison-Wesley.
(The fourth or fifth edition will suffice, if you already have that.)
Required: Möller and Haines,
Real-Time Rendering,
second edition, A K Peters, 2003.
Copies of all three texts are available in the textbook and general computer science sections of the campus bookstore. Readings from Foley, van Dam, Feiner, and Hughes will be assigned throughout the course. The OpenGL book will also be used throughout the course. The Real-Time Rendering book covers programming techniques you'll find useful when writing your video game, so it too will be used mainly toward the end of the course.
We will also read a number of papers from current journals and conference proceedings. These will be linked from the course schedule page.
CS 248 assumes no prior knowledge of computer graphics. However, most students taking 248 have had some exposure to graphical user interfaces and interaction techniques. Formally, we require CS 108 and Math 103. However, we do not enforce these prerequisites. More specifically, we assume programming experience in C (or C++) on a UNIX workstation, we assume you have written a largish program or two (at least several hundred lines long), and we assume a basic knowledge of calculus and linear algebra. An exposure to digital signal processing or Fourier analysis is useful, but it is not required.
In addition to regularly scheduled readings, the workload for this course consists of three programming projects, an evening midterm examination, and a final examination. The midterm will be on Monday, Oct. 29, from 7-9 pm in Gates B01. The final will be on Thursday, Dec. 13 from 7-10pm, at a place to be determined. SITN students must come to campus for both exams. Makeup exams will be offered only in extreme circumstances, and must be approved in advance. A makeup final exam will not be offered to students because they are taking conflicting classes, since doing so is prohibited by the registrar.
The first two projects teach you how to write low-level imaging and graphics primitives, while being fun at the same time. The last project asks you to implement a 3-D video game of your own design, in OpenGL. It will be impossible not to have fun on this project.
For all projects 1 and 3, you will demo your program to myself or a teaching assistant. Demos will be held in the graphics teaching lab, Gates Hall room B08, during university business hours. For project #3, you are permitted to work in teams. If you do, then all team members must be present at both demos. To keep the project #1 and #2 demos fair, you will also be required to submit your source code before midnight prior to the demo day and to give your demo from that code. We will describe in a later handout how code freezings and on-line submissions will be handled.
Evaluation criteria: Projects #1 and #2 will each count as 15% of your grade, project #3's proposal as 2%, first critique as 8%, and final demo and writeup as 20%. The midterm and final exams will each cover half of the material in the course, and will each count as 20%. Grading criteria on the projects will vary; typical criteria are correctness (40%), efficiency (20%), elegance (of your UI and your code) (20%), and originality (20%). Your workload and grade in the course will not depend on whether you are taking it for 3, 4, or 5 credits. Students taking the course P/NC must complete all assignments to receive a passing grade.
Collaboration: You may discuss the first two projects with friends, but you are expected to implement your own solutions. Sharing or looking at other students' code is not permitted. On the third project (the video game), you are permitted (and encouraged) to form teams of two or three people and to partition the work among the team members. The work expected from each team will be proportional to the size of the team. Teams may discuss their project with other teams, but each team is expected to implement the project independently. Sharing code or libraries between teams is not permitted. The exams must be individual efforts, as usual.
Borrowing code and data: As more programming resources become available online, we have found it necessary to tighten up the borrowing policies in this course, to ensure a level playing field for all students. In particular, using source code, libraries, executables, or data you find on the Internet (or elsewhere) is permitted only on the third project, and is limited to geometric models of characters or props (not environments), textures, sounds, and low-level programming tools (like matrix packages). In particular, borrowing code that implements required (or extra credit) game features is not allowed. We'll elaborate more on these restrictions in the handout for the third project. This said, looking on the Internet for ideas, even looking at sample code you find there, is permitted and encouraged on all projects. However, when you do this, we expect you to cite your sources in your writeup. We also expect that your video game was developed only for this course, and that it was begun no earlier than the start of this academic quarter. We want everyone to have a fair shot at the competition; if you have already been working on a game in your spare time, it would be unfair to the rest of the class.
The honor code: Every year, a few students in this class are caught sharing code or using code downloaded from the Internet. Aside from being unfair to your fellow students, these are violations of Stanford's Honor Code. In keeping with the Honor Code, we don't go looking for these violations, but they are relatively easy to detect, and when we find one, we prosecute it, and the penalties are real and severe. If you have any doubt about whether a form of collaboration or code borrowing is permitted, just ask us; we would be happy to ease your mind. Let's spend our time learning graphics, not policing each other.
Late projects: It is important that projects be completed on time. To allow for unforeseeable circumstances, you will be allowed one weekday of grace during the quarter for either a late demo or a late writeup. Beyond this, late demos or writeups will cause you to be penalized by 10% of your grade for that assignment per weekday that either is late. If both are late, you will only be penalized once, according to the maximum lateness among them. Late demos will be accommodated subject to the availability of the TAs. If the late demo slots for a particular day are full, you may be delayed another day, possibly incurring a penalty. On project #3, neither the demo nor the writeup may be late. Exceptions to these late policies will be made only in the case of a necessary (non-pleasure) trip approved in advance, or severe illness. If you do not submit one of the assignments at all, you will fail the course, even if you are taking it pass/fail. In this case, or if you believe you are in danger of failing, it is your responsibility to come talk to us before the end of the course. Incompletes are given only in exceptional circumstances.