glTF is not a very optimal runtime format, and IIRC it even started out originally with the statement that it was 'purely for interchanging models between programs' and that engines would/should still use their own format (hence the Transfer Format in the glTF name.)
Even GLB, the binary glTF format, is very sub-optimal for runtime. It even has chunks of JSON embedded in it.
glTF wouldn't be my first choice for a runtime format but it's hard to see the intent behind it as anything but a runtime format, there's a very distinct mapping from glTF concepts to OpenGL concepts. The first version didn't even have a standard material definition, the asset just had an inlined GLSL shader to render it with. They even use the same enum values so that you can plug the values in the glTF file directly into an OpenGL call if you want to.
Marrying the format so closely to OpenGL is looking pretty dated now of course, with OpenGL/WebGL dead and buried by Vulkan/WebGPU. You can render glTF with Vulkan/WebGPU but the flexibility of the format and the newer APIs rigid pipeline layouts are at odds with each other - ideally you want the data to follow a consistent, rigid layout.
Vulkan requires everyone to be a driver writer before they can even think about drawing a triangle, while at the same time already beating OpenGL with spaghetti extensions at the rate it is getting new ones every month.
And it is only a GNU/Linux and Android thing anyway, not the main API on PlayStation, XBox, Apple, Windows and Switch.
WebGL took a decade to be fully adopted, WebGPU has at least another decade ahead of it until it becomes fully widespread, and even then it will be targeting 2015 hardware capabilities.
>Vulkan requires everyone to be a driver writer before they can even think about drawing a triangle
No different than DX12/Metal. these new APIs were made because driver writers need more power. But that means the usage will be niche, either for top companies who can throw money to find driver writers or hobbyists who invest in the future (or become headhunted by said top companies).
>And it is only a GNU/Linux and Android thing anyway, not the main API on PlayStation, XBox, Apple, Windows and Switch.
To be fair, OpenGL was never the main API for Xbox/Apple/Windows to begin with. And it's been several generations since Playstation/Switch really endorsed OpenGL. I wasn't expecting Vulkan to change that overnight.
That said, Nintendo does seem to welcome Vulkan more warmly than Sony has. So that's one more major player.
> No different than DX12/Metal. these new APIs were made because driver writers need more power. But that means the usage will be niche, either for top companies who can throw money to find driver writers or hobbyists who invest in the future (or become headhunted by said top companies).
The BIG difference is that DX12, Metal, LibGNM(X) and NVN come with productive SDKs, documentation, IDE tooling, frameworks, in a big support package.
> To be fair, OpenGL was never the main API for Xbox/Apple/Windows to begin with. And it's been several generations since Playstation/Switch really endorsed OpenGL. I wasn't expecting Vulkan to change that overnight.
OpenGL was definilty the main API on Apple platforms after OS X was introduced with its NeXTSTEP roots, and if it wasn't for Apple endorsing GL ES on the iPhone, no one would have cared.
Symbian did support it, but it wasn't until Asphalt on N95, that it mattered, given that it was doing software rendering on most devices.
> That said, Nintendo does seem to welcome Vulkan more warmly than Sony has. So that's one more major player.
While the Switch supports GL 4.6 and Vulkan, it is NVN, what most studios actually use.
>The BIG difference is that DX12, Metal, LibGNM(X) and NVN come with productive SDKs, documentation, IDE tooling, frameworks, in a big support package.
well of course. they are closed off (in both source and general tribal knowledge. Hell, the docs for GNM/NVN aren't available without a license), locked down to one platform each, and their customer base is overwhelmingly enterprise. And each has a dedicated full time team to consult with. It's no surprise they can give more focused suites when their job is more or less to wrap you into their respective ecosystem.
If you are fine focusing on one platform, or relying on a huge library/framework/engine to abstract all these APIs for you (which remember, you need to provide some license for, except DX12. So another barrier), you can get a bit more convenience. But if you can't use those and/or want to target Linux/Android, you lose some of that for a more flexible, agnostic API (and probably some small performance hitches on the highest end. Vulkan can't assume 2-3 configurations like Gnm/NVN after all).
>if it wasn't for Apple endorsing GL ES on the iPhone, no one would have cared.
Well, Apple at the time basically made people care about mobile graphics at all, so you are technically right. But they could have raised Glide from the dead and made that matter for all the early control they had.
Apple certainly does have a rich history with OpenGL, but we all know how that eventually ended up. It was a long time coming but the breakup was much more spontaneous than I ever would have guessed. Definitely seems to be more than technical shortcomings behind that story.
Even GLB, the binary glTF format, is very sub-optimal for runtime. It even has chunks of JSON embedded in it.