3 ms·

I am going to respectfully disagree with you here. Yes, Vulkan is a difficult API to work with and it's not at all beginner friendly. But simplicity and ease o

by exDM69 10y ago

I am going to respectfully disagree with you here. Yes, Vulkan is a difficult API to work with and it's not at all beginner friendly. But simplicity and ease of use should not be guiding the decisions, the emphasis should be on providing a way to run Unity, Unreal, and other engines (new and old) on the Web. Even if Vulkan is a difficult API to work with, a low level 3d API should be available in a browser. It could be used as a building block to create frameworks and engines that are easy to use. Even WebGL is "too low level" for most application developers, which is why three.js and other frameworks are popular.

flohofwoe 10y ago
Yes there are also valid points for having an really low level 3D-API like a WebVulkan in the browser, and the 'big-engine-makers' seem to be fond of this idea. But I see this more in the realm of a 'compilation target', more for WebAssembly then JS. Translating Vulkan 1:1 to D3D12 or even Metal would be challenging though, I think most of the advantages of having a real bare-metal API would be lost in this translation-layer I guess.
- grovesNL 10y ago
  The Altai example is great but they can already be implemented in JavaScript with very low overhead. If the performance is a concern then we should be moving more towards lower level APIs such as Vulkan, and let JS libraries implement their own API on top of that when that extra performance is needed. There is also the possibility that performance improvements to WebGL could always be made (i.e. supporting command queues or SPIR-V).
  - flohofwoe 10y ago
    I think that Metal / WebGPU is just at the right abstraction level for a modern 3D API. It's like a successor to D3D11 (which is a mighty fine 3D-API). Vulkan and D3D12 are really not a lot of fun to work with. I'd rather maintain an thin API wrapper on top of 3 different 3D-APIs at the complexity level of D3D11 or Metal, instead of having to maintain a single wrapper for D3D12 or Vulkan (and you need to support multiple 3D APIs anyway, since none of them exists on all relevant platforms). But that is strictly IMHO, I guess there's also people who enjoy working in D3D12 or Vulkan ;)
    - exDM69 10y ago
      The problem with the WebGpu proposal is that it is difficult to implement with Vulkan efficiently as the spec is now. I'm sure the spec can still be changed to be a better fit, though.
cwyers 10y ago
It's not about being too low-level for developers, it's about it being too low-level for implementation. Vulkan is lower level than DX12 or Metal; you can't implement it on top of those platform APIs, like ANGLE runs OpenGL ES on top of a compatibility shim over DirectX or desktop OpenGL. A cross-platform graphics API in the browser needs to be high-enough level to abstract over all of Vulkan/DX12/Metal and provide a consistent interface so that developers don't have to know which one their application is running on. Either that, or in addition to WebVulkan you need WebDX12 and WebMetal.
- erichocean 10y ago
  > you can't implement [Vulkan] on top of [DX12 or Metal] http://lmgtfy.com/?q=vulkan+metal http://lmgtfy.com/?q=vulkan+metal First result: "MoltenVK is an implementation of Vulkan that runs on Apple's Metal graphics framework on iOS and macOS."

by exDM69 10y ago

flohofwoe 10y ago

Yes there are also valid points for having an really low level 3D-API like a WebVulkan in the browser, and the 'big-engine-makers' seem to be fond of this idea. But I see this more in the realm of a 'compilation target', more for WebAssembly then JS. Translating Vulkan 1:1 to D3D12 or even Metal would be challenging though, I think most of the advantages of having a real bare-metal API would be lost in this translation-layer I guess.

grovesNL 10y ago
The Altai example is great but they can already be implemented in JavaScript with very low overhead. If the performance is a concern then we should be moving more towards lower level APIs such as Vulkan, and let JS libraries implement their own API on top of that when that extra performance is needed. There is also the possibility that performance improvements to WebGL could always be made (i.e. supporting command queues or SPIR-V).
- flohofwoe 10y ago
  I think that Metal / WebGPU is just at the right abstraction level for a modern 3D API. It's like a successor to D3D11 (which is a mighty fine 3D-API). Vulkan and D3D12 are really not a lot of fun to work with. I'd rather maintain an thin API wrapper on top of 3 different 3D-APIs at the complexity level of D3D11 or Metal, instead of having to maintain a single wrapper for D3D12 or Vulkan (and you need to support multiple 3D APIs anyway, since none of them exists on all relevant platforms). But that is strictly IMHO, I guess there's also people who enjoy working in D3D12 or Vulkan ;)
  - exDM69 10y ago
    The problem with the WebGpu proposal is that it is difficult to implement with Vulkan efficiently as the spec is now. I'm sure the spec can still be changed to be a better fit, though.

cwyers 10y ago

It's not about being too low-level for developers, it's about it being too low-level for implementation. Vulkan is lower level than DX12 or Metal; you can't implement it on top of those platform APIs, like ANGLE runs OpenGL ES on top of a compatibility shim over DirectX or desktop OpenGL. A cross-platform graphics API in the browser needs to be high-enough level to abstract over all of Vulkan/DX12/Metal and provide a consistent interface so that developers don't have to know which one their application is running on. Either that, or in addition to WebVulkan you need WebDX12 and WebMetal.

erichocean 10y ago
> you can't implement [Vulkan] on top of [DX12 or Metal] http://lmgtfy.com/?q=vulkan+metal http://lmgtfy.com/?q=vulkan+metal First result: "MoltenVK is an implementation of Vulkan that runs on Apple's Metal graphics framework on iOS and macOS."