Mind expanding what sucks about it? It's been a number of years since I did any serious OGL work, but at the time Vulkan looked like it was going to be a major step in the right direction.
Perhaps that is the problem, for any new general GPU API to get industry traction, driver, and os + tool support -takes a lot of time, and it feels obsolete by the time it is put to practical use.
- it inherited the 'vendor extension mess' of GL, e.g. the development process of Vulkan is to let GPU vendors write extensions which are eventually declared as 'core', this sort of 'design by committee^H^H^Hvendor' approach will ineviatably result in a hot mess of an API after a couple of years
- it tried to cover the whole range between low-end mobile and high-end desktop GPUs with the same API, pretty much all design warts of Vulkan exists because it had to cover mobile GPU architectures that were already outdated with Vulkan 1.0
At least Khronos is aware now about the issues, question is whether it will result in any actual improvements, and how long that will take:
Additionally yes, traction has been pretty weak too. It's still a wrapper on iOS/Mac and slower than DX12 on Windows. When you want something easy and crossplatform use OpenGL, and if you're really going to max out perf, then you use DX12 and Metal(which tbh might be easier than Vulkan too), so Vulkan's in a kinda awkward place.
Back in the day, when Blender still had an openGL python module[0], I made a pie menu prototype without too much fuss.
With Vulcan, with what I've seen, this would have been a major endeavor just to get to the point where you can get a canvas so you can put some pixels on the screen as you have to do a whole lot of state setup and bookkeeping. Not really something you can wrap as a relatively simple python API for someone to do quick experiments with.
I did some other completely random, definitely not recommended, stuff in Blender like this camera motion tracking thing which would rotate the viewport as the camera moved and have the camera video as the background (also using the python GL module) to reproduce this paper I found on the interwebs. I also found the Clippy sprite sheet but decided that was probably a bridge too far even though it wouldn't have been too hard.
So, yeah, if you want your program to be crazy extensible a simple API is probably the best. Might not matter too much these days as you can just get the robots to do the hard work.
[0] I heard they were going to rip it out but haven't checked if they ever did
I am a fairly novice 3D programmer (but experience programmer) and Vulkan is much more complicated compared to OpenGL to even get the basic triangle working.
The basic idea was that you trade more upfront work against a much leaner and efficient render loop, which on its own isn't a bad idea (all modern 3D APIs do that). In Vulkan this idea is just badly executed (e.g. look at Metal for a much better - and much more programmer-friendly - implementation of that same idea).
I understand that. As someone that is doing this stuff for fun and wants something cross platform (Windows/Linux/BSD, I don't care about macs) with native code (C/C++) it just raises the bar a bit too high. I am sure I could figure it out, but it easily doubles the time needed to get going.
Perhaps because you should be using some kind of low/mid-level graphics engine. That's part of the difference between OpenGL and Vulcan: that ogl did more for you, even in immediate mode. Vk came about because getting more performance out of ogl was becoming difficult because it didn't directly expose enough of modern hardware, or only exposed it in a specific less-performant way.
Yes, it takes way more code to start from scratch on vulkan, but that's a trade-off against being able to better optimize exactly to your use case, if you need to.
I am burned out by frameworks in my day job which is basically working in full stack web land and I want to get away from that. So using anything other than libraries is out of the question as far I am concerned. I could have use Unity / Unreal and been further along, but it isn't going to be enjoyable.
I understand there are situations where more performance is desirable and that vulkan fills that niche. However if you are building simpler games, are you really going to need it? If I am building say a puzzle game, do I really need maximum 3D graphics fidelity and performance? I would argue probably not.
I am using OpenGL in my projects for now and if I feel the need to learn Vulkan I will. Almost all the materials online for OpenGL 3.3 are still relevant and unlike web world (where things are depreciated every 6 months) the code still works fine. The C++ linter / analysis tools I am using with CLion throw up warnings but these are normally fairly easily to fix.
Perhaps that is the problem, for any new general GPU API to get industry traction, driver, and os + tool support -takes a lot of time, and it feels obsolete by the time it is put to practical use.