-
BabylonJS
Babylon.js is a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.
We investigated this many years ago:
https://github.com/BabylonJS/Babylon.js/
1. It works just fine for basic 3D functionality, but has limited support for tricks like fog FX etc. WebGL is actually quite capable when combined with simplified physics engines, and animated mesh packing formats.
2. In a business context it fails to check all the boxes, as people are not going to invest in a platform with near zero IP protection.
3. Steam + Unreal has all the advantages, and none of the problems/overhead of a Browser. i.e. peoples game pads, spacial audio, and shader cache buffers will work properly.
WebGL is just hitting the same VRML market that failed decades ago for the same reasons. =3
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
> Here's an example of Bevy WebGL vs Bevy WebGPU
I think a better comparison would be more representative of a real game scene, because modern graphics APIs is meant to optimize typical rendering loops and might even add more overhead to trivial test cases like bunnymark.
That said though, they're already comparable which seems great considering how little performance optimization WebGPU has received relative to WebGL (at the browser level). There are also some performance optimizations at the wasm binding level that might be noticeable for trivial benchmarks that haven't made it into Bevy yet, e.g., https://github.com/rustwasm/wasm-bindgen/issues/3468 (this applies much more to WebGPU than WebGL).
> They're 10k triangles and they're not overlapping... There are no textures per se. No passes except the main one, with a 1080p render texture. No microtriangles. And I bet the shader is less than 0.25 ALU.
I don't know your exact test case so I can't say for sure, but if there are writes happening per draw call or something then you might have problems like this. Either way your graphics driver should be receiving roughly the same commands as you would when you use Vulkan or DX12 natively or WebGL, so there might be something else going on if the performance is a lot worse than you'd expect.
There is some extra API call (draw, upload, pipeline switch, etc.) overhead because your browser execute graphics commands in a separate rendering process, so this might have a noticeable performance effect for large draw call counts. Batching would help a lot with that whether you're using WebGL or WebGPU.
