3D Game Shaders for Beginners

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.

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"

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.

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.

However, if you still wish to persist. Here is a class at Oregon State that does Vulkan: http://web.engr.oregonstate.edu/~mjb/vulkan/

Note that this is considered an upper division/graduate class. That should give you an idea of what you're in for.

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