The one and only Holy Bible of Graphics Programming. If you're starting to learn computer graphics, just study through the entire site and do the examples one by one. It doesn't matter one bit that it uses a slightly outdated API called OpenGL - you're supposed to learn how to render things first, not about some weird obscure hardware / driver details!
After you've learned it, you can start learning CUDA if you want to do some more low-level compute stuff on the GPU (sorry, but you should just buy an NVIDIA card, CUDA is just that good). Or if you actually want to just make things but want to use a nicer cross-platform graphics API than OpenGL, then I recommend SDL3. (Or use Metal if you want to make macOS exclusive apps - it's actually a quite nice API)
Vulkan or DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware anymore. (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api). However if you want a computer graphics career (either in the game industry or in other niche domains) having experience with these APIs will be beneficial since these are what many production apps are currently stuck with - though honestly the job market for graphics really suck nowadays. (The biggest sector was triple-A game companies with their own engines, but the game industry is imploding right now...)
If you want to use the learned knowledge I would recommend to use something like Sokol [0] or use the SDL-GPU API [1]. While Sokol is more higher level both can be used. Otherwise learn opengl is a really good introduction.
In 2026: Please don't learn this; it's obsolete. Learn Vulkan (Or another modern API; or how to build engines on top of them; or how to write shaders; or how to do GPU compute using CUDA etc)
Im the author of vkguide.dev and i disagree. I wrote that tutorial specifically for people that have already gone through learnopengl and want to learn vulkan.
The core problem with the modern apis is that they are so incredibly complicated that they will kill any newbie on the spot. When the student still doesnt really know what a mesh is, having them setup GPU side memory allocators and graphics compute pipelines is absurd.
Opengl meanwhile is significantly easier, and will give them the important terminology and math required to do graphics. Once the student has learned opengl and wrote a small renderer with a few basic techniques, moving to vulkan or DX12 will happen far more smoothly.
In particular, learnopengl explains a lot of basics like transformation coordinates, what a mesh is, and other similar "basic knowledge", while all vulkan and dx12 tutorials skip through that because they are meant for a much more experienced audience.
I do agree Vulkan is too cumbersome, but OpenGL is definitely obsolete.
The OpenGL API with its binding-based approach is also very confusing for beginners, but the replacement Direct State Access API came too late (after Apple already decided they would deprecate OpenGL, so it never got supported on macOS).
And the fact that the GLSL parser and compiler are part of the driver means there are tons of hardware-specific bugs and miscompilations. Intel integrated drivers on Windows are notorious for being especially buggy.
All of those make OpenGL a pretty poor target for learning. Personally, I would recommend WebGPU to people who want to get into graphics programming. It's very similar to DirectX/Metal, and like a more streamlined Vulkan. The WGPU implementation of WebGPU has a C API, which also has C++ headers, and a native Rust API. And you can also use WebGPU in your browser from JavaScript, if you don't know any native languages.
What is the current status of WebGPU support in browsers? I tried to get into it a while ago go, when the writing was already on the wall for WebGL. But WebGPU just wasn't there yet, so I had to stick with WebGL.
I still think that OpenGL is a better place to start learning 3D because there is so much less bookkeeping to do regarding memory and concurrency vs. Vulkan. I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...
If you are going to use Vulkan, check out https://howtovulkan.com/ Vulkan started with a lot of compromises to make mobile hardware happy at the expense of making everything overly complicated on desktop. Over the past decade, desktop devs have managed to get a lot of features added to make Vulkan on desktop more sane. How To Vulkan covers that newer approach. This recent video "It's Not About the API" https://www.youtube.com/watch?v=7bSzp-QildA shows how simple it can be if you let it.
And, if you are on a Mac, folks who use Metal like it a lot. Don't worry about lock-in. Once you learn the basics, knowledge is easily transferable to DX12 and Vulkan. You should plan to write 3 or 4 renderers to throw away anyway :P
> I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...
Is it the AZDO stuff? Quite interested, since there isn't really much information on the Internet about it rather than some slides and GDC videos.
The problem with OpenGL isn't so much that its programming model is outdated, but that it is an incredibly confusing and (in many places) just plain badly designed API (just look at VAOs, it's hard to come up with a more broken and useless feature - some of the problems have been salvaged on more recent OpenGL versions, but those are not portable to macOS or GLES3.x).
Another (related) problem is that the many sediment layers that have accumulated over nearly three decades are not clearly separated (and Vulkan is starting to suffer from the same problem btw, there's always at least five different ways to do the same thing, three of which are outdated or not recommended to be used on specific GPU architectures, and the other two have complicated relationships and interdependencies with other redundant or optional features, it's apparently some sort of Khronos curse to always create the biggest possible mess when it comes to 3D APIs).
On Windows (maybe even on Linux via Proton), starting with D3D11 makes a lot more sense, or on macOS with Metal v1. Both APIs are 'close enough' to modern 3D APIs to carry a lot of the knowledge over, but without being too low-level like Vulkan or D3D12, WebGPU running in browsers is also a good choice (even though it inherits some bad design decisions from Vulkan 1.0 when it comes to resource bindings, and is in some places actually slower than WebGL2).
OpenGL is limited to 4.1 on Apple platforms if I am not mistaken, and will not get updated ever. So you will run into missing features eventually on some platforms, e.g. SSBOs are really nice but you can't them use on Apple devices.
For me, a much stronger argument against OpenGL is that is requires a global state. This often leads to bad design, is miserable to multi-thread, and is rather tedious to port to Vulkan. I have spent several years fighting with multi-threading applications doing all sort of things in OpenGL and it is not great. Yes, Vulkan is extremely painful to set-up and you have to think about a million things you might not really care about directly, but honestly, I would also recommend against starting anything serious in OpenGL. To get your hands wet maybe, as with a couple lines you can get something running..
A data point: "OpenGL ES is still supported on Android, but is no longer under active feature development. Vulkan offers the following advantages over OpenGL ES" "Vulkan is the preferred Android interface to the GPU. Android 15 and up includes ANGLE as an optional layer for running OpenGL ES on top of Vulkan."
Sadly, the OP is right, OpenGL is deprecated on a number of platforms and down right removed from others. Please don't learn this now. Vulkan has the shape of every modern graphics api out there, DX included. Learn this or at the very least WebGPU.
I still write games using OpenGL for the reasons described in the comments here. I've had very good results with it despite it being "old". It works on my MacBook, PC, and SteamDeck and it has yet to surprise me.
Mesa has Zink which translates OpenGL to Vulkan. AFAIK Asahi uses it because they only wrote a native Vulkan driver for the hardware, no native OpenGL driver.
Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.
> write old OpenGL and translate it on the fly to Vulkan
Apple's OpenGL on macOS and iOS has been a shim over Metal for a very long time. The feature set is stuck somewhere between GL 3.x and 4.1 though (e.g. no compute shaders), but not for technical reasons.
OpenGL is the only truly cross-platform graphics API out there. Vulkan isn't on Apple platforms, unless you use MoltenVK which implements it on top of Metal. Also I don't know why, but Windows games tend to use Direct3D even though afaik GPU drivers do implement Vulkan on Windows, so there must be a good reason for that.
It's also much easier to grasp than Vulkan, Metal, or Direct3D.
In 2026: Yes yes, please please learn this if you're beginning computer graphics. This is basically the One and Only Holy Bible of graphics programming, and dealing with a slightly outdated and weird API doesn't make it worse even a teeny bit. You will never get the same quality of fundamental education material from any of the other tutorials (especially Vulkan ones, since most of them assume you already know the basics and delve straight into writing thousands of lines of code that doesn't even perform better than OpenGL). You need to first learn the really basic things like homogeneous coordinates, matrix transforms, vertex and fragment shaders, various shading models like Phong and PBR, multi-pass rendering, etc, before actually diving into lower-level details where you want to optimize things.
Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api) - if you want to really learn the low-level details you should start diving into something like CUDA or get into graphics driver development (start by reading Mesa open source driver code - which you will then learn why Vulkan is flawed)
> You will never get the same quality of fundamental material
If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
> Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware
> If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
I've never seen a more detailed tutorial than LearnOpenGL that actually goes through the concepts of graphics programming thoroughly and actually make things other than just "learn how to use the API". That alone should be enough to cement the site's longevity.
> And OpneGL is worse
It's never late to learn Vulkan / DX12 after learning learnopengl.com! The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming. If you start learning with Vulkan without any prerequisite knowledge, you'll be bogged in low-level details from the start that isn't really related with learning the actual fundamentals. (And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced)
Man, this takes me back! I made a Minecraft clone called Mindacraft in Java using LWJGL (the same framework Minecraft uses) about 6 or 7 years ago using this tutorial. I vividly remember this tutorial being the most useful resource for OpenGL by an order of magnitude, and that was with it being written in a language that actually had pointers and buffers! (Using OpenGL in Java is very weird because you have to use pointers and buffers through a bunch of wrapper classes, and it makes things a lot weirder. It's like using unsafe in Rust if unsafe wasn't even in Rust).
Typically just find bindings for your language and adapt the startup/bootstrap to match your language syntax. Opengl calls are fairly agnostic especially when you move to the shader logic.
The biggest issue with c# dev is OS specific window management. CLR doesn't have good wayland support yet if you're trying to do this from a modern Linux distro.
I've gotten through the Getting Started section and found it to be quite good overall. A few times it seems to make some jumps back and forth between slightly different setups, which might lead to some problems debugging.
I definitely recommend it to anyone interested! Honestly one of the biggest things it helps with is explaining the setup boilerplate for OpenGL.
After you've learned it, you can start learning CUDA if you want to do some more low-level compute stuff on the GPU (sorry, but you should just buy an NVIDIA card, CUDA is just that good). Or if you actually want to just make things but want to use a nicer cross-platform graphics API than OpenGL, then I recommend SDL3. (Or use Metal if you want to make macOS exclusive apps - it's actually a quite nice API)
Vulkan or DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware anymore. (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api). However if you want a computer graphics career (either in the game industry or in other niche domains) having experience with these APIs will be beneficial since these are what many production apps are currently stuck with - though honestly the job market for graphics really suck nowadays. (The biggest sector was triple-A game companies with their own engines, but the game industry is imploding right now...)
[0] https://github.com/floooh/sokol [1] https://wiki.libsdl.org/SDL3/CategoryGPU
Opengl meanwhile is significantly easier, and will give them the important terminology and math required to do graphics. Once the student has learned opengl and wrote a small renderer with a few basic techniques, moving to vulkan or DX12 will happen far more smoothly.
In particular, learnopengl explains a lot of basics like transformation coordinates, what a mesh is, and other similar "basic knowledge", while all vulkan and dx12 tutorials skip through that because they are meant for a much more experienced audience.
Even if OpenGL doesn't get new features what exists now will continue to work for decades.
The OpenGL API with its binding-based approach is also very confusing for beginners, but the replacement Direct State Access API came too late (after Apple already decided they would deprecate OpenGL, so it never got supported on macOS).
And the fact that the GLSL parser and compiler are part of the driver means there are tons of hardware-specific bugs and miscompilations. Intel integrated drivers on Windows are notorious for being especially buggy.
All of those make OpenGL a pretty poor target for learning. Personally, I would recommend WebGPU to people who want to get into graphics programming. It's very similar to DirectX/Metal, and like a more streamlined Vulkan. The WGPU implementation of WebGPU has a C API, which also has C++ headers, and a native Rust API. And you can also use WebGPU in your browser from JavaScript, if you don't know any native languages.
If you are going to use Vulkan, check out https://howtovulkan.com/ Vulkan started with a lot of compromises to make mobile hardware happy at the expense of making everything overly complicated on desktop. Over the past decade, desktop devs have managed to get a lot of features added to make Vulkan on desktop more sane. How To Vulkan covers that newer approach. This recent video "It's Not About the API" https://www.youtube.com/watch?v=7bSzp-QildA shows how simple it can be if you let it.
And, if you are on a Mac, folks who use Metal like it a lot. Don't worry about lock-in. Once you learn the basics, knowledge is easily transferable to DX12 and Vulkan. You should plan to write 3 or 4 renderers to throw away anyway :P
Is it the AZDO stuff? Quite interested, since there isn't really much information on the Internet about it rather than some slides and GDC videos.
Another (related) problem is that the many sediment layers that have accumulated over nearly three decades are not clearly separated (and Vulkan is starting to suffer from the same problem btw, there's always at least five different ways to do the same thing, three of which are outdated or not recommended to be used on specific GPU architectures, and the other two have complicated relationships and interdependencies with other redundant or optional features, it's apparently some sort of Khronos curse to always create the biggest possible mess when it comes to 3D APIs).
On Windows (maybe even on Linux via Proton), starting with D3D11 makes a lot more sense, or on macOS with Metal v1. Both APIs are 'close enough' to modern 3D APIs to carry a lot of the knowledge over, but without being too low-level like Vulkan or D3D12, WebGPU running in browsers is also a good choice (even though it inherits some bad design decisions from Vulkan 1.0 when it comes to resource bindings, and is in some places actually slower than WebGL2).
For me, a much stronger argument against OpenGL is that is requires a global state. This often leads to bad design, is miserable to multi-thread, and is rather tedious to port to Vulkan. I have spent several years fighting with multi-threading applications doing all sort of things in OpenGL and it is not great. Yes, Vulkan is extremely painful to set-up and you have to think about a million things you might not really care about directly, but honestly, I would also recommend against starting anything serious in OpenGL. To get your hands wet maybe, as with a couple lines you can get something running..
https://developer.android.com/games/develop/vulkan/overview
I wonder if somebody has written a adapter layer to write old OpenGL and translate it on the fly to Vulkan?
Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.
Even if you use OpenGL you still need to write shaders.
Apple's OpenGL on macOS and iOS has been a shim over Metal for a very long time. The feature set is stuck somewhere between GL 3.x and 4.1 though (e.g. no compute shaders), but not for technical reasons.
It's also much easier to grasp than Vulkan, Metal, or Direct3D.
Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api) - if you want to really learn the low-level details you should start diving into something like CUDA or get into graphics driver development (start by reading Mesa open source driver code - which you will then learn why Vulkan is flawed)
If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.
> Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware
And OpneGL is worse
I've never seen a more detailed tutorial than LearnOpenGL that actually goes through the concepts of graphics programming thoroughly and actually make things other than just "learn how to use the API". That alone should be enough to cement the site's longevity.
> And OpneGL is worse
It's never late to learn Vulkan / DX12 after learning learnopengl.com! The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming. If you start learning with Vulkan without any prerequisite knowledge, you'll be bogged in low-level details from the start that isn't really related with learning the actual fundamentals. (And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced)
it also will run just fine on windows or Linux using Proton with no issues
if I had to learn Vulkan from scratch instead, that would have been a whole different animal...
The biggest issue with c# dev is OS specific window management. CLR doesn't have good wayland support yet if you're trying to do this from a modern Linux distro.
[0] https://opentk.net/
I definitely recommend it to anyone interested! Honestly one of the biggest things it helps with is explaining the setup boilerplate for OpenGL.