▲ 270 points
back
142 comments
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...)
>The one and only Holy Bible of Graphics Programming.
The textbooks Real Time Rendering and Physically Based Rendering are far more deserving of such claims.
I've heard that learning WebGPU is a pretty decent alternative, it's cross-platform, has runners that are non-web, and has some of the niceties of Metal without being platform lock-in
The best selling game of all time (Minecraft) is basically GL 1.1. You really don't need much.
> but the game industry is imploding right now...
Why is that? Is it because of AI automating many steps of game creation?
Working through every example in order is the real advice here - the site clicks once you've actually debugged your own framebuffer, not just read the chapter. The math only sticks after you've drawn something wrong a few times.
If you really want to learn from first principles, I'd recommend writing a software renderer without any graphics API. If you're looking for a course, see [1]. Next up, extend the software renderer to render a 3D character model (an obj file will suffice) which [1] covers and animate that 3D model with skeletal animation all the while on the CPU. Use quake's md5mesh and md5anim files to render the skeletal animation from [2]. This just lays down a clear foundation of what a rendering pipeline looks like.
Then pick up something like Modern OpenGL and you'll easily intuit if you've put in the hard yards above, which parts of this pipeline are fixed and which are programmable on a hardware designed specifically to do 3D. It just so happens that the same is reusable for compute and there you go with all the D/ML jazz. After this, read up on the HW architecture of GPU's (the literature is sparse as these are vendor locked) but realtimhrendering books has chapters on it and you can find out why Vulkan, DX12, Metal are in vogue now and OpenGL has been deprecated.
[1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...
There's no need to pay for questionable courses. Here's an excellent free alternative that covers all the basics:
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.
[0] https://github.com/floooh/sokol [1] https://wiki.libsdl.org/SDL3/CategoryGPU
I cannot imagine a field more rewarding than programming with opengl when you grew up playing games. I'm talking about hobbyist engine type of development. It is almost like therapy for any dev that does web/cloud stuff during a day job.
I'm not as interested in game development but I'm one of these web/cloud people who finds graphics work extremely therapeutic. I made a box move around on the screen with various easing animations and it was some of the most fun I've ever had programming.
Lol.. I am the same. My day job is Rust + car headunit development. My drugs of choice are tikz and openscad..
Shaders used to not make any sense to me. The tutorial writes a simple expression and boom the screen is displaying all kinds of funky things.
Then I realized you're just writing code that executes on all pixels sequentially. That made it easier to understand
> executes on all pixels sequentially
or in parallel?
At this point GL is an interface, implementations will come and go, but the interface refuses to die. It's still the simplest way to get started, and the browser (WebGL) demands portability for code written against the API.
Cem Yuksel's lecture videos for Interactive Computer Graphics at the University of Utah are another free and fantastic resource. https://www.youtube.com/playlist?list=PLplnkTzzqsZS3R5DjmCQs...
I fear that in the future, opengl will be made obsolete and GPU vendors will stop supplying drivers for it, because it won't be worth it for them. Of course there are layers to be put on top of vulkan, but I don't know if they're reliable enough and can support 100% of opengl.
I would say that's one thing that the "stop killing games" movement would not see coming. I am not expert enough in graphics programming.
I am wary because lately, I realized I could not run blender 4.5 on a thinkpad from 2014, on windows, I had to use a 3.x version because that thinkpad has a chipset.
Generally in software, making things work for a long time doesn't generate profits, and it feels like opengl is getting a bit old already. I hope it won't happen and people can contradict me here.
I remember learning OpenGL back in the day with the NeHe tutorials, coding for the Dreamcast :)
That's a name I haven't heard in a long time. It was NeHe and the red book for me.
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).
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.
Honestly, in 2026 I would not really bother with OpenGL. Just start with WebGPU, it's much nicer. You can use it easily on most modern browsers or better can even use native libraries like Dawn or WGPU.
OpenGL is still the simplest way to start learning hardware accelerated rendering, and it runs on all modern platforms.
Any recommendations on how to use OpenGL from the CLR (.Net/C#) please?
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 can recommend OpenTK [0]. I've used it recently to create a 3D renderer, and I have not run into any issues.
How does this compare to The OpenGL Programming Guide?
Is it possible to complete this course on an M1 Mac?
Yes, OpenGL 4.1 is available, just deprecated. It's emulated through Metal, and so will work on M chips.
Should be, OpenGL still runs on MacOS.
Could you please give some advice on whether there are options as good as Metal for targeting Windows and Linux platforms separately?
Many years ago, I used Learn OpenGL to learn about graphics. It's good to see that it's getting some love now.
The old primitive API was the best. Who invented the new shader API? They ruined my life.
If you want to use glBegin() / glEnd() - like immediate API with modern OpenGL, I reecommend using a library called RLGL (https://github.com/raysan5/raylib/blob/master/src/rlgl.h), from Raylib. You'll feel straight at home!
Same sentiment here. My litmus test is - after creating a window - "how many lines of code does it take to render a triangle?".
With the old OpenGL API you could do this in like 10 lines of code (probably even less with SGI's GL).
With the new/shader-based API, well... https://learnopengl.com/Getting-started/Hello-Triangle
Vulkan - I don't even want to know.
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.
OpenGL is not obsolete and is totally fine for many use cases. Vulkan is way too complicated and cumbersome for many.
Even if OpenGL doesn't get new features what exists now will continue to work for decades.
This advice is basically like a teenager wanting to play electric guitar to jam out a few rock tunes, but their parents insist on learning classical guitar instead because starting with the fundamentals is the only "real" way to become a great musician. Meanwhile the kid loses interest and moves on to something else.
Vulkan is garbage. It's completely needlessly overengineered. Like, you literally have to write 50 lines of code just to allocate GPU memory, which is a one-liner in other APIs like CUDA. These 50 lines include things like heap type shopping and usage flags, that are entirely pointless for modern desktop GPUs. I know there is VMA, but that is a poorly made bandaid over a badly designed API, and barely addresses one out of 100 UX issues with Vulkan. There is a reason so many are sticking with OpenGL. OpenGL is fairly bad, but at least it isn't Vulkan.
But I can agree with CUDA. CUDA is great, in a large part because it actually offers an easy to use API.
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.
OpenGL is arguably still better for learning the fundamentals of computer graphics. All you really want early on is a simple vertex and fragment shader up and running so that you can learn how to move a camera around, transform objects, basic lighting and texturing, etc. Vulkan is overkill for that. If you follow the LearnOpenGL tutorials you'll get as far as HDR lighting and shadows. At that point you'll be better equipped to understand an API like Vulkan and probably a lot more successful at porting an engine over to it.
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)
It's so much easier than Vulkan or writing shaders and the performance is more than good enough for a lot of applications.
I wonder if somebody has written a adapter layer to write old OpenGL and translate it on the fly to Vulkan?
Wonder how this opinion will age. Won't be surprised if in 10 years OpenGL will be more widely supported and used than Vulkan. It's the Lindy effect after all.
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.
Relatedly: could someone recommend a Vulkan introduction for people who don't "just want to make it work"? I understand the fact that Vulkan abstracts away a lot less of the rendering device than OpenGL does – that may be a strength or a weakness, but either way I'd like to understand. It seems a lot of introductions just skip over it all while apologizing for the boilerplate.
I think I once bookmarked an article which takes an interesting approach, namely doing all rendering with Vulkan compute! Does that ring a bell to anyone? I can't find it again. It seems very appealing to me. It may not be the best way to approach graphics, but I know a lot more about computations in general than I do graphics in particular. And knowing Vulkan Compute would help me in lots of ways, so it I can also use it for graphics that's a nice bonus.