Learn OpenGL, extensive tutorial resource for learning Modern OpenGL

Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.

"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.

You always need to explicitly say which platforms you target, and then test on those platforms.

The main questions should be "on which platform will my users run it" and "can I debug and test this".

So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).

The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM. In that regard there are also some interesting projects/opportunities.

The RTR book doesn't teach you the programming side of things at all, the material is more theoretical and reads more like a reference book. Most importantly it doesn't have any examples with full source code, so it's not a friendly book to follow for beginners. The PBR book is much better in this regard, but it mainly focuses on offline ray tracing / path tracing which is bit of a distinct topic from conventional real-time rendering on the GPU.

Then layer in some incredibly bad bets like Game Pass for XBox and audience tastes shifting away from splashy big budget releases making them an “inevitable” success. It’s left middle aged execs heads in a twist.

In a broader view discoverability is the big problem for everyone. People are hoping in the short term that reducing budgets and scope will save things but all that will do is make the discoverability problem worse. So everyone’s hot under the collar for codev, offshoring, “the Hollywood model*” and so on without looking at the downstream effects of everyone doing that.

AI has largely impacted games by sucking all the available money away and the discoverability problem has made what little is left extremely conservative.

* - This has been a thing for at least three decades now in games despite the obvious collapse of this model and Hollywood.

You're absolutely wrong here and without backing it up with strong justification.

FWIW, I work at a FAANG as a HW/SW GPU Engineer, have enough experience to not have any need to do this course but did so to confirm it's appropriate and found it of top notch quality. We don't have enough GPU engineers and recommend this as one of the initial courses when we hire from other domains.

You want to start with OpenGL because the API is organized roughly around these high level concepts. Starting with something like Vulkan means you're dropped straight into hundreds of lines of low level boilerplate setting up VkCommandBuffers and VkRenderPasses and VkPipelines and shaders, and all this GPU programming, and it's all just bewildering if you're used to thinking about things at the high level first, or just want to draw a fucking triangle on the screen.

I would agree if by modern you mean DX12 or Vulkan, but WebGPU (and maybe even Metal) are quite decent.

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).

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

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

If you're in it for learning how to play music, the flea market guitar will serve you better.

Windows official API is DirectX, OpenGL and Vulkan use a plugin API, ICD, which is nonetheless DirectX underneath.

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

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

Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.

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.

Even if you use OpenGL you still need to write shaders.

Khronos has a tutorial that walks you through getting a triangle on the screen, to rendering a glTF model, all the way up to how you go about making a simple engine.

But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that.

Almost 1000: https://github.com/Overv/VulkanTutorial/blob/main/code/15_he...

(From Chapter 15 of the Vulkan Tutorial from vulkan-tutorial.com)