I noticed the fox demo's wasm_example_bg.wasm is 22MB. That seems large? Is there code splitting?
Also, seems streaming is broken:
wasm_example.js:285 `WebAssembly.instantiateStreaming` failed because your server does not serve wasm with `application/wasm` MIME type. Falling back to `WebAssembly.instantiate` which is slower. Original error:
TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
Turns out we weren't optimizing these builds for size. We just merged a fix! We've also set the right content type on cloudflare to enable streaming/compression. The raw size is down to 13mb and the actual download size (with compression) is now 3.9mb.
https://github.com/bevyengine/bevy/pull/8636
Not that it's a race, but how far "ahead" is Godot?
I'm really hoping for Bevy and/or Fyrox catch up to Godot. I like all three, but having a Rust ecosystem for gamedev will be a game changer. Especially if they eventually garner the same kind of support that Blender has.
I'm one of the maintainers of Bevy. In my opinion, Godot clearly has a significant lead in many fronts, some moreso than others. A clear few that are lagging behind are:
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.
This question might be a little less fair -- what's the state of Bevy vs Fyrox?
And if you have a guess, how long will animation and editor support take? A wild guess is fine (though if you break out animation a bit, I'd be grateful).
Fyrox definitely has a better end-to-end feature offering right now, but I personally think Bevy has the stronger ecosystem.
Animation support is growing rapidly. I'm one of the two SMEs (subject matter experts) focused on this area, and we just rounded out the final parts of the animation composition RFC. I'm hoping to get that feature to land in 0.11, but may take until 0.12 to be fully available. There's also an open PR for animating morph targets, the primary other way of deforming meshes for animation, which I think should land in 0.11. I'm also working on inverse kinematics implementation, which should round out the core "animate to move things" features. More powerful animation features are likely going to be reliant on an editor going forward though.
The editor is definitely something we're pushing hard on. Cart recently just opened a PR rewriting the asset system to better support preprocessing and more complex asset interactions, something we desperately needed for the development of an editor. I'd like to say we'll break ground on the editor before Q3 of this year, but that might be an overaggressive target.
How are you finding webgpu compared to it's other sibling APIs?
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.
I'm a frequent contributor to the rendering parts of Bevy, so I can give you my personal opinion on wgpu/webgpu. Feel free to ask me to go into more detail on anything, or ask follow up questions. GPU programming (both shaders and the host CPU-side API) are complex - they're nothing like typical CPU programming.
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.
This is pretty much aligned with my feelings as well. I think wgpu was by far the right call. Pretty much all general purpose engines have some form of generic "gpu device" api. wgpu solves that space quite nicely and in a more complete way than some of the other approaches in the space. It defines a default, relatively modern feature set that when targeted will work on pretty much anything. And it provides a capability detection / opt-in-feature API that allows us to expose and access other APIs we might need.
It helps us embrace Bevy's core "engine features look like app features" mentality: the APIs we use to implement renderer features are the same APIs that Bevy plugin developers use to implement renderer features.
Not my personal immediate priority, but one of our ECS SMEs (subject matter experts) is currently experimenting with relations. The earliest it would land is probably two releases from now (around 4 months from now), but it could be longer. There is lots of demand for relations (or something like them), and our ECS dev team is very interested in building them. This will almost certainly happen in the "medium term".
(subject matter expert: a formal role in the Bevy project for experts in an area that have a say on big/controversial changes)
Hey! What's the state of audio for web?
Also, roughly two years ago when I ran Bevy on ARM hardware, I found a lot of operations were more CPU/thread bound than I had anticipated. I'm curious what work you may have done since (and have planned) to improve performance.
And lastly, thank you for your contributions, IMO Bevy has been a massive driver of visual/game efforts for Rust!
From the API documentation, audio looks pretty barebones (e.g. I don't see anything about any synthesis or filtering nodes, so it seems to be limited to loading audio files), but the inclusion of a SpatialAudioSink is encouraging.
there's also the option of using a different audio engine, if you're looking for a specific feature. for example bevy_kira_audio does this, though it may also be lacking the advanced features you mentioned.
Yup currently pretty simple. You can play as many sounds as you want and control playback (pause/play, speed, volume) for each instance of a sound being played. We support spatial audio.
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.
Bevy is a super interesting project. We are considering it for an RTS game.
I know that some efforts have been made to make Bevy deterministic. Which would be great and allow RTS games. Cross-platform determinism is not necessarily needed or wanted. Determinism on AVX2 would be fantastic. What is the plan for determinism?
I want to do a custom imposter-based rendering engine to handle particle systems (actually little “spheres” representing atoms in a molecular simulation) in the hundreds of millions.
I want to try out bevy because I’ve heard it is very modular so it would be easier to swap out stuff like this. What part of bevy would I need to look at modifying to support this?
Everything in Bevy is organized as a plugin. Bevy's asset crate (bevy_asset) for instance exports the AssetPlugin, itself comprised of more sub-plugins. Bevy's rendering infrastructure is split into the following crates/plugins, each building on the layer below it:
- 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.
Thank you! I just started with bevy this week, and it's a bit overwhelming, but in a weird and mostly good way. The way components and systems work is fucking magic, the kind of stuff you'd expect of Rails or Django, but not in a real-time framework in a systems programming language.
The good is that whole applications can be written in just a handful of mostly declarative code, which is absolutely amazing! The bad is that with all the magic being handled by macros and back-end event processing loops, it can be a little intimidating and not obvious how it is constructed under the hood. I would love to see a class diagram showing both the extant objects and their types, and the control flow during a frame update.
But anyway, thank you for all your hard work and for the response. Now I know where to go first in the source code to do what I need to do.
> 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.
> 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.
Any plans to extract the core ECS functionality out of bevy_ECS and create a bevy_core or something along those lines with no_std (alloc is fine) support, so we can use it to target some console platforms? TY!
This isn't a high priority for us as Bevy relies on std for a good chunk of its features and dependencies. Any Bevy console ports would likely rely on an std implementation on that console. Which specific consoles are you considering that have these constraints? To my knowledge std ports are viable for the popular consoles.
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.
Fair enough, thanks. I don't think there's a pressing/mainstream ask that justifies the maintenance burden that I imagine this would cause. I've seen people mentioning sparingly that they'd like to use Bevy for Xbox and Playstation development. Another cool use case was to use Bevy with crankstart to develop games for the Playdate with Rust. Again, probably not sufficient demand beyond curiosity or a hobby.
Bevy is a really cool project. Are there any AAA game studios looking at using Bevy or even Rust in general for their gamedev projects? As far as I can tell, gamedev is still heavily dominated by C++.
Not currently. Rendering is provided by the wgpu library, which wraps vulkan/directx12/directx11/webgpu/metal/opengl es/webgl2. No webgl1 support. If wgpu gained webgl1 support in the future then bevy would too, but it's unlikely imo. Webgl2 is already extremely limiting as it is (no storage buffers/textures, no compute passes).
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.
Unfortunately those APIs are pretty ancient. Even if Bevy were to provide a renderer targeting those, it would end up being _much_ more limited. DX11/GLES 3/WebGL 2 are already pretty limited targets.
We simply don't have the contributors to create and maintain such a renderer, at least at the moment.
Just chiming in to say I started learning Rust because I wanted to try out Bevy and so far it's been a great experience. The Discord community is especially vibrant. The hardest parts have been learning ECS at the same time as a new language/framework and how quickly updates are released which invalidate old information (including asking ChatGPT questions and getting stale info)
Overall though I haven't regretted the experience at all. If anyone is on the fence about playing around with Bevy I'd encourage you to jump on in.
Intriguing development! It's quite refreshing to witness Bevy hopping onto the WebGPU bandwagon. I can't help but wonder about the complexity involved in transitioning an existing codebase from WebGL to WebGPU in such a compressed timeline.
On a similar note, Ambient (https://github.com/AmbientRun/Ambient) has been on my radar for their utilization of WebGPU, though they seemingly lack a tangible web demo. Anyone have any insights or comparisons to share?
thanks to Bevy already being built on the wgpu Rust crate, which implements a API similar to WebGPU but with many different backends, Bevy never really interacted with WebGL directly. in fact, the PR to add WebGPU support was not that large, with as far as i can tell most changes consisting of initialisation code being moved around.
https://github.com/bevyengine/bevy/pull/8336/files
