A graphics programmer's syllabus: path tracing first, PBR next, minimal math

Alan Wolfe, who blogs as demofox, argues you can become a graphics programmer with only linear algebra, basic trig and a little calculus, and that the fastest on-ramp is writing a path tracer before you ever touch a real-time API.

In brief

Wolfe splits rendering into two jobs: driving explicit APIs like DirectX 12, Vulkan or Metal, and working the math of lighting on the GPU. His first suggested project is a path tracer via 'Ray Tracing in One Weekend,' before any real-time API.

He insists linear algebra, basic trig and a little calculus are all you need.

Commenters disagree: one whose college major was computer graphics called that math coverage far too thin, while a 25-year veteran said he would not enter the field today at all.

Two jobs in one, and a path tracer to start

Physically based rendering output from the post
Physically based rendering output from the post

Alan Wolfe, who blogs as demofox, frames modern rendering as two jobs in one. On the CPU side you drive an explicit API such as DirectX 12, Vulkan or Metal; on the GPU side you work the mathematics of lighting and shading and the techniques built on it, like shadows and ambient occlusion.

His counterintuitive advice is to start offline, not real-time. Write a path tracer first, using the free "Ray Tracing in One Weekend," so you understand how film-quality rendering works before you spend years approximating it at interactive speeds. From there, move into physically based rendering: LearnOpenGL's PBR theory, then Google's Filament documentation, then the free PBRT book.

Physically based rendering comparison from the post
Physically based rendering comparison from the post

On prerequisites he is reassuring: linear algebra, basic trigonometry and a little calculus cover what you actually need. The working language is C++, shaders are HLSL or GLSL, and beginners can warm up on OpenGL, WebGL or DirectX 11 before the explicit APIs. The portfolio he suggests is concrete: a real-time renderer with asset loading and PBR lighting, plus a path tracer that outputs a PNG.

Add the math, or don't bother at all

The thread split cleanly between people extending the syllabus and people questioning the destination. A working graphics programmer added the resources he leaned on:

"The most useful resources I've found for graphics are scratchapixel, UC Davis' graphics lectures, songho's articles, and Essential Math for Games and Interactive Applications."

The reassurance about math got direct pushback from someone whose college focus was computer graphics:

"There is not enough focus about the math in this article … Linear Algebra is huge!"

John Nagle reframed the question entirely, warning would-be engine builders about scope:

"If you want to make games, use an existing engine. … Building a game engine takes about two years to get to the My First Renderer point."

The bluntest note came from a graphics programmer since 2001, who has watched Nvidia move to real-time AI-driven effects and no longer sees room for a lone virtuoso:

"Today, I would not recommend anybody to go into graphics programming"

His worry names its own antagonist, asking where a new John Carmack could even come from when the ground shifts this fast.

Get breakdowns like this every day

The top Hacker News stories, unpacked — by email, Telegram, or RSS.

Next story · 18 of 24 Read more
🚀Tech

FFmpeg 9.1 ships a new AAC encoder, tuned by ear and CBR-only

FFmpeg 9.1 landed a brand-new native AAC encoder, hand-tuned by its author's own ears, that aims to retire the fdk-aac and Apple Core Audio encoders people have leaned on for years. It comes with two loud asterisks: it is CBR-only and built for 48kHz.

★ 300 · 💬 101 · hydrogenaudio.org · 2 min