A Note to Readers
Aug 4, 2026 • 4minThis handbook is written primarily to document my own learning. I have found it really helpful to document some of what I learn publicly, as it helps me stay focused on my work. Teaching myself this way also keeps my learning well documented for future reference.
You may find it useful, but it is not intended to be as beginner-friendly, polished, or descriptive as a conventional tutorial or blog. Some sections may assume prior context or omit detailed explanations. I may completely skip sections from LearnOpenGL that I’ve already completed multiple times and no longer feel the need to document or explain to myself. In such cases you can refer to my source code to understand how something was done or read the original LearnOpenGL course for a more detailed explanation.
My goal here is to teach myself how to render beautiful images on screen using GPUs. This handbook will be focused on LearnOpenGL, but for a better visual understanding of the underlying concepts, you can also explore introductory courses by Cem Yuksel or Justin Solomon.
I will link to my source code, so if you do not understand something from my notes, looking at the code might help.
This handbook is entirely focused on completing the LearnOpenGL course as simply as possible, without unnecessary complexities such as:
- Engine architecture and design
- It’s a giant rabbit hole that helped me learn a lot of Rust, but I completely lost sight of my original goal: learning how to render.
- I am working on my render engine, whose progress I will track here: https://willofindie.com/proj/sponza-experiment
- The latest and greatest rendering techniques, like Indirect Rendering and other techniques I was learning from the 3D Graphics Rendering Cookbook
- Cross-platform builds. Everything will be native only, with no WebAssembly builds, which removes the complexity of asynchronous programming in Rust. To learn how to generate WebAssembly builds, you can refer to https://sotrh.github.io/
- No parallelism, because
wasmbuilds don’t support it anyway. - And a lot more things that I don’t know about.
Please note that I am not an avid writer or teacher, and taking notes or writing blogs really bores me. However, I have realized that documenting the things you struggle with—as if you were teaching them to yourself and using yourself as a rubber duck—helps a lot.
That is exactly what these notes are. They are primarily meant to help me understand complex topics that I often forget or find difficult to grasp. This approach helped me when I wrote my blog post on the Infinite Grid Shader, so I am repeating the same process to keep myself focused and on track.
If you do not find these notes helpful, I suggest learning from the following resources:
These resources, along with many other blogs directly or indirectly related to graphics programming, have helped me reach this point.
We will not use WGSL for our shader language. I have worked with it, and it’s fine, but I find
GLSLto be more user-friendly. Also,GLSLis widely supported, examples are easier to find online, and my custom render engine that I’m working on is tightly coupled withGLSL.There are a few limitations to using
GLSL, though, one of them being that it may generate incompatibleWGSLcode if not written properly. For example,WGSLis a strict shader language andGLSLis loosely typed, so we must ensure that we type-cast our values in some places whereWGSLmight throw an error. Again, it will immediately be caught at runtime, so it’s not that worrisome. Also, GLSL gets compiled toWGSLwhen working on the web, but I don’t think that’s a huge issue. Yeah, it might increase the initial pipeline loading times, but the runtime (once the shader is compiled) remains the same.We will stick with
GLSL->v4.5as it works just fine withwGPU.
WebGPUdoes not support Geometry, Tessellation and many other shader stages, so do keep that in mind when trying to copy code from online that uses these shader stages.