Winter 2020
Syllabus and Course Website: https://facultyweb.cs.wwu.edu/~wehrwes/courses/csci480_20w
CRN (CSCI 480): 13422
CRN (CSCI 580): 13961
480: Overview of the hardware, software, and techniques used in computer graphics; raster display devices; input devices; display files, 2D and 3D transformations; windowing, clipping; simple surface rendering.
580: Three-dimensional concepts, shading techniques, curves and surfaces, ray tracing, radiosity, texture mapping, fractals.
This course will give an introduction to the fundamentals of computer graphics, with a focus on rendering techniques. At the core of computer graphics is the modeling and rendering of synthetic scenes. We will begin by discussing some basic data structures for modeling 3-dimensional objects, then spend the bulk of the middle of the course covering two fundamentally distinct approaches to rendering. Beginning with image-order rendering, we will investigate raycasting, raytracing, and touch on more advanced image-order rendering techniques such as path tracing. We will then move on to about object-order rendering, covering the basics of hardware-accelerated rendering using OpenGL and programmable shaders. Along the way, we will make heavy use of mathematics, in particular linear algebra, 3D geometry, and coordinate transformations. As time allows, we will delve into the details of the rasterization algorithms underlying OpenGL, as well as other topics that might include animation, spline curves, parametric surfaces, and global illumination.
On completion of this course students will be able to:
Grades will be calculated as a weighted average of scores on the following course components, each of which is described in more detail below:
Notice that the 580 components add up to 110%, which is fitting for graduate students. 580 students’ scores will be scaled by a factor of 10/11 to map them back into the 0-100% range before letter grades are assigned.
The standard letter grade ranges apply (i.e., 90–100% is an A, 80–90% is a B, and so on). The calculated raw percentages may be curved at the instructor’s discretion, but any such curve used will not lower anyone’s grade. “+” or “-” cutoffs will be decided at the instructor’s discretion. Students who demonstrate mastery of the material will get grades in the A range, and it is my goal to give as many A’s as possible.
Approximately 3 programming assignments will be given. The first assignment will be done alone, while the second and third will be done in pairs. You must work with a different partner for the two group assignments.
Approximately 3 short written homeworks will be assigned. The primary focus of these homeworks is to reinforce the mathematics underlying the concepts covered in class.
The midterm exam will be given during the week of February 10th. Further details will be announced at least one week before the exam.
In place of a final exam, students will complete a final project, which will provide a chance to explore and implement a special topic beyond the basics covered in the programming assignments. Final projects may either be a significant extension of one of the programming assignments, or a standalone implementation on a separate topic. You will submit a project proposal by Friday of the 6th week of class (2/14). A brief milestone progress report will be submitted partway through the project. The final project source code, results, and writeup are due the last Friday of classes (3/13). The final project will be done in groups of two or three.
Graduate students will work in teams to prepare and lead a class on an advanced topic of their choice during the 9th week of classes. Typically, the topic of this class will either be an overview of an active sub-area of graphics research, or a deep dive into some topic not covered in lecture. The topic may coincide or overlap with your final project topic, but is not required to. Topics will be proposed by the end of the 6th week of classes and finalized during the 7th week of classes.
The Schedule section of this page will be updated as the quarter progresses with topics, links to lecture slides, code examples, readings, and links to assignment and lab handouts. I suggest bookmarking this page; if you forget the URL and need to find your way back here, you can use link on the Syllabus page in Canvas.
We will use Canvas for announcements, grades, and submission of written homework. Programming and Homework Assignments will be linked from both the course webpage and the corresponding assignment on Canvas. Lecture notes and readings will be posted on the course webpage only.
We will use the online Q&A platform Piazza to ask and answer questions, make clarifications, and discuss supplemental topics outside of class time. You can access our Pizza page here or by logging into Piazza. You will receive an email in the first week of classes with information on how to log in.
It is your responsibility to make sure that you promptly become aware of Canvas Announcements as they are posted; Canvas should be configured to send you an email notification by default, but if you are unsure, please come see me in office hours.
Exams will be graded and returned to you via an online tool called Gradescope. You will receive an email when midterm grades are released inviting you to log into an account that has been created for you and set a password. Thereafter, you will access your graded exams by logging into your account on http://www.gradescope.com. If you have trouble accessing Gradescope after exam grades are released, please come talk to me in office hours.
This course assumes that you have basic familiarity with git. Programming assignments will be completed using git repositories hosted by GitHub and orchestrated by GitHub classroom. You will receive an invitation link to create a repository for each assignment, complete the assignment in a local copy of the repo, and submit by pushing your final changes to GitHub.
I take student feedback seriously. I appreciate any feedback you’re willing to give, and I will do my best to act on constructive feedback when possible. I will solicit feedback formally partway through the course, but you are welcome to provide feedback anytime in my office hours, by email, or if you desire anonymity you can use this Google Form.
This schedule is highly tentative and subject to change without notice. Slides/notes, assignments, readings, etc. will be posted here throughout the quarter.
Date | Topics | Assignments | Suggested Readings |
---|---|---|---|
1/7 | Introduction and logistics - what is graphics? slides |
1 - Introduction | |
1/8 | Triangle meshes - Geometry slides |
12.1 - Triangle Meshes | |
1/10 | Triangle meshes - Normals slides, notes, meshes |
Mesh out | 2.5 - Curves and Surfaces |
1/13 | ❄ Snow Day ❄ | ||
1/14 | Triangle meshes - textures slides notes worksheet demo files |
2.1- Sets and Mappings 11.1 - Looking Up Texture Values 11.2.2 - Interpolated Texture Coordinates 11.2.5 - Continuity and Seams |
|
1/15 | ❄ Snow Day ❄ | ||
1/17 | ❄ Snow Day ❄ | ||
1/20 | No class - MLK day | ||
1/21 | Ray tracing setup: images, cameras, rays slides, notes.md whiteboard |
3.1–3.3: Raster Images, Pixels, and Image Geometry 4.1–4.3 - Basic Raytracing, Perspective, Viewing Rays CGFS Common Concepts, Part I Intro |
|
1/22 | General Perspective Cameras slides, notes, whiteboard, handout |
Mesh due | 2.2 - Quadratic Equations 4.4.2 - Ray-Sphere intersection CGFS Basic ray |
1/24 | Ray-sphere intersection Lights and Shading slides, notes whiteboard |
Ray out |
4.5 - Shading CGFS Light |
1/27 | Blinn-Phong Shading slides, whiteboard, handout |
HW1 out | 4.7 - 4.8 - Shadows and Specular Reflection CGFS Shadows, Reflection |
1/28 | Shadows and Reflection slides |
||
1/29 | Barycentric coordinates Ray-triangle intersection slides, notes, whiteboard, handout |
2.7 - Triangles 4.4.2 - Ray-triangle intersection |
|
1/31 | Advanced Ray Tracing slides |
Chapter 13 - More Ray Tracing CGFS Beyond the Basics |
|
2/3 | 2D Linear Transformations slides, whiteboard, handout |
5 - Linear Algebra 6.1 - Linear Transformations |
|
2/4 | Affine Transformations Homogeneous Coordinates slides, whiteboard, handout |
6.3 - Affine Transformations | |
2/5 | Affine Composition Similarity Transformations 3D Transformations slides, whiteboard, handout |
6.2 - 3D Transformations | |
2/7 | Object order introduction Viewing Transformations 1 slides, notes, whiteboard |
Ray due | 7 - Viewing 8.2 - Before and After Rasterization |
2/10 | Viewing Transformations 2 slides, whiteboard, handout, demo |
7.1 - Viewing Transformations | |
2/11 | Perspective Viewing slides, whiteboard, handout |
HW2 out | 7.2 - Projective Transformations 7.3 - Perspective Projection |
2/12 | Hierarchical Transformations slides, whiteboard |
Artifact Voting open | 12.2: Scene Graphs |
2/14 | The Graphics Pipeline slides, demo |
Raster out | 8: Graphics Pipeline |
2/17 | No class (President’s Day) | ||
2/18 | GL and Shaders 1 slides, notes, GLSL, lab, code |
HW2 due | 17: Using Graphics Hardware |
2/19 | GL and Shaders 2 slides, demo |
||
2/21 | Rasterization slides, handout |
FP proposals due; midterm out | 8.1: Rasterization |
2/24 | Rasterization 2 slides, whiteboard, handout |
FP proposals back; midterm due | 8.1: Rasterization |
2/25 | Spline Curves slides, whiteboard |
15: Curves | |
2/26 | Rasterization Lab | ||
2/28 | No class | Raster due | |
3/2 | Raytracing: CSG and Dielectrics Richard O. and Ashima announcements, slides |
||
3/3 | Ambient Occlusion and Volume Rendering Max and Robert announcements, slides |
A primer on Bézier Curves | |
3/4 | Hardware-accelerated raytracing Jagi and Eric slides, bezier slides |
FP milestone due (Wed) | |
3/6 | Procedural textures and Perlin Noise for Terrain Generation Alex, Trevor, and Richard L. bezier slides |
||
3/9 | Environment Simulation, Waves Robin and Chloe waves, animation |
||
3/10 – 3/13 | No class | FP due (Fri) | |
Final Project Showcase |
It is expected that everyone will promote a friendly, supportive, and respectful environment in the classroom, labs, and project groups. Everyone’s participation will be equally welcomed and valued.
You have five “slip days” that you may use at your discretion to submit programming assignments or written homeworks late. Slip days cannot be used for the final project. You may use slip days one at a time or together - for example, you might submit each of five assignments one day late, or submit one assignment five days late. Each slip day moves the deadline by exactly 24 hours from the original deadline; if you go beyond this, you will need to use a second slip day, if available.
After your slip days are exhausted, a penalty of .1 * total_assignment_points * floor(hours_late/24 + 1) - that is, 10% of the total points per day late, will be applied.
To submit your work late, you must push your changes via git (as usual) then send me an email stating that you have submitted the assignment late. The timestamp of the email, which must be sent after your final changes are pushed to git, will be used as the submission time. It is your responsibility to keep track of your slip day balance - no exceptions will be made for accounting errors on your part.
Your programs will be graded on correctness, clarity, and efficiency (in that order).
A correct program is one that always produces the correct output for a given input. Also, a correct program does not produce unintended side-effects. The most effective way to ensure that your program is correct is to test, test, test. Test each component as you introduce it; once you are confident that a component works you can use it in other routines. Try to break your program in testing, and if you succeed, locate the bug and fix it. The better you test your program, the more likely it is to be correct - the more likely it is to be correct, the more likely you’ll earn a good score. Most of your grade will depend on the correctness of your code.
The easier it is to read and maintain your code, the easier it is to locate and remove bugs. Your program should be well organized, appropriately commented, and easy to maintain. To have a well-organized program, design your program thoughtfully and modularly. Think before you code: hacking away blindly leads to ugly, difficult-to-read code. If you do hack away, producing a functional but ugly wall of code, try to clean it up a bit. Make sure that your cleaning does not introduce new bugs.
As for comments, please follow these simple guidelines proposed by Emeritus Professor Osborne:
Your programs should be asymptotically efficient, e.g. checking graph reflexivity should be O(n), insertion into a balanced tree should be O(log n), etc. Do not optimize your code beyond the asymptotic level at the expense of clarity unless the benefits are substantial, and even then do so judiciously, and justify and document your optimizations in comments.
Individual programming assignments are to be completed independently. Students are welcome to discuss assignments with each other on a conceptual level, but each student should be writing their code independently and without direct help from fellow students. Sharing your code with others or looking at someone else’s code is an explicit violation of this collaboration policy. The best way to be absolutely sure you are collaborating appropriately is follow these two rules:
Automated tools will be used to check your code for plagiarism at the push of a button. They are not fooled by tricks such as changing variable naming and whitespace: in fact, hiding plagiarism is harder than doing the assignment.
All University-wide policies apply to this course, including those outlined at http://syllabi.wwu.edu. These policies cover issues including: