[pjmlp]

It is not a next generation OpenGL, unless one wants to become an expert in driver and compiler development on top of mastering graphics programming.

Currently Khronos answer for those that don't want to become such experts it to stick with OpenGL, the problem is that is isn't gettting much updates beyond 4.6, and Vulkan is not getting a more developer friendly API.

Most devs will be better by choosing a middleware engine and just check the respective box of the desired graphics API backend.

[skocznymroczny]

I think expert in driver and compiler development is too much. It takes a lot more to get started, because it doesn't assume any defaults, but then it isn't too hard as long as you venture into topics like multithreading, but then in OpenGL you never went into multithreading in the first place.

I think the best middleground between OpenGL and middleware engines are translation layers such as gfx-rs and bgfx, which offer a low-level but userfriendly API and can compile to several different graphics API backends.

[pjmlp]

Experience has proven that if you aren't really deep into Vulkan, the end result will be worse than just doing it in OpenGL, in terms of performance.

[HelloNurse]

The theory was that OpenGL or any other API of that kind is reasonably easy to implement on top of Vulkan, providing very long term support and compatibility for OpenGL-based applications.

In practice, like 15 years ago, you can use Mesa3D which remains as comprehensive and unexciting as ever with constantly improving performance thanks to using Vulkan.

In the more mainstream part of practice, rendering engines get rid of OpenGL to use Vulkan because it's usually better.

[MaxBarraclough]

> Vulkan is not getting a more developer friendly API

It's not going to be 'dumbed down', sure, but developer-friendly APIs may still be possible through higher-level systems like Unreal Engine, no?

Plenty of developers will benefit from Vulkan without mastering it. I presume they already have.