edX Foundations of Computer Graphics postmortem

Last updated on 20 Dec 2012

I have recently finished the “Foundations of Computer Graphics” massively open online class (MOOC) offered by edX, and I had a lot of fun and learnt a lot about ray tracing. In the following post, I will highlight what I liked about the course, what I didn’t like about the course, and offer suggestions to anyone who does the course when the offer it next in March, 2013 or anytime later.

As you can see on the course website, it covers 4 major topics: required math, transformations, OpenGL and lighting and ray tracing.

Unit 1 – Math

The first topic was largely review for me, and will be for anyone who knows linear algebra, or has worked with computer graphics before. Vectors and their operations, matrices and their operations and coordinate frames were covered. The assigment here was to get your programming environment set up with their code framework. While I’m sure it was helpful for those new to programming, anyone who has worked with C++ before probably doesn’t need to worry about this homework.

Unit 2 – Transformations and Projection

Next, 2D and 3D transformations were covered, including 2D scaling, shearing, rotation and translation and 3D scaling, rotation and translation, as well as final transform matrix composition and orthographic and perspective projection.
This section was very useful to me, though the pace was fairly fast. I had to do a lot of self learning on this topic, including how to derive perspective projection and a few other theorems.
The homework for this class was to implement a number of 3D transforms and a perspective projection in the framework, which was pretty much plug and chug. It was useful from the perspective of interpreting mathematical formula in code, but it didn’t particularly tax me.

Unit 3 – OpenGL and Shading

Once we covered the theory, we started into practice. The next section was on OpenGL programming and computer graphics theory, such as the Gouraud, Phong and Blinn-Phong shading models. I preferred other sources on OpenGL syntax, as there are much better sources that go into more depth that I’ve linked to from my notes on the unit . Again, I had to do a fair bit of self learning on light scattering and the shading algorithms and how they were derived and what they mean.
The homework again was to insert code into their framework, this time shading code and some file reading and scene set up. Again, I didn’t feel I learnt much from this homework, as you don’t really get to write your own full stack. I didn’t have to hook up shader variables and buffer vertices, because all that was done. I just had to shade them.

Unit 4 – Ray tracing

Up to this point, I was feeling fairly disappointed. I have done some self study in graphics, but have never gotten around to implementing what I learnt. I thought this would be a great way to be forced to do some implementing, but up to this point, I was wrong.

Then we started learning about ray tracers. If the previous 3 units could be faulted for excessive hand holding, this unit definitely threw you into the deep end. In one unit, we covered ray tracing theory and tips to ray tracing implementation. The theory extended to generating rays from a camera definition, ray object intersection and recursion and reflectance. The tips on impementation were on how to calculate rays from a camera, a repetition of the intersection theory, impelemting shading and recursion.

The homework was to write a ray tracer from scratch, including a file parser, from just a handful of lectures and the code from the previous homeworks. The goal was to render a series of images, one of which had 50,000 vertices and took some over 24 hours to render. To say this was challenging was an understatement. However, this is also where I felt I learnt the most, and it’s the homework that I’m most satisfied with. This section alone makes the course worth taking, to me.

Tips

For those of you who will take this course, here are some tips when writing your ray tracer:

when checking if a point on a surface is in light, don’t forget to discard surface collisions that occur behind the light

inverting matrices is expensive. When you invert a matrix, cache the result. This will speed things up significantly

when casting a ray from the camera, find the nearest intersection. When casting for lighting, any intersection will do

use floats for everything. If you think something can be implemented with an integer, use a float anyway

clamp your lighting values, the shading equations can cause numbers out of range and will give you weird renders

implement some sort of acceleration structure. Rendering the Stanford Dragon is painful to debug when it takes 3-4 hours to render.