Bevy 0.13: ECS-driven game engine built in Rust(bevyengine.org)
bevyengine.org
Bevy 0.13: ECS-driven game engine built in Rust
https://bevyengine.org/news/bevy-0-13/
65 comments
I wrote the lightmaps, reflection probes, and irradiance volumes support for this release! Bevy has really been a joy to work with, and the community is fantastic.
I've been building My First Game™ using Bevy after teaching myself Rust last year. I feel super cool running Rust in WASM in the browser! It's been a great experience overall and I highly recommend exploring what Bevy has to offer.
The community is really exceptional. I ask questions daily and get helpful responses usually within minutes. Bevy hides some of the complexities of Rust, such as lifetimes, away from normal development. This was a pleasant surprise for someone coming in with little awareness of Rust.
Writing in ECS is pretty confusing to begin with and, IMO, represents the steepest part of the learning curve. After a while ECS starts to feel more natural though and you'll wonder why you were ever comfortable doing OOP.
The main sore spots for me are: UI needs a lot of work to be ergonomic and beautiful, there's a lot of footguns related to performance and event handling/change detection, which do have workarounds, but at the cost of ergonomics, and, specifically for WASM, everything (including rendering) is still single-threaded which makes the app perform worse than well written JavaScript for now.
I'd be happy to try and answer any questions about my experience as a complete noob to Rust/Bevy/ECS/game development and having immersed myself ~full time on a game for the past year.
FYI, you can browse my game's code here: https://github.com/MeoMix/symbiants
The community is really exceptional. I ask questions daily and get helpful responses usually within minutes. Bevy hides some of the complexities of Rust, such as lifetimes, away from normal development. This was a pleasant surprise for someone coming in with little awareness of Rust.
Writing in ECS is pretty confusing to begin with and, IMO, represents the steepest part of the learning curve. After a while ECS starts to feel more natural though and you'll wonder why you were ever comfortable doing OOP.
The main sore spots for me are: UI needs a lot of work to be ergonomic and beautiful, there's a lot of footguns related to performance and event handling/change detection, which do have workarounds, but at the cost of ergonomics, and, specifically for WASM, everything (including rendering) is still single-threaded which makes the app perform worse than well written JavaScript for now.
I'd be happy to try and answer any questions about my experience as a complete noob to Rust/Bevy/ECS/game development and having immersed myself ~full time on a game for the past year.
FYI, you can browse my game's code here: https://github.com/MeoMix/symbiants
Hey!! I’m on the same journey! Yew, but with Bevy ECS and HTML as my “rendering engine”.
Keep me posted!!
Keep me posted!!
Never dug deep into Bevy's subcrates, but does this mean you have more control from the JS side? (e.g. when I want to interlace the main loop tick with something from the JS side)
https://github.com/sanspointes/bevy-wasm-api someone in the Discord mentioned they were playing around with this idea a couple of days ago. No idea how well it works though.
Much appreciated!
Oh, I my case, I was actually creating a “headless” game, where my graphics were just in HTML and CSS because I’m more artistically enabled to make things using those instead of OpenGL!
And because I’m weird!
And because I’m weird!
Bevy's creator and project lead here. Feel free to ask me anything!
No question, just want to say thanks! I've had a lot of false starts trying game tutorials but the ones I found for Bevy were really easy to follow. I was working two versions behind and the changelog for Bevy was so well done that I was able to figure out most of what changed. Bevy was also just straightforward to use.
Are there any good "end to end" examples that show things like a splash screen, main menu, pause menu, video settings, that sort of thing?
We don't have a "complete" official example of those things, although the "game menu" example has some of that: https://github.com/bevyengine/bevy/blob/main/examples/games/...
I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4
Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4
Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
I gotta ask newbie questions.
Any concrete plans for a GUI editor?
Does stuff like Lumen/Nanite from UE5 have any chance of existing in Bevy?
Any concrete plans for a GUI editor?
Does stuff like Lumen/Nanite from UE5 have any chance of existing in Bevy?
Here are the plans for the editor prototypes: https://github.com/bevyengine/bevy_editor_prototypes/discuss...
As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality.
For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages.
[1]: https://github.com/jms55/bevy/tree/solari
[2]: https://github.com/bevyengine/bevy/pull/10164
As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality.
For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages.
[1]: https://github.com/jms55/bevy/tree/solari
[2]: https://github.com/bevyengine/bevy/pull/10164
Hi, I'm the author of both the Solari (Lumen) and Meshlet (Nanite) PRs, and I'm happy to see interest in them! To expand on pcwalton's answer:
Solari is _extremely_ experimental. I'm basically entirely scrapping my previous version[1] based on Radiance Cascades[2], and starting over with ReSTIR[3] techniques. Don't expect it anytime soon, but I'm definitely having fun working on it! The real technical blockers to Solari is that wgpu, our graphics library, does not have upstreamed raytracing support. I've been using a semi-buggy fork[4], but we'll need to get it merged before Bevy can merge any Solari code.
Meshlets (no cool product name like Solari) on the other hand are much less experimental. I already have a very functional and fairly fast GPU-driven renderer based on meshlets implemented, and mostly reviewed, and it should hopefully get merged into Bevy's main branch within a few weeks. Check the meshlet section of the "What Comes Next" section at the bottom of this post to see an image. I'm planning to do a livestreamed review session to get the PR pushed through since it's such a complex PR (thousands of lines). However, what I have so far is just the basics. Memory usage is a big issue, and lack of hierarchical LODs (the main selling point of Nanite) are not yet implemented. Further more, I'd really like to have both mesh shaders (for large triangles), and software raster (for small triangles) implemented to improve the visibility buffer raster speed. Mesh shaders are sadly not supported in wgpu, nor has anyone started a fork to implement them. For software raster, we need support for 64bit integers and texture atomics in wgpu, but that's something we're working on[5].
So yeah, lots of experimental work that's going to take a while to be production-ready and available to users, part of which will need to be working with wgpu to implement more modern features, as wgpu's current priorities are understandably focused on the WebGPU spec, which lacks the newer features from 2020+ that started shipping in the last 2-3 GPU generations. I'm having a lot of fun though, and making good progress!
[1]: https://github.com/bevyengine/bevy/pull/10000
[2]: https://drive.google.com/file/d/1L6v1_7HY2X-LV3Ofb6oyTIxgEaP...
[3]: https://interplayoflight.wordpress.com/2023/12/17/a-gentler-...
[4]: https://github.com/gfx-rs/wgpu/pull/3631
[5]: https://github.com/gfx-rs/wgpu/pull/5123, https://github.com/gfx-rs/wgpu/pull/5154
Solari is _extremely_ experimental. I'm basically entirely scrapping my previous version[1] based on Radiance Cascades[2], and starting over with ReSTIR[3] techniques. Don't expect it anytime soon, but I'm definitely having fun working on it! The real technical blockers to Solari is that wgpu, our graphics library, does not have upstreamed raytracing support. I've been using a semi-buggy fork[4], but we'll need to get it merged before Bevy can merge any Solari code.
Meshlets (no cool product name like Solari) on the other hand are much less experimental. I already have a very functional and fairly fast GPU-driven renderer based on meshlets implemented, and mostly reviewed, and it should hopefully get merged into Bevy's main branch within a few weeks. Check the meshlet section of the "What Comes Next" section at the bottom of this post to see an image. I'm planning to do a livestreamed review session to get the PR pushed through since it's such a complex PR (thousands of lines). However, what I have so far is just the basics. Memory usage is a big issue, and lack of hierarchical LODs (the main selling point of Nanite) are not yet implemented. Further more, I'd really like to have both mesh shaders (for large triangles), and software raster (for small triangles) implemented to improve the visibility buffer raster speed. Mesh shaders are sadly not supported in wgpu, nor has anyone started a fork to implement them. For software raster, we need support for 64bit integers and texture atomics in wgpu, but that's something we're working on[5].
So yeah, lots of experimental work that's going to take a while to be production-ready and available to users, part of which will need to be working with wgpu to implement more modern features, as wgpu's current priorities are understandably focused on the WebGPU spec, which lacks the newer features from 2020+ that started shipping in the last 2-3 GPU generations. I'm having a lot of fun though, and making good progress!
[1]: https://github.com/bevyengine/bevy/pull/10000
[2]: https://drive.google.com/file/d/1L6v1_7HY2X-LV3Ofb6oyTIxgEaP...
[3]: https://interplayoflight.wordpress.com/2023/12/17/a-gentler-...
[4]: https://github.com/gfx-rs/wgpu/pull/3631
[5]: https://github.com/gfx-rs/wgpu/pull/5123, https://github.com/gfx-rs/wgpu/pull/5154
Thank you for taking the time to write this up. Appreciate your work!
The blog post directly mentions efforts towards a GUI-based editor in the "What's next" section.
We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
Just to clarify, irradiance volumes (and other forms of GI added this release like lightmaps and reflection probes) are statically baked ahead of time, meaning they'll start showing incorrect lighting as you move objects and light sources around. They take time to bake (slowing down development iteration), and limit how much you can do with them / need careful usage and placement, but are widely supported, and give great results for very cheap runtime costs.
Lumen is a fully _dynamic_ GI system. No slow offline baking, and much more flexible (and therefore realistic) lighting, especially reflections. The downside is it's much, much slower (but still barely fast enough to be realtime 60fps), and requires a semi-recent graphics card that support hardware-accelerated raytracing.
As for whether meshlets or realtime dynamic GI is harder, well, I'd probably lean towards GI right now. I haven't yet started the (very complex) LOD building system for meshlets though, so maybe I'll change my mind in the future :)
Lumen is a fully _dynamic_ GI system. No slow offline baking, and much more flexible (and therefore realistic) lighting, especially reflections. The downside is it's much, much slower (but still barely fast enough to be realtime 60fps), and requires a semi-recent graphics card that support hardware-accelerated raytracing.
As for whether meshlets or realtime dynamic GI is harder, well, I'd probably lean towards GI right now. I haven't yet started the (very complex) LOD building system for meshlets though, so maybe I'll change my mind in the future :)
I can't help but feel that between events and commands, and especially with all the parallelism, there's no clean, powerful solution to manage all manner of inter-system interactions. Having .before(), .after(), .chain(), different schedules and whatnot is great, but I think there's something lacking in the model to round it all out. Granted, I'm a novice in these matters and I understand that concurrency brings many hard problems. Could you spare your thoughts on the matter? Thanks!
What did you have for lunch
Haven't eaten yet, but I'm planning on having a lentil / beef / mushroom curry I made earlier.
That sounds delicious! Recipe please ^_^ !
Pretty straightforward process / I just made it up. Throw some olive oil in an Instant Pot, add beef and sear (no need to fully cook, just brown it), add ~4 cups of water and ~2 cups of lentils (I eyeball these), throw in chopped onions / bell peppers / mushrooms / garlic, add spices (plenty of turmeric + generic store bought "curry powder", garlic powder, dill, cayenne pepper, salt), and the secret ingredient: ~1/2 cup of smooth peanut butter (trust me this is very important ... when in doubt add more).
(edit: I keep the Saute setting on while im adding ingredients and occasionally stir. Then I seal it up, turn on the "bean chill" mode on high. And wait 40 minutes for tasty goodness)
(edit: I keep the Saute setting on while im adding ingredients and occasionally stir. Then I seal it up, turn on the "bean chill" mode on high. And wait 40 minutes for tasty goodness)
Sounds delicious! Thank you so much!
> The built-in collection of primitives is already quite sizeable
And yet no teapot! Literally unusable.
And yet no teapot! Literally unusable.
In two / three years, where do you see the project?
Core pillars (including WIP things like Scene, UI, Editor, Audio) are in place. Partial or full engine stability (see my "partial stabilization discussion: https://github.com/bevyengine/bevy/discussions/9789). More than a few fully released quality games. More than a few fully released quality non-games / tools (we're already seeing Bevy being used as a foundation for things like CAD software and modeling tools).
Any idea why the example image in the OP link appears to be running at sub-optimal framerate?
What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)?
Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)?
Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
I would say that the systems in the ECS _are_ the game loop. The ECS overhead per frame is kind of hard to measure / it depends on the scale of usage. To establish the scale of operations: Random single-entity ECS data accesses are a sparse array lookup to find the table the entity is in, and then an array lookup to find the component in the table. Iterating components in a query is roughly the same as iterating an array / is very cache friendly. Running individual systems is _slightly_ more expensive than a function call. Scheduling systems in parallel does introduce some overhead (which is currently higher than we'd like / we're working on optimizing it), but when you pay that cost you get the benefits of everything running in parallel.
That is a size-optimized webp / gif that isn't running at 60 fps. The game is butter smooth in practice: https://twitter.com/jarl_game
There is still a game loop that runs every tick. The engine wouldn't work so well if we only responded to inputs as they come in, event pub-sub style.
As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
> Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
How do you plan to have stuff moving then? You need to update their position every frame, so...
How do you plan to have stuff moving then? You need to update their position every frame, so...
This looks like a really cool project!
Is it portable to Browser? Or is that on the roadmap?
Is it portable to Browser? Or is that on the roadmap?
Yup we support both WebGL and WebGPU browser deployments via WASM
Glorious. This is exciting. Looking forward to seeing youalls progress
Love the way the Bevy project is moving. In a year or two, this project will be a serious alternative to the current Unity / Unreal / Godot engines. Getting it right first is vital, and I'm glad the team is spending a lot of time perfecting the nitty-gritty details before adding features like UI / Editor / etc.
As usual bevy is moving at an impressive pace. Excited for them to break ground on the new scene/ui system
Honestly, if you wanna see impressive pace, look at Fyrox. It has had scenes and UI for ages.
While bevy is a decent piece of tech, it gets way more hype than it deserves, especially when there are more mature and capable alternatives.
While bevy is a decent piece of tech, it gets way more hype than it deserves, especially when there are more mature and capable alternatives.
Sure if you only care arbout surface level details like "has scenes" and "has a UI system".
It also has a statically typed storage for game entities, something ECS-based engines are lacking and in fact many people have tried to write an ECS wit hstatically typed entities and all (including me) ended up conclusing it's not possible in the current Rust.
Oh and if you care about "deep level details" then i can still say fyrox has better internals. I know people who have given bevy many more chances than me and each time ran into a brick wall when writing an actual game.
Oh and if you care about "deep level details" then i can still say fyrox has better internals. I know people who have given bevy many more chances than me and each time ran into a brick wall when writing an actual game.
And I know people that have used bevy to make games and liked it more than any other engine they tried before. Many people are already using it in production, there's also multiple games built with bevy released on steam with many more in progress.
It's completely expected that it doesn't click for everyone, but I don't get why you are framing it as if hitting a brick wall is the only experience that people have when making games with bevy. Plenty of people just don't like the ECS model. That doesn't mean that bevy is bad. It's just not for them. We are lucky enough that there's a great alternative in the rust gamedev ecosystem like Fyrox for those people. It doesn't have to be a competition.
It's completely expected that it doesn't click for everyone, but I don't get why you are framing it as if hitting a brick wall is the only experience that people have when making games with bevy. Plenty of people just don't like the ECS model. That doesn't mean that bevy is bad. It's just not for them. We are lucky enough that there's a great alternative in the rust gamedev ecosystem like Fyrox for those people. It doesn't have to be a competition.
An entity is just an identifier and components are statically typed. Not sure what you’re talking about here.
To the uninitiated, bevy is one of Rust's two main game engines, the other being Fyrox.
Bevy, despite being written by an army of contributors is continually behind Fyrox which is developed mostly by one guy. Fyrox not only has an editor and a UI toolkit, both of which bevy devs keep just talking about, it recently also added a UI editor. In addition the author is writing 2 games to dogfood Fyrox.
Yet despite all this, Fyrox gets a fraction of the attention and money. Maybe it's because it uses proven old tech instead of being a resaerch project, maybe it's because the author is russian, maybe because people are afraid of a 3D-first engine, maybe fyrox doesn't focus on promotion enough. Idk, but here i am doing my bit to make the world a tiny bit more fair even if I annoy all the bevy fans who kept posting about bevy on every single fyrox post that wasn't completely downvoted and ignored.
Bevy, despite being written by an army of contributors is continually behind Fyrox which is developed mostly by one guy. Fyrox not only has an editor and a UI toolkit, both of which bevy devs keep just talking about, it recently also added a UI editor. In addition the author is writing 2 games to dogfood Fyrox.
Yet despite all this, Fyrox gets a fraction of the attention and money. Maybe it's because it uses proven old tech instead of being a resaerch project, maybe it's because the author is russian, maybe because people are afraid of a 3D-first engine, maybe fyrox doesn't focus on promotion enough. Idk, but here i am doing my bit to make the world a tiny bit more fair even if I annoy all the bevy fans who kept posting about bevy on every single fyrox post that wasn't completely downvoted and ignored.
Looks to me like Fyrox is competing more with Godot or Unity, than it is with Bevy. The cool part about Bevy is its ECS handling. There aren't a lot of ECS-first game engines, and Bevy is one of the few that do exist.
Personally, I feel the real competition is the OSS Rust engines against Unity, Unreal, and to some extent Godot, rather than the competition being between Rust engines. Bevy and Fyrox are both great frameworks.
Your conspiratorial framing here strikes me as odd, as well as unnecessarily denigrating Bevy as a "research project." Isn't the answer quite obvious, which is that if someone wants to use an engine built off "proven old tech", they should probably just use one of the major players in the space, and that Bevy's uniqueness/commitment to the ECS model is precisely what causes it to generate more hype and energy? Is this really an issue of "fairness"?
> Isn't the answer quite obvious, which is that if someone wants to use an engine built off "proven old tech", they should probably just use one of the major players in the space
All of the major engines are written in C++. I've tried Unreal, Unity and Godot. They all have their flaws. With Unreal and Godot those flaws are mainly the scripting languages BP and GDScript which one can get tired of quite easily, especially BP. You can of course use C++ for all your scripting but both engines strongly encourage you to use their scripting solution for a big chunk of your game. (Unity has a bunch of other issues and isn't source available, although C# is fairly pleasant to work with IMO).
There is definitely need for an OOP engine in Rust just as there is need for an ECS engine in Rust.
All of the major engines are written in C++. I've tried Unreal, Unity and Godot. They all have their flaws. With Unreal and Godot those flaws are mainly the scripting languages BP and GDScript which one can get tired of quite easily, especially BP. You can of course use C++ for all your scripting but both engines strongly encourage you to use their scripting solution for a big chunk of your game. (Unity has a bunch of other issues and isn't source available, although C# is fairly pleasant to work with IMO).
There is definitely need for an OOP engine in Rust just as there is need for an ECS engine in Rust.
> There is definitely need for an OOP engine in Rust
Is there a need for an OOP engine in Rust?
I don't want to be too negative here — the developer of Fyrox seems like an incredibly talented and productive engineer and they can work on whatever they please, more options in the ecosystem is always a net good — but in my experience attempting to model OOP patterns in Rust is almost always the wrong decision.
Is there a need for an OOP engine in Rust?
I don't want to be too negative here — the developer of Fyrox seems like an incredibly talented and productive engineer and they can work on whatever they please, more options in the ecosystem is always a net good — but in my experience attempting to model OOP patterns in Rust is almost always the wrong decision.
It's a mixed approach in the end. Bevy is 100% ECS from what I gather. Fyrox is doing a pragmatic approach of taking what's good from different engines. I'm sure as it evolves it will abandon the things that don't work in a Rust context. So to rephrase: there is definitely a need for a game engine in Rust that's not 100% ECS.
> Fyrox is doing a pragmatic approach of taking what's good from different engines.
And bevy isn't taking what's good from different engines? Bevy gets inspiration from everywhere. Just because it uses an ECS doesn't mean it's all developed in a bubble.
And bevy isn't taking what's good from different engines? Bevy gets inspiration from everywhere. Just because it uses an ECS doesn't mean it's all developed in a bubble.
mcjerry(1)
It's not _that_ OOP. I keep telling people not to use OOP to refer to fyrox because people associate it with java but there maybe isn't a better commonly known word.
OOP in fyrox means composition and message passing.
OOP in fyrox means composition and message passing.
> Yet despite all this, Fyrox gets a fraction of the attention and money.
Heh Bevy sounds like Rust itself. Good PR with money behind it is its no1 cause of adoption.
Heh Bevy sounds like Rust itself. Good PR with money behind it is its no1 cause of adoption.
What PR money has been behind Rust?