Hacker News Reader

Comment by k_sze | Hacker News Reader

I'm mildly surprised that people still write tutorials using OpenGL nowadays.

I thought the concensus is that 1) OpenGL is bad due to hidden states (and if I remember correctly, the hidden states can behave differently depending on the vendor, which exacerbates the problem), and that 2) people should move to Vulkan (or Metal, or DirectX 12).

View on HN

Don't believe the hype. OpenGL is still fine for getting started with and applications where Vulkan etc is overkill. It makes perfect sense for game engines and heavy duty applications to make the switch, but for the simple stuff stick with OpenGL where it makes sense.

Vulkan/DX12 is quite intimidating, even for an experienced programmer, let alone a novice. I am a DX12 graphics driver developer and I still find the API intimidating at times, and a missing barrier can cause hard to debug graphical corruptions, something you didn't have to worry about in OpenGL. Metal is simpler in comparison. WebGPU is a good stepping stone between OpenGL and Vulkan. It feels closer to Vulkan/DX12 in design, but takes care of the tougher things like synchronization, barriers, memory management.

I think one of the main issues is that Vulkan is really bad from a usability perspective. OpenGL is too, but there is little incentive to switch from one bad API that you know how to use, to another bad API that you don't know how to use. On the other hand, I've spent time learning WebGPU in the past year and found that it was an excellent API that is an enormous quality of live improvement over OpenGL, so even if it has fewer features (due to Web, not API design), it's still something that I really want to switch to, unlike Vulkan.

I had a really good time writing a Vulkan renderer for a project I did. There's _A LOT_ of boilerplate, but there are helpful error messages every step of the way and the API makes sense because everything is explicit, unlike OGL.

It's not just the boilerplate, but also seemingly noncensical things like stypes.

Getting Vulkan to work is one thing. Getting Vulkan to work well is another.

There's nothing to be surprised about, Vulkan creators themselves said that they do not want to replace OpenGL for these kind of use-cases.

Vulkan is very deliberately a very very verbose low-level API to allow maximum optimization for game engine developers. It's not meant for your my-first-3d-program usage and it shouldn't be sold as such. Same way as using ASM to write CLI tools isn't a sensible approach.

Do the following:

    <start a timer>

    vi vulkan_one_pixel.cpp

    <add the required code to open a window and draw *one* pixel>

    <save, compile, debug, rinse, repeat until a window is opened and a pixel is drawn in it>

    <stop timer>

    <read timer>

    wc -l vulkan_one_pixel.cpp

    du -sh vulkan_one_pixel.cpp

    <despair>

Vulkan has a very high initial cost when it comes to lines of code. You have to recreate a lot of stuff that you took for granted in OpenGL, such as a default framebuffer to draw to. Also, a lot of boilerplate code to create resources can be abstracted away into functions to reuse later. So while you might need a lot of lines to even draw a triangle, you won't need many more lines to draw a full 3D model.

For anyone interested in the Vulkan end of things, I recommend this: https://hoj-senna.github.io/ashen-aetna/

What is nice to see that with Rust's linearity, cleaning resources once they become unused can be cleared quite easily by implementing a custom drop function. The challenge remains though that to know what order you have to do it requires consultation of the Vulkan specification. Though even for this you can enable Vulkan validation layers which actually give quite clear idea what you are doing wrong.

This seems to focus on WebGL, and the alternative, WebGPU, is still only available in nightly builds.

Also for a beginner, WebGL is far more accessible. I'm just getting into it myself, and started with WebGPU. Bad idea lol. Went back to WebGL and even though it was still tough, I stuck with it and now have a basic grasp of what's going on. I get that there's a lot of hidden stuff under the hood, but now when I return to WebGPU at some point, I'll at least have context as to what it's trying to do.

Reply on news.ycombinator.com