Bevy and WebGPU

Pros:

- Compared to OpenGL, WebGPU is wayyy better in every way

- Compared to Vulkan/DirectX 12/Metal, WebGPU is 0.5-1 steps higher level (easier to use), and covers macOS/iOS without needing a separate Metal backend

- We get WebGPU (browser) support for free, as mentioned in this post :). wgpu also gives us WebGL2 for free (provided you don't use certain features) which we're using to target browsers until WebGPU is more fully supported.

- WGSL (the shader language) is actually fairly nice coming from Rust, compared to the more C-style GLSL/HLSL

Cons:

- We're leaving performance on the table due to WebGPU validation / extra work it needs to do to abstract differences between platforms and be higher level than the APIs it wraps. Not the worst thing in the world, but it's a downside. Probably can be alleviated on non-browser platforms with opt-in relaxed validation and lower level APIs (wpgu-hal).

- Library/tooling maturity is much worse. Wgpu/naga (the WGSL shader compiler) frequently have bugs (less now than they used to), and error messages leave much to be desired. Shader tooling is much worse - we've had to build our own shader import system, syntax highlighting is provided by a non-bevy VSCode extension someone on the internet kindly maintains, GPU debugging tools don't have source-level info for WGSl shaders, etc. Again this will get better over time.

- We can't access all the latest features. Things like raytracing, subgroup/warp/wave operations, binding arrays, etc. That said, wgpu does provide native-only extensions for some of these. Support inevitably trails behind Vulkan/DirectX 12 though. Not really a huge deal for the most part, but I personally do miss this. Again will get better as wgpu/webgpu finalize and more time can be spent extending the spec with newer features.

- I've left this for last, but the explicit binding model sucks. WebGPU is fairly high level, but keeping explicit binding instead of requiring binding arrays is awful. Every time you want to add a texture/buffer/etc to your shader, you need to modify the bind group layout, modify the bind group, and then modify the shader, and keep those definitions in sync. When you have multiple pipelines, bind groups, shaders, and modular systems that only need certain resources under different conditions or certain parts of different shaders, it's just awful to keep track of. The ergonomics are terrible. I wish WebGPU would've required binding arrays and just accepted losing support for some older devices. In Bevy we plan to write an abstraction that acts more like binding arrays and falls back to explicit bindings where needed, but that's still a lot of work.

Overall, I generally think wgpu was/is the right choice for Bevy. The ergonomics could still use work, we leave performance on the table, we don't get all the advanced and new features, and the growing pains were (and still are, to a lesser degree) real. But we still get better ergonomics compared to other options, WebGPU support for browsers, 1 rendering backend vs at least 3 (Vulkan/Metal/WebGL2), and the rest of the issues are fixable over time and with more work done on both Bevy's side and the library and tooling side.

Sometimes I wish we went with just Vulkan+Metal and could drop down to lower level stuff, get access to new features, and just generally not have to deal with extra layers and immature tooling. But I still think it's the right choice for the project overall. Discalimer: just my own opinion, I don't represent the project.

> Also, have you thought of teaming up with anyone who is explicitly teaching webgpu / wgsl? Seeing someone create a rust perspective course on learning webgpu could be nice.

Learn wgpu (https://sotrh.github.io/learn-wgpu) provides a nice intro to WebGPU/WGSL. I don't think there's really anything Bevy specifically would be able to provide. Once you wrap your head around the APIs themselves, generally the hard part of graphics programming is dealing with the boilerplate, and the actual 3D rendering techniques themselves irrespective of the API you write in.

That said, there's a few improvements I've though about contributing to learn wgpu to cover the more advanced side of things (compute shaders, storage resources, alignment rules, etc), but I haven't had time lately.

https://docs.rs/bevy/latest/bevy/audio/index.html

Biggest missing piece is an "audio bus" API with effect stacks. For that, plugins like bevy_kira_audio already do a good job. And we'll get there eventually with our official plugin.

What is your use case for needing webgl1?

Bevy is also extremely modular. If you absolutely need webgl1 support, you can implement it yourself as a plugin without losing the rest of the non-rendering parts of bevy like audio, input, the core ECS of course, etc.

- bevy_pbr: Bevy's standard physically-based renderer. Provides PBR shaders, user-extensible materials, as well as APIs for organizing draw calls and rendering.

- bevy_core_pipeline: Defines some standard rendering setups like "2d" and "3d - Opaque, transparent, etc", with the goal that you could plug your own wgpu-based renderer into this layer. Also currently holds all of our post-processing effects (TAA, tonemapping, bloom, etc).

- bevy_render: One part wrapper/helpers around wgpu, one part generic renderer utilities like a render node graph and 3D camera types.

There's also some extra crates I didn't cover like bevy_sprite for 2D, bevy_ui for UI, etc.

If you want to build a wgpu-based renderer, you have a couple of options depending on what kind of rendering you need. You can plug in your own custom renderer instead of bevy_pbr using bevy_core_pipeline. You can still use bevy_pbr and just add your own render nodes on top of it. Or, you can ditch wgpu/bevy_render completely and build everything from scratch (at the cost of losing UI/2D support).

Anything you do would take the form of a custom plugin. Bevy is extremely modular - plugins are how we organize and develop the engine itself, so removing certain rendering plugins and adding your own is easy.

EDIT: I encourage you to join Bevy's discord channel and discuss your project in the #rendering channel, it's much easier to provide help and give info than over a forum.

Editor: Godot has one, Bevy does not. Animation support: Godot has support for complex animation blending and animating anything that can be serialized. Bevy does not. Audio: Bevy's audio is pretty simple right now and lacks direct world entity driven spatial audio. Rendering: Godot has pretty deep support for higher performance and higher fidelity rendering techniques like automatic instancing and

Everything in this list is being worked on, but require time to bake. Everything else more or less has most of the core pieces in place that Godot has, though may be missing a few small features here or there.

Where is Bevy ahead?

Multithreaded CPU performance. I can almost guarantee your average Bevy app will have higher thread utilization than your average Godot/Unity/Unreal game, and this will continue to scale as more complex computations are required for various engine systems are added.

Testability: ECS makes it really easy to write dependency injection based unit tests, something otherwise difficult to test end-to-end with engines like Godot and Unity.

Extendability and customization: Bevy is plugins all the way down. Godot definitely takes a much more monolithic approach to building an engine, and making significant changes to the core engine will require forking. Where Godot requires exposing deeper APIs for exposing functionality, Bevy already supports ripping out the relevant plugins and subsituting just those with your own.

Memory safety: As the mantra goes, every 1k LoC of C/C++, there's one CVE that is yet to be found, and 70% of those are memory safety issues. Bevy heavily leverages unsafe in the ECS, but rarely touches it in the other core engine crates. We can with high confidence say there are no memory safety problems or problems caused by undefined behavior in Bevy due to Rust's strong safety guarantees.

(subject matter expert: a formal role in the Bevy project for experts in an area that have a say on big/controversial changes)

If theres enough demand we could probably port bevy_ecs on its own to no-std, but that would add more code and maintenance burden so I'd be a bit hesitant to merge such a port.