I'm sure Vulkan is fun and wonderful for people who really want low level control of the graphic stack, but I found it completely miserable to use. I still haven't really found a graphics API that works at the level I want that I enjoyed using; I would like to get more into graphics programming since I do think it would be fun to build a game engine, but I will admit that even getting started with the low level Vulkan stuff is still scary to me.
I think what I want is something like how SDL does 2D graphics, but for 3D. My understanding is that for 3D in SDL you just drop into OpenGL or something, which isn't quite what I want.
Maybe WebGPU would be something I could have fun working on.
SDL 3.0 introduced their GPU API a year or so ago, which is an abstraction layer on top of vulkan/others, might want to check it out.
Although after writing an entire engine with it, I ended up wanting more control, more perf, and to not be limited by the lowest common denominator limits of the various backends, and just ended up switching back to a Vulkan-based engine.
However, I took a lot of learnings from the SDL GPU code, such as their approach to synchronization, which was a pattern that solved a lot of problems for me in my Vulkan engine, and made things a lot easier/nicer to work with.
`wgpu` in Rust is an excellent middle ground, matching the abstraction level of WebGPU. More capable than OpenGL, but you don’t have to deal with things like resource barriers and layout transitions.
The reason you don’t is that it does an amount of bookkeeping for you at runtime, only supports using a single, general queue per device, and several other limitations that only matter when you want to max out the capabilities of the hardware.
Vulkan is miserable, but several things are improved by using a few extensions supported by almost all relevant vendors. The misery mostly pays off, but there are a couple of cases where the API asks you for a lot of detail which all major drivers then happily go ahead ignore completely.
As someone who did OpenGL programming for a very, very long time, I fully agree with you. Without OpenGL being maintained, we are missing a critical “middle” drawing API. We have the very high level game engines, and very low level things like Vulkan and Metal which are basically thin abstractions on top of GPU hardware. But we are missing that fun “draw a triangle” middle API that lets you pick up and learn 3D Graphics (as opposed to the very different “learn GPU programming” goal).
If I was a beginner looking to get a basic understanding of graphics and wanted to play around, I shouldn’t have to know or care what a “shader” is or what a vertex buffer and index buffer are and why you’d use them. These low level concepts are just unnecessary “learning cliffs” that are only useful to existing experts in the field.
Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you. They are willing to put up with the minutiae and boilerplate needed to work at that low level because they need it. Everyone else would be better off with OpenGL.
The problem with 'something like SDL, but 3D' very quickly turns into a full blown engine. There's just such a combinatorial explosion of different ways to do things in 3D compared to 2D that 3D 'game engine' is either limiting or complicated.
OpenGL was designed as a way to more or less do that and it turned complicated fast.
To this day, the best 3D API I’ve used (and I’ve tried quite a few over the years) is Apple’s SceneKit. Just the right levels of abstraction needed to get things on the screen in a productive, performant manner for most common use cases, from data visualization to games, with no cruft.
I followed tutorials for Vulkan. I liked vk-guide, until it updated to the latest version. People said the newer SDL is so much better, but I honestly had more fun and got things done back with Renderpasses.
I personally have just been building off of tutorials. But notwithstanding all of the boilerplate code, the enjoyability of a code base can be vastly different.
The most fun I’ve ever had coding, and still do at times, is with WebGL. I just based it off of the Mozilla tutorial and went from there. WebGLFundamentals has good articles…but to be honest I do not love their code
Frank Luna’s D3D11 bible is probably the closest thing we’ll get to a repetition spaced learning curriculum for 3D graphics at a level where you can do an assload with the knowledge.
No, it won’t teach you to derive things. Take Calculus I and II.
No, it won’t teach you about how light works. Take an advanced electrical engineering course on electromagnetism.
But it will teach you the nuts and bolts in an approachable way using what is by far an excellent graphics API, Direct3D 11. Even John Carmack approves.
From there on all the Vulkan, D3D12 shit is just memory fences buffers and queue management. Absolute trash that you shouldn’t use unless you have to.
I just want to be a bit picky and say that bike shedding means focusing on trivial matters while ignoring or being oblivious to the complicated parts. What he described sounded more like a combination of feature creep/over-engineering.
The author could also have used the phrase "hobby horsing", which is similar to bike shedding in that the individual is focusing on things that don't really push the project forward, but which rather give them personal pleasure, instead. Bike shedding usually is explained as "working out what color to paint the bike shed before the rest of the house is done".
I am fascinated with 3D/Gaming programming and watch a few YouTubers stream while they build games[1]. Honestly, it feels insanely more complicated than my wheelhouse of webapps and DevOps. As soon as you dive in, pixel shaders, compute shaders, geometry, linear algebra, partial differential equations (PDE). Brain meld.
>If you haven’t done any graphics programming before, you should start with OpenGL
I remember reading NeHe OpenGL tutorials about 23 years ago. I still believe it was one of the best tutorial series about anything in the way they were structured and how each tutorial built over knowledge acquired in previous ones.
Vulkan was one of the hardest thing I've ever tried to learn. It's so unintuitive and tedious that seemingly drains the joy out of programming. Tiny brain =(
You don't have a tiny brain. Vulkan is a low-level chip abstraction API, and is about as joyful to use as a low-level USB API. For a more fun experience with very small amounts of source code needed to get started, I'd recommend trying OpenGL (especially pre-2.0 when they introduced shaders and started down the GPU-programming path), but the industry is dead-set on killing OpenGL for some reason.
When I first tried to learn Vulkan, I felt the exact same way. As I was following the various Vulkan tutorials online, I felt that I was just copying the code, without understanding any of it and internalizing the concepts. So, I decided to learn WebGPU (via the Google Dawn implementation), which has a similar "modern" API to Vulkan, but much more simplified.
The commonalities to both are:
- Instances and devices
- Shaders and programs
- Pipelines
- Bind groups (in WebGPU) and descriptor sets (in Vulkan)
- GPU memory (textures, texture views, and buffers)
- Command buffers
Once I was comfortable with WebGPU, I eventually felt restrained by its limited feature set. The restrictions of WebGPU gave me the motivation to go back to Vulkan. Now, I'm learning Vulkan again, and this time, the high-level concepts are familiar to me from WebGPU.
Some limitations of WebGPU are its lack of push constants, and the "pipeline explosion" problem (which Vulkan tries to solve with the pipeline library, dynamic state, and shader object extensions). Meanwhile, Vulkan requires you to manage synchronization explicitly with fences and semaphores, which required an additional learning curve for me, coming from WebGPU. Vulkan also does not provide an allocator (most people use the VMA library).
SDL_GPU is another API at a similar abstraction level to WebGPU, and could also be another easier choice for learning than Vulkan, to get started. Therefore, if you're still interested in learning graphics programming, WebGPU or SDL_GPU could be good to check out.
Exactly the reason why I haven't switched from OpenGL to Vulkan. Vulkan is just ridiculously overengineered. Cuda shows that allocation of GPU memory and copy from host to device can be one-liners, yet in Vulkan it's an incredible amount of boilerplate to go through. Modern Vulkan fixes a lot of issues, like getting rid of pipelines, render passes, bindings, etc., but there is still much more to fix before it's usable.
I think anyone who ever looked at typical Vulcan code examples would reach the same conclusion: it's not for application/game developers.
I really hope SDL3 or wgpu could be the abstraction layer that settles all these down. I personally bet on SDL3 just because they have support from Valve, a company that has reasons to care about cross platform gaming. But I would look into wgpu too (...if I were better at rust, sigh)
I love that it's becoming kind of cool to do hobby game engines. I've been working on a hobby engine for 10 years and it's been a very rewarding experience.
tombert|3 months ago
I'm sure Vulkan is fun and wonderful for people who really want low level control of the graphic stack, but I found it completely miserable to use. I still haven't really found a graphics API that works at the level I want that I enjoyed using; I would like to get more into graphics programming since I do think it would be fun to build a game engine, but I will admit that even getting started with the low level Vulkan stuff is still scary to me.
I think what I want is something like how SDL does 2D graphics, but for 3D. My understanding is that for 3D in SDL you just drop into OpenGL or something, which isn't quite what I want.
Maybe WebGPU would be something I could have fun working on.
thegrim33|3 months ago
Although after writing an entire engine with it, I ended up wanting more control, more perf, and to not be limited by the lowest common denominator limits of the various backends, and just ended up switching back to a Vulkan-based engine.
However, I took a lot of learnings from the SDL GPU code, such as their approach to synchronization, which was a pattern that solved a lot of problems for me in my Vulkan engine, and made things a lot easier/nicer to work with.
simonask|3 months ago
The reason you don’t is that it does an amount of bookkeeping for you at runtime, only supports using a single, general queue per device, and several other limitations that only matter when you want to max out the capabilities of the hardware.
Vulkan is miserable, but several things are improved by using a few extensions supported by almost all relevant vendors. The misery mostly pays off, but there are a couple of cases where the API asks you for a lot of detail which all major drivers then happily go ahead ignore completely.
ryandrake|3 months ago
If I was a beginner looking to get a basic understanding of graphics and wanted to play around, I shouldn’t have to know or care what a “shader” is or what a vertex buffer and index buffer are and why you’d use them. These low level concepts are just unnecessary “learning cliffs” that are only useful to existing experts in the field.
Maybe unpopular opinion: only a relative handful of developers working on actually making game engines need the detailed control Vulkan gives you. They are willing to put up with the minutiae and boilerplate needed to work at that low level because they need it. Everyone else would be better off with OpenGL.
user____name|3 months ago
maybewhenthesun|3 months ago
OpenGL was designed as a way to more or less do that and it turned complicated fast.
unknown|3 months ago
[deleted]
gyomu|3 months ago
Sadly 1) Apple only, 2) soft deprecated.
bashmelek|3 months ago
I personally have just been building off of tutorials. But notwithstanding all of the boilerplate code, the enjoyability of a code base can be vastly different.
The most fun I’ve ever had coding, and still do at times, is with WebGL. I just based it off of the Mozilla tutorial and went from there. WebGLFundamentals has good articles…but to be honest I do not love their code
diath|3 months ago
DeathArrow|3 months ago
cuckmaxxed|3 months ago
Frank Luna’s D3D11 bible is probably the closest thing we’ll get to a repetition spaced learning curriculum for 3D graphics at a level where you can do an assload with the knowledge.
No, it won’t teach you to derive things. Take Calculus I and II.
No, it won’t teach you about how light works. Take an advanced electrical engineering course on electromagnetism.
But it will teach you the nuts and bolts in an approachable way using what is by far an excellent graphics API, Direct3D 11. Even John Carmack approves.
From there on all the Vulkan, D3D12 shit is just memory fences buffers and queue management. Absolute trash that you shouldn’t use unless you have to.
jezze|3 months ago
mpenick|3 months ago
MomsAVoxell|3 months ago
nodesocket|3 months ago
[1] https://www.youtube.com/@tokyospliff
jesse__|3 months ago
Plenty of people make minecraft-like games as their first engine. As far as voxel engines go, a minecraft clone is "hello, world."
DeathArrow|3 months ago
I remember reading NeHe OpenGL tutorials about 23 years ago. I still believe it was one of the best tutorial series about anything in the way they were structured and how each tutorial built over knowledge acquired in previous ones.
gnabgib|3 months ago
anvuong|3 months ago
ryandrake|3 months ago
hutao|3 months ago
The commonalities to both are:
- Instances and devices
- Shaders and programs
- Pipelines
- Bind groups (in WebGPU) and descriptor sets (in Vulkan)
- GPU memory (textures, texture views, and buffers)
- Command buffers
Once I was comfortable with WebGPU, I eventually felt restrained by its limited feature set. The restrictions of WebGPU gave me the motivation to go back to Vulkan. Now, I'm learning Vulkan again, and this time, the high-level concepts are familiar to me from WebGPU.
Some limitations of WebGPU are its lack of push constants, and the "pipeline explosion" problem (which Vulkan tries to solve with the pipeline library, dynamic state, and shader object extensions). Meanwhile, Vulkan requires you to manage synchronization explicitly with fences and semaphores, which required an additional learning curve for me, coming from WebGPU. Vulkan also does not provide an allocator (most people use the VMA library).
SDL_GPU is another API at a similar abstraction level to WebGPU, and could also be another easier choice for learning than Vulkan, to get started. Therefore, if you're still interested in learning graphics programming, WebGPU or SDL_GPU could be good to check out.
bsder|3 months ago
The question you need to ask is: "Do I need my graphics to be multithreaded?"
If the answer is "No"--don't use Vulkan/DX12! You wind up with all the complexity and absolutely zero of the benefits.
If performance isn't a problem, using anything else--OpenGL, DirectX 11, game engines, etc.
Once performance becomes the problem, then you can think about Vulkan/DX12.
m-schuetz|3 months ago
raincole|3 months ago
I really hope SDL3 or wgpu could be the abstraction layer that settles all these down. I personally bet on SDL3 just because they have support from Valve, a company that has reasons to care about cross platform gaming. But I would look into wgpu too (...if I were better at rust, sigh)
jesse__|3 months ago
jakogut|3 months ago