Unity is not a free standard with multiple implementations. Unity doesn't support a plurality of programming languages, while it's the goal of the garbage collected WASM. Unity is higher level in the stack, and could be executed on top of WASM and WebGPU. The work of making GCd WASM (which could interface with browser APIs without an overhead) and WebGPU fast is ongoing.
Not all games need "to take advantage of 2022 hardware in 2022, with 2022 3D API". A good plenty would look fine with a middling level of graphical fidelity or "latestness" of employed GPU features. Using the web platform you also free yourself of gatekeeping, cut taking middlemen. So there is a niche for both WASM and WebGPU.
So in your world there are only games employing the latest features, and "retro" games from the 80s and the 90ies, and nothing else? Ok.
As far as I know WebGPU doesn't lack any significant features beside raytracing (They are prioritizing the MVP, and raytracing could come later). Some of the newest features like mesh shaders are not yet supported by the native engines either, because there isn't a sufficient hardware base. Intel for example will support mesh shaders only in the yet to be released Alechemist GPU.
I think one big difference with WebGL and WebGPU is that WebGL was never really a target that you'd use for native applications. I've never heard of WebGL running outside of a browser (you'd use OpenGL ES for that), whereas I think native WebGPU has the potential to end up being the OpenGL replacement people have been asking for for years.
It definitely won't kill Unity or Unreal, but I have hopes that it will make developing without a ready-made engine a bit more attractive at least!
> - "Use this game engine or this old and outdated graphics library instead"
That is the actual answer for when people ask that question, most of the time. Almost nobody is asking for a raw GPU API, which is what Vulkan, DX12, and WebGPU are. Rather they want a graphics API. Something that provides utilities and helpers. Something that can actually load textures, models, and animations. Or has a particle effect system.
But if all you want is a GPU API, as I mentioned far higher up in the thread there's no shortage of those today either (like bgfx, or even Angle). 'native' WebGPU isn't addressing some unserved market here.
Although if you actually do want a GPU API, there's also a good chance you actively don't want to use a middleware like WebGPU since it limits what you can do and gets in the way...
bgfx is definitely a competitor in that sense. However, it doesn't have the same backing, is not standardized, and would have a hard time building momentum due to that.
I'm mostly thinking of indie game devs who decide to write their games from scratch (which still happens, though it's becoming rare), or up-and-coming game engines such as Bevy. They might not have a team who can spend the time optimizing Vulkan (while also making sure MoltenVK runs it fine, if they want to target MacOS), and might prefer something more modern than OpenGL.
>WebGPU since it limits what you can do and gets in the way
>Castrated by the security constraints of being a MVP 1.0 API to fit into the security sandbox of a Web browser.
What security contraints are you thinking of which are making it castrated? In what meaninful ways is it castrated?
> In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
So with Qt, can I write a complete renderer with advanced techniques, and have it run on all 3 platforms without changing a single file? If not, how is it relevant to even mention?
Here is a little secret, thanks to extension spaghetti and driver bugs, there is seldom "without changing a single file" unless it is some toy app, instead of being used across all possible consumer hardware.
Plus you are focusing too much on Qt while being defensive for WebGPU on native deployments, there are plenty of other middleware I can use as example.
What are you talking about? Are you saying that https://doc.qt.io/qt-6/qsgmaterialshader.html is less "castrated" than WGSL ? Doesn't look like it. I don't even see the spec, it only says "Vulkan-style GLSL"
>Here is a little secret
Google and Apple definitely have more resources to spend standardizing WGSL (WebGPU has a Conformance Test Suite) than whoever owns QT this time of the year.
> while being defensive for WebGPU on native deployments
Because I still haven't heard a single argument against it from you that isn't extremely vague and handwavey.
For example, you skipping over my questions regarding more details on what you think makes WebGPU bad/castrated, or what is making Qt the better choice over WevGPU? (ignoring the fact that Qt doesn't seem to have a common shader language)
I'm open to hear the reasons, but it seems like your goal is to be contrarian.
There's a multi-billion market for hyper casual games, and double so if we include slightly less casual games.
And since you need to be Epic or a multi-million funded team with big scale to do an AAA game, but everybody could do a casual (and even more a hyper casual game), I'd say the latter is smarter than sneering on simpler games...
You might not care for those, but billions do. Heck, Wordle could make 10 times the money an average FAANG made in their whole career if it chose so...
