CS 348C Requirements

Students may take CS 348C for either 1 unit, in which case the only grading option available is CR/NC, or for 3 units, in which case the student may opt for either letter grading or CR/NC.

• Students taking the class for 1 unit make one in-class presentation (60%). They also attend all student presentations and participate in class discussions (40%). While the only grading option allowed by the coordinator is CR/NC, AXESS will still permit the students to sign up for letter grading: the students are required to select, and must remember to select, CR/NC when signing up for the class.
• Students taking the class for 3 units (for either grading option) make one in-class presentation (30%), and complete three short assignments (10% each), and a programming project (35%). They also attend all student presentations and participate in class discussions (5%).

• The speakers use overheads or slides summarizing or elucidating relevant concepts. These overheads or slides should not contain too much text in "microfont"; instead, they should concisely highlight important points or graphically illustrate fundamental techniques.
• The presentation should convey the intuition behind the formalisms presented in the papers. It should not focus on listing equations and algorithms copied verbatim from the paper: the audience can read the paper to learn these technical details. To this end, it might be necessary for the speakers to research prior work on the same topic as the assigned papers.
• The speakers are encouraged to contact the authors of the relevant papers (see the hyperlinks of the topics list for author contact information), and learn "inside information" related to the research: when does the algorithm fail? did you time it on a CRAY? how did you come up with this equation? Also, authors might provide animations, video clips, or software illustrating their work. Some authors even provide such information on their WWW home pages!
• The speakers should time their talk and make sure that it does not exceed 1 hour and 5 minutes. After the end of the talk, the speakers are expected to answer questions posed by the rest of the class. If no questions are posed, the speakers are expected to guide a class discussion on the papers presented; such discussions may raise concerns of viability or commerciability of the proposed approaches, suggest potential improvements, etc. These discussions are the usual birthplace of ideas for programming projects!

Topics are assigned to students on the basis of their preferences, as stated in their registration form. The coordinator processes these forms and assigns topics to students. Assignments of topics to particular dates in the course schedule are randomly made; swaps are allowed if all students concerned agree. These assignments are subject to change as students drop the class.

Collaboration:

Students are encouraged to discuss their presentations with everybody else in the class, including the coordinator; however, each topic should be presented only by the assigned students.

Deadlines:

Please consult the course schedule.

Evaluation criteria:

In order of importance: clarity of exposition, depth of understanding, quality of visual aids.

1. Site notation, barycentric and homogenous coordinates, maps, and parametric polynomial curves.
2. Polynomial specification, polar forms, parametric continuity, and B-spline curve drawing.
3. SoftImage 3D training and critique, degree-raising and merging rational curves, subdividing rational patches.

Format of written assignments:

Typed work is preferred, but neatly hand-written work is fine, too. Sloppy, illegible work is not graded.

Collaboration:

Students may discuss the assignments with other students, but each person is expected to implement/design/solve/write up their assignments individually.

Deadlines:

Please consult the course schedule.

Late assignments:

Late work is not accepted without prior approval by the coordinator.

Platforms:

Programming assignments have to compile and execute on Silicon Graphics workstations. C and C++ are the only allowed languages.

Evaluation criteria:

In order of importance: correctness, efficiency, and elegance of user interface.

Acceptable projects include but are not limited to implementation (and/or improvement and/or customization) of an algorithm from a recent paper related to geometric modeling or modeling of natural phenomena and processes. Or, the students may synthesize techniques from several papers into a useful tool.

For the development of their projects, students are given access to the teaching laboratory in Sweet Hall and the computer graphics laboratory in CIS. The first lab is open to all Stanford students, but students of graphics classes, including CS 348C, have priority over everybody else: CS 348C students should feel free to ask students of non-graphics classes to relinquish their machines. The second lab has a Silicon Graphics Onyx RealityEngine/2 which students may use; however, paid researchers have priority over the students of the class concerning use of all the CIS laboratory equipment. Follow the on-line instructions to obtain accounts for use in the CIS laboratory, as well as information on gaining physical access to the laboratory after hours; students of this class should seek the authorization of Marc Levoy for after hours access to the CIS building. Finally, to obtain an account on the 32-processor DASH machine, contact Dave Nakahira in CIS 128.

Students are encouraged to use the class software in any or all steps of their project work. Here is a sample list of possible uses:

• Students may use the provided particle system simulator to test whether a natural phenomenon may be adequately modeled using a particle system. Such preliminary tests may invalidate partile systems as a modeling method for the natural phenomenon under investigation; or, they may give rise to a project which incorporates the implementation of an advanced, custom-made particle system simulator, tailored to the natural phenomenon.
• Students may use the provided modeler to generate or animate elements which can be subsequently incorporated in the renderings. These renderings, in turn, may be generated using the provided ray tracer.
• The students may film some of the elements of their renderings, and use the digitizer in the CIS laboratory, as well as the provided compositing utilities, to merge the output of their code and the filmed backdrop.
• Students who wish to render animations, are encouraged to transfer their work on videotape using the Abekas system in the CIS laboratory. Doing so will allow them to present their work to a large audience, in contrast to low-quality, small in size, MPEG animations, displayed on a crowded workstation screen.

Students may seek advice on their projects from other students, the coordinator, as well as outside sources, such as the staff of Pacific Data Images: contact Apurva Shah (R & D staff), Shawn Neely (R & D staff), Gilles Dezeustre (R & D staff), or Terence M. Emmons (Senior Animator).

The projects are completed in the following steps:

1. Coordinator and team hold a one-on-one meeting during which the students present orally a preliminary form of their project proposal. All teams have to sign up for these meetings.
2. A written project proposal is due approximately a week after this meeting.
3. Coordinator and team hold a one-on-one meeting during which the students present orally a project progress report. All teams have to sign up for these meetings. Prior to this meeting, the team should have finalized the concrete goal of the project, as well as the software/algorithm analysis. Also, the implementation should be half completed, and the students should be able to present in full a definite timeline of all remaining work on the project.
4. The students present their project to the rest of the class, in a format adhering to the suggested guidelines. The project presentations are also to the public.
5. A project writeup, due approximately two days after the public presentation, documents all aspects of the project.

Collaboration:

Teams are encouraged to discuss their projects with other teams, but each team implements their project independently; in particular, student code may not be shared between teams.

Deadlines:

Please consult the course schedule.

Late proposals, presentations, or writeups:

Late work is not accepted without prior approval by the coordinator.

Platforms:

Any platform is acceptable.

Evaluation criteria:

In order of importance: correctness, originality, quality of presentation, efficiency, and elegance of user interface.