Vulkan 1.2
khronos.org
khronos.org
Talk by the same guy at GDC about porting Doom 3 to Vulkan and Stadia: https://stadia.dev/intl/en/blog/gdc-2019-session:first-light...
The returns will diminish to the point that porting or developing on new APIs does not pay for itself.
I know both Jonathan Blow and Godot are clear signs that I'm wrong, but I guess we'll just have to wait and see.
Until then I have my engine running on Win/x86 and the Pi 4 at good performance with minimal effort.
Which is good; simple software will live forever.
My favourite of the newest APIs is Metal, because it's very easy to jump from OpenGL (triangle in Metal is about 30 lines of code). Perhaps WebGPU is an alternative once desktop translation layer is created (Google is working on one called Dawn).
Dawn and wgpu have also been collaborating to create a common set of WebGPU headers. The WIP headers are located at https://github.com/webgpu-native/webgpu-headers if you're interested in contributing or following.
1: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl...
I have written a bit of Vulkan code (i wrote this[0] the day the spec came out, after banging on it for several hours - and i found the spec quite readable, at least from the side of someone who wants to use it... someone i know who worked on the implementation side has told me that it wasn't that great), but i find the API way too ugly and verbose for my taste.
I have considered writing a small OpenGL-like wrapper on top of it since i am concerned that OpenGL quality will deteriorate in the future (though that would break a TON of games, including the ultrapopular Minecraft), but for now things work fine.
OpenInventor could have been it, but SGI had other plans for it, and no one at either ARB or Khronos actually cared about it.
Though i disagree with OpenInventor, it is too complex and takes too much upon itself, which few wanted - see Direct3D Retained Mode which despite being a much simpler API (both compared to D3DIM and OpenInventor) didn't see much use and in an uncharacteristic move by Microsoft (especially at the time) it was removed from Direct3D.
A better solution would have been something like GLUT, but with a few more utilities thrown in (like vector math stuff - OpenGL implementations already have the code anyway, why not expose it?). And GLUT was more popular than OpenInventor ever hoped to be despite not offering more than a few basic things.
The ones that don't use one, end up reimplementing their own scene graph anyway.
As for the rest, full with you.
OpenGL, Vulkan and Direct3D are at a level where they enable you to write your own engine, but not at the level where they provide your the engine themselves. Microsoft tried it with Direct3D RM and it didn't work and Sun also tried it with Java3D as the official way to do 3D in Java but also didn't catch on (it caught on more than D3DRM but that is mainly because there was no other official way - however its popularity paled in comparison to OpenGL bindings that appeared soon after and nowadays it has been reimplemented and lives on top of these bindings).
Writing vulkan for a quick hobby project is probably a bit much, but it seemed like a great choice where extra control is needed. Hopefully more libraries will mature take care of the dirty work (thousands of lines of initialization).
OpenGL's original design was a "fine grained state machine" which doesn't map well to modern GPU architectures, and every time a "micro state" in that big state machine is changed the GL driver needs to translate that change into much coarser state that GPUs accept. But it turns out that many 3D application don't even need to change unique states one by one, so each frame your code translates mostly static and coarse "application rendering state" into GL's fine grained state, only to have the GL driver translate that fine grained state back into coarse GPU state.
That's just one piece of the puzzle but I think explains the motivation behind the modern 3D APIs best.
The "other" 3D-API, Direct3D already took steps to group fine grained state into coarser state (starting with D3D10 and D3D11), the problem there was that they didn't come up with a good solution for threaded rendering (generating rendering work on different CPU threads), that's the other big thing that the modern 3D APIs solve properly. You essentially build render command lists on multiple CPU threads, and then enqueue those command lists on the main thread to be processed by the GPU.
[1] https://www.gamedev.net/forums/topic/666419-what-are-your-op...
https://www.khronos.org/registry/vulkan/specs/1.2-extensions...
I guess this will first be elevated to a vendor-neutral extension and (I guess) eventually will move into the core API.
If you are interested, a friend of mine and a few coworkers pieced together a small proof-of-concept game engine in their spare time that uses Vulkan ray tracing on Nvidia RTX cards. They finally released it on GitHub a few days ago:
https://github.com/W4RH4WK/Raygun
I also submitted it on HN, but with little interest so far: https://news.ycombinator.com/item?id=22037474
OpenGL got lucky with Doom and Carmack's charisma, followed by Apple's decision to adopt it alongside NeXTSTEP.
Copland was going to use QuickDraw 3D.
Good idea too. Make it clear that they are doing things differently.
...not talking about the idea to first test out new ideas in vendor-specific extensions, and then elevate them to the core, this is definitely a good idea - but about stacking new stuff on the previous API version, this approach is what turned OpenGL into the heap of accumulated cruft it is today.
Direct3D instead was a new API with each new major version, which in the beginning sounded insane, but turned out the better decision in the end because that made it possible to discard the cruft (the crucial part is that old API versions are frozen but still supported).
Direct3D is mostly used for games so if your new game has to use a new API that's not _that_ big of a deal. You don't start from scratch every couple years with regular software though.
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.
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.
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.
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.