Will students use a low level API like OpenGL or DirextX, or is this completely CPU based?

Yes, why not use OpenGL?

fudgeracoon said:

@Gnollrunner Its a software rasterizer course, so CPU based yes.

It's questionable that will be more useful to learn than a GPU based API, given what your average student will likely do in the future. I mean I had to use Bresenham's algorithm in the ‘80s to do graphics on the very first PCs. However, these days it’s nearly useless for anything real.

Conversely learning a modern Graphics API would be beneficial to most. IMO learning how to write a higher-level API over the lower-level stuff is just as hard as the actual graphics. This is especially true with newer APIs such as Vulkan and DirectX 12 where there's a lot more resource management involved.

fudgeracoon said:

The course will include the following goals and outcomes:

…

This knowledge will empower them to pursue careers in game development, animation, visual effects, virtual reality, and various other industries where computer graphics expertise is highly sought after.

I am not really sure how useful that is in 2023.

The bullet points seem like it covers what was taught in the mid-1990. The theory and concepts are important to understand, but what you described is not what a person would use today.

I would not agree that the list would “empower them to pursue careers” from the list. Shaders, RenderDoc, and systems like Unreal's Nanite implementation would be more in line with the jobs listed for “computer graphics expertise”.

One thing that seems to be missing is any discussion of ray tracing algorithms. For instance, you could have the students implement a simple Whitted ray tracer or possibly a path tracer. This could also include discussion of acceleration structures and BVH, which is good general knowledge to have.

With regards to lighting/shading, I'd like to see specific focus on modern PBR shading instead of the old style Phong shading.

An introduction to basic image processing could be useful information as well (convolution, filters, separable blurs, tone mapping). This would probably be part of your post processing section.

The part about “Creating essential utility libraries” seems not that useful to me unless this is a game engine course. You should provide those libraries to students so that they can focus on graphics. I wouldn't spend more than 1 lecture on this topic.

For comparison, in my graphics class (graduate level) circa 2008, we did the following class projects (using GLUT library for window/input management):

• Software scan line rasterization for polygons
• Add Z buffering and model loading to previous project
• Add transformations and shading to previous project (result is software rasterizer)
• Whitted ray tracer with spheres and reflections
• Final project of students choice, subject to approval. I did a soft-body physics simulation, other people did path tracers.

While I agree with other people here that GPU-based graphics is more relevant today, I also understand that a course must be designed to be accessible and to fit within a limited amount of time. The field of graphics is simply too big to give a complete introduction in a 1 semester course.

Furthermore, unless you provide students a large amount of code infrastructure, or some existing game engine or library, they will be likely to not get anywhere in the time available, since it can take months for novices to write the infrastructure code necessary to display a mesh with textures on screen. This is especially a concern for modern GPU-based stuff using shaders, it's not as simple to get started as with old OpenGL 1.4. Hence, CPU code may be the right choice for an introductory survey course because the barrier to entry is lower, all you need is a way to write out an image (24-bit TGA is easy) or display it on screen. You can still give a few lectures introduction to GPU programming, but I'd personally keep any programming projects on CPU.