It's an amazing book, but I think most beginners would struggle with it. It's more of an intermediate - advanced level overview of the entire field. Required reading of you're serious about getting into real time graphics, for sure.
I was recently asked by a colleague how to get into rendering. I recommended this book to her. I did read through the first chapter again to see how beginner friendly the start was.
It seems to assume some familiarity with linear algebra, but it seemed quite accessible. It's difficult to gauge when you already know the topic well and I'm still waiting to hear back from my colleague.
edit: I might add that the reason I have a copy is actually that it was the textbok we used at the University.
Yeah, the early sections are good for beginners. Later sections less so - try reading through the chapter on PBR without prior knowledge, for example.
I'm not saying this book is not suitable for beginners. But I think there are easier places to start and it's likely many beginners would get frustrated some time after the first few chapters unless they are very motivated or using it as part of a course (and hence having someone lead them through the material).
For a beginner I'd recommend using this as a reference - something to keep on your shelf for years and keep coming back to as you go deeper into new areas of graphics - rather than trying to read it through and absorb all the material in one go.
Is learning OpenGL pretty much inevitable as a precursor to learning Vulkan?
The main page of Khronos' beginner's guide to Vulkan has a quote which says "emphatically... NO", but then the first tutorial in the list gives as a prerequisite "some existing experience with 3D computer graphics" and links to a guide (https://paroj.github.io/gltut/) which teaches OpenGL.
There's a lot more to 3D graphics than writing shaders - here are some things that could be considered prerequisites:
* vectors, vertices, points and how they are handled in 3D graphics
* how geometry is built out of the above
* Basic knowledge of how the camera is set up
* Ditto lights
* Basic knowledge of manipulating objects in 3D space
* Knowledge of texture/material systems and how materials are applied to geometry
And, while not specifically 3D graphics, some maths to tie all that together (mostly linear algebra, optionally quaternions).
Besides the math, a couple of days learning to create some simple scenes in Unity - or even better in a pure code environment like Three.js - could give you all the knowledge you need to get started writing shaders.
Of course, you could technically jump straight into writing shaders without any of that, and shaders can be used for a lot more than creating 3D scenes, but presumably the Khronos assumes this kind of knowledge.
I'd rather suggest that people learn D3D11 first, if they can, instead of Vulkan. The OpenGL programming model has a lot of backwards ideas that can make graphics seem far more complicated than it is. Vulkan removes those and gets closer to the D3D11 style, but it also introduces a lot of more complicated ideas. Learning the whole gamut at once is a challenge.
There are other options to get started with graphics. Frameworks you can use to start putting your toes in the water: any game engine, a higher-level graphics framework like raylib or bgfx, or a cross-platform graphics layer like WebGPU/wgpu.
I don't want to gatekeep, just being realistic that if you're new to graphics in general, Vulkan might not be the best place to start. You'll get there eventually though.
If they want to use Rust, wgpu-rs is basically a simpler and memory-safe version of the Vulkan API. Obviously the overhead will be unacceptable for some use-cases, but it's a good way of learning the core concepts of Vulkan and 3D rendering in general
In my opinion, yes you should probably learn a higher level api than Vulkan first like DX11 or OpenGL if you have no experience. This is also still important for 2D, creating a simple textured quad in Vulkan is at least one order of magnitude more complicated/verbose than the higher level mentioned apis.
In Vulkan, you're going to be manually describing to the GPU every last atom of your graphics pipeline. You also need to worry about how it's all laid out in memory through a bunch of descriptor objects that you're building in tandem. Then there's syncing between the GPU and CPU via semaphores etc to transfer data, which can be error prone and hard to debug. This results in very verbose and hard to read code. If you've never touched a graphics api before, I think frustration starts to mount and you'd be more likely to just give up. The upside is you have total control over how the GPU interprets and executes your workload (most likely a triangle as a beginner :P)
Anyway, a lot of this is hidden away in DX11 or OpenGL, you call a few functions here and there and it will do all of these lower level concerns for you. I think once you get used to the jargon and feel of apis like these, you can then start to see how Vulkan or a similar low level api would fill in between the higher level procedures/objects.
Edit: For any graphics api, imo, if you're concerned about building a game you'd probably also not want to touch those apis directly from game code. In DX11 or OpenGL it's not too hard to wrap that up in a bit higher abstraction but in Vulkan you'd almost first want to wrap Vulkan into an api that can be used without writing a ton of manual setup and then use that api to write a higher level, more game appropriate abstraction to call from the game's code. (usually done as part of an engine/framework)
Edit 2: Having said all of this, you could ignore all of the nitty/gritty details and just copy paste the code from the tutorials and make a workable api for yourself to try to understand. Up to you and how you like to learn.
OpenGL is a lot easier to learn. It's not a pre requisite, but Vulkan is definitely the deep end of shader programming.
Honestly if platform is not an issue, I'd recommend people start with Metal because it's the easiest of the "modern" graphics APIs.
DirectX 12 is probably second and Vulkan is probably among the hardest to start with.
WebGL is also a good way to start though is obviously more limited.
Or start with shader graphs in unreal or unity. You can still learn the shader logic and math without worrying about setting up a render context and learning to "code"
> Is learning OpenGL pretty much inevitable as a precursor to learning Vulkan?
Well, maybe not OpenGL, but almost surely some graphics API which allows you to do graphics without a couple thousand lines of obscure boilerplate.
There are lots of "middleware" systems built on Vulkan that are WAY friendlier than raw Vulkan. They handle things like asset loading, memory management, and scene composition for you. If you want to build something, use those. You'll be vastly happier at the end of the day. Maybe at some point you'll hit a performance bottleneck--fine, but by then you know a lot more about graphics.
If you're doing raw Vulkan, you should have a darn good idea as to your purpose.
If someone says: "I want to use Vulkan." I ask "Why?"
If they say: "Because I want to make a thing that does <X>." then they absolutely should be in a middleware system and not Vulkan. They'll get something on the screen much faster and keep their motivation going.
If they say: "Because I want to learn" I have to try to redirect them to something a lot simpler. Learning is about motivation and Vulkan boilerplate saps your motivation really hard.
It also doesn't help that Vulkan development is basically C++ and Windows and there is no negotiating this as a beginner. Trying to develop Vulkan through a language wrapper or on Linux/OS X adds an unnecessary amount of pain to the process--quadruply so if the wrapper tries to be "idiomatic" in your language of choice.
If they say: "Well, we found a bottleneck using RenderDoc and we..." then I ... HA! I'm kidding. Nobody says this because they KNOW why they need to use Vulkan so they don't even ask me.
The primary problem with Vulkan is that you are mapping REALLY closely to the underlying hardware. If you don't understand what the pieces of your graphics card are and what they are doing and why, Vulkan makes very little overarching sense.
One thing I will warn you about when programming Vulkan, you better be really good in your programming language of choice. There are times when you are writing Vulkan code where you have to add a couple hundred lines of code before you can finally test that you got it right. You have to be very confident in your programming skill that you got all the essential things in your language right so that any bug is really in the way you are using Vulkan. For example, if your understanding of pointers and pointers-to-pointers isn't rock solid, you're gonna have a bad time.
> It also doesn't help that Vulkan development is basically C++ and Windows and there is no negotiating this as a beginner. Trying to develop Vulkan through a language wrapper or on Linux/OS X adds an unnecessary amount of pain to the process--quadruply so if the wrapper tries to be "idiomatic" in your language of choice.
Actually Vulkan uses C, not C++ as usual in most Khronos APIs, and only GNU/Linux and Android 10 onwards are the only platforms where Vulkan has any meaningful usage.
On Windows everyone just uses DirectX, OpenGL ICD which are also used by Vulkan drivers aren't even allowed on Windows sandbox driver model, and on Switch, Vulkan might be supported, but so is OpenGL and NVN is actually the one holding the GPU keys.
In what concerns Sony and Apple, Vulkan doesn't even exist.
> Actually Vulkan uses C, not C++ as usual in most Khronos APIs
You are technically correct--Vulkan is a C API. However, all the tutorials you will use are written in C++.
I have never seen a C-only Vulkan tutorial. Link welcomed.
On Windows, everyone is using DirectX 11. That is a very different (and much simpler!) beast than DirectX 12 (which--unsurprisingly--looks very much like Vulkan).
And, as for Apple, I suspect the fact that Valve/Steam is all-in on MoltenVK(Vulkan on top of Metal) for development means that way more gamers are running games with Vulkan on OS X than plain Metal. (DotA 2--for example--is MoltenVK only on OS X, IIRC).
However, most game developers DON'T CARE. They are writing to a game engine that handles all that behind the scenes. As long as the game engine is ported to the appropriate system, the underlying implementation is irrelevant to them.
Which is quite different from "It also doesn't help that Vulkan development is basically C++ and Windows".
On Apple, all relevant engines support Metal directly, no need for MoltenVK at all. That is just for the usual FOSS anti-Apple folks that buy Apple hardware and then complain it isn't GNU/Linux.
Nope. Leaving aside the fact that the book isn't that great and that I only see snippets and not a compilable codebase, look at the snippets:
"VkResult vkapp::init()"
"std::vector<VkQueueFamilyProperties>"
> It also doesn't help that Vulkan development is basically C++ and Windows
I stand by this statement. If you are doing Vulkan (and not DirectX) the highest probability is that you are on Windows in C++.
> On Apple, all relevant engines support Metal directly
Source 2, at the least, does not as far as I know. Which means that DotA2, CS:GO, Artifact, etc. all only run on iOS via MoltenVK since Apple has dropped OpenGL support.
> Source 2, at the least, does not as far as I know. Which means that DotA2, CS:GO, Artifact, etc. all only run on iOS via MoltenVK since Apple has dropped OpenGL support.
CS:GO is definitely not Source 2 (yet?), and I'm not sure about Artifact, but it was at least at one point developed using Unity.
Why would you be doing Vulkan on Windows, if the targets are GNU/Linux and Android?
Source 2 belongs to the "that is just for the usual FOSS anti-Apple folks that buy Apple hardware and then complain it isn't GNU/Linux." given it is from Valve.
A great way to explore, play around with, and share shaders is Shader Toy[1]
[0] https://www.realtimerendering.com/
[1] https://www.shadertoy.com/