4 ms·

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 r

by k_sze 5y ago

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

mschuetz 5y ago
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.
- tpxl 5y ago
  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.
  - mschuetz 5y ago
    It's not just the boilerplate, but also seemingly noncensical things like stypes.
  - SantalBlush 5y ago
    Getting Vulkan to work is one thing. Getting Vulkan to work well is another.
blihp 5y ago
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.
sva_ 5y ago
This seems to focus on WebGL, and the alternative, WebGPU, is still only available in nightly builds.
- danielvaughn 5y ago
  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.
skocznymroczny 5y ago
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.
ur-whale 5y ago
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>
- skocznymroczny 5y ago
  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.
  - Jhsto 5y ago
    For anyone interested in the Vulkan end of things, I recommend this: https://hoj-senna.github.io/ashen-aetna/ 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.
izacus 5y ago
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.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

by k_sze 5y ago

mschuetz 5y ago

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.

tpxl 5y ago
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.
- mschuetz 5y ago
  It's not just the boilerplate, but also seemingly noncensical things like stypes.
- SantalBlush 5y ago
  Getting Vulkan to work is one thing. Getting Vulkan to work well is another.

blihp 5y ago

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.

sva_ 5y ago

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

danielvaughn 5y ago
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.

skocznymroczny 5y ago

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.

ur-whale 5y ago

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>

skocznymroczny 5y ago
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.
- Jhsto 5y ago
  For anyone interested in the Vulkan end of things, I recommend this: https://hoj-senna.github.io/ashen-aetna/ 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.

izacus 5y ago

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.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]