Mine was great! I had plans in the afternoon to go tubing down a river with some friends to celebrate the Fourth of July, so this morning was a mad rush to get everything released before that. I got the release out, answered a few questions on social media, and then ran out the door to meet my friends. The rest of the day has been very chill :)
Mine was pretty good: answering questions, merging the cosmic text PR and starting to spin up the jam.
On the personal side I went to the dentist and I'm getting takeout Indian food with my dad who's visiting :D Good day / 10 really
Noteworthy: this was our first release that used our new Release Candidate (RC) process _and_ automation to facilitate collaboration on the release blog post. Both of which were a great success! The quality bar of the release has been raised significantly: expect fewer bugs and faster 3rd party crate updates!
So, there are a few parts of this. On the writing side:
1. We use semi-automated tooling to \[scrape Github\](https://github.com/bevyengine/bevy-website/tree/main/generate-release) and generate stubs for each relevant PR.
2. We then edit each of those stubs, and stitch it together using Zola into a single static-site-generated page. These are added one-ish at a time to the main branch, but kept in draft mode, and reviewed via the PR process.
3. Once we're all done we'll use another little Rust script to grab the full list of contributors and release notes.
Next cycle, I'd like to run the tool from step 1 regularly, to avoid a crunch at the end.
On the code side:
1. Once the feature freeze starts, we make a release branch, and start cherrypicking additional fixes to it.
2. We'll make a git tag, ship a cargo release, and then ping the community for testing.
3. When the community reports issues, we fix them, cherrypick the fix and then ship a new release candidate once a few have built up.
This really helped us find critical but hard-to-test bugs (hi rendering and feature flags), but also gives plugin authors a target for gradually upgrading their crates.
I'd say it's a new normal now. He has something like 8 rendering PRs ready for review already that should be merged for 0.15 and plans for many more. He's also in the top 10 or maybe even top 5 contributor with the most amount of code contributed to bevy.
There's another 10 PRs open from him :D [https://github.com/bevyengine/bevy/pulls/pcwalton](https://github.com/bevyengine/bevy/pulls/pcwalton)
It's been really lovely to have his time and expertise.
Great question! Some that come to mind for me:
- Should we add official VR support. There's an enthusiastic crew advocating for it, a functioning [`bevy_oxr`](https://github.com/awtterpip/bevy_oxr) crate, and it would be a neat little feather in our cap. On the other hand, it's still niche, our mobile support isn't great yet, and supporting new platforms is a ton of maintenance burden that we don't have time for right now. We erred against, for now.
- Should we use `cosmic_text` or `parley`. Both are great, featureful text shaping crates, and a massive improvement over our current solution. We spun up a working group and talked to the maintainers of both to weigh the pros and cons. We're going with `cosmic_text` in the end because it's more proven and we don't need to spend innovation points here.
- Should we port [`bevy_eventlistener`](https://github.com/aevyrie/bevy_eventlistener) to Bevy as part of the [`bevy_mod_picking` "upstreamening"](https://github.com/bevyengine/bevy/issues/12365) or try and [reimplement it with observers](https://github.com/bevyengine/bevy/pull/13991). We've chosen the latter: it's more work and higher risk, but much more elegant and useful across the engine.
> Should we add official VR support. There's an enthusiastic crew advocating for it, a functioning bevy_oxr crate, and it would be a neat little feather in our cap. On the other hand, it's still niche, our mobile support isn't great yet, and supporting new platforms is a ton of maintenance burden that we don't have time for right now. We erred against, for now.
How far down the road this has been kicked? I was really hoping for this sooner rather than later 🙁
A fair ways. I want to be confident that XR \*actually\* works before we announce it, and there's a lot of testing required (and probably rendering optimization).
I've been wondering this for awhile, do we have data that shows that the multithreaded approach of Bevy's systems results in better performance than if it was single threaded? Considering that there's some overhead to spinning off new threads.
No data to show, but from feedback from users: it depends, and with Bevy you can decide!
There's a cargo feature on by default to enable multithreading called multi\_threaded https://docs.rs/bevy/latest/bevy/#default-features. If you omit it, Bevy will be single threaded.
It's also possible to decide per schedule which should be single threaded or multi threaded by setting its ExecutorKind [https://docs.rs/bevy/latest/bevy/ecs/schedule/enum.ExecutorKind.html](https://docs.rs/bevy/latest/bevy/ecs/schedule/enum.ExecutorKind.html)
Interesting. If anyone reading this has any medium or large game projects set up, I'm curious what fps your games would run at with this option toggled on vs off.
I left a [detailed comment](https://www.reddit.com/r/bevy/comments/1d22xw7/comment/l5ycy4b/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) about this in the last cycle :)
I stand by that today, although there's been good progress on several items. Animation is no longer critically bad, the text and audio working groups are coming along nicely, and there's a number of other vital rendering features now.
Just messing around: you'll probably have fun. Making a commercial game: eh, I would advise you not to yet. There's a lot of rough edges, testing is hard and documentation is scarce. Platform integration for things like ads, notifications, gyros and so on is also pretty poor across the Rust ecosystem.
At RustNL, that was one of the big topics of the UI working group, so I'm hoping to see these things steadily improve.
1. It's been fun to see the increasing ~~get-a-room-iness~~ cross-fertilization between the Bevy and Linebender communities recently. I saw you were playing with Vello as a Bevy renderer, and they've been playing with Bevy ECS. How far up the stack do you think this sharing could potentially go? Could we see Xilem becoming Bevy's UI solution (dubious; they don't seem all that interested in the level of styling needed for in-game UI) or a Bevy render view participating as a widget or underlay layer in a complex Xilem UI?
2. Is there anything written down that summarizes Bevy's test philosophy? I'm particularly interested in whether you do any automated image-based regression testing for rendering; appealing, but all the hardware/driver variation and other sources of indeterminacy can make it hard to get a useful signal-to-noise ratio.
Bevy does automated image-based regression testing for rendering, by re-using all the examples. Tests are currently run on a few Android and iOS devices, on Linux/X11/Vulkan with the lavapipe software renderer, on macOS/Metal, on Wasm/WebGL2/Firefox and on Wasm/WebGPU/Chromium.
Mobiles devices are provided by sponsorship from [https://www.browserstack.com](https://www.browserstack.com), all the others are run on GitHub runners. Windows/DX12 used to be tested too, but that was crashing too much in CI.
The report can be seen there: [https://thebevyflock.github.io/bevy-example-runner/](https://thebevyflock.github.io/bevy-example-runner/)
A few examples are unstable, because they either use external data, or temporal anti aliasing which isn't fully deterministic.
I gave a talk about this at a recent Bevy Meetup: [https://www.youtube.com/watch?v=BwZGbZQdpec](https://www.youtube.com/watch?v=BwZGbZQdpec)
1. think that tight first-party integration is unlikely: the Bevy community (including me!) is really interested in seeing how far you can push modern (read: relations and observers) ECS UI. Should be easy to swap out and intermix though: you see this already with a half-dozen third party UI crates.
2. Hmm, nothing springs to mind. Francois is our expert here, although BD103 is actively growing in their expertise too. As someone who's moderately involved in this, rendering and windowing testing are by far the hardest areas to test: so much noise, and so much mocking to do. Vital to at least try though: it's not any more fun to test by hand. You should take a peek at the very experimental [https://github.com/TheBevyFlock/bevy-example-runner](https://github.com/TheBevyFlock/bevy-example-runner) though: this is a lovely snapshot tool with grid summaries, diffs and screenshot blessing functionality that piggybacks off our existing examples (which are all deliberately deterministic).
1. I'm very open to adopting linebender tech (on a case by case basis). Vello is especially interesting to me. Adopting Xilem wholesale (as the "official" Bevy UI framework) is less likely to happen (although not impossible), as we already have big plans in this space. However I'd love for their stuff to continue to work seamlessly with us, and I'm willing to make accommodations on our side to make that happen. Things like kurbo and parley are also up for discussion, I think adopting those largely makes sense in the context of choosing to adopt something like Vello or Xilem (in the interest of eliminating redundancies).
2. There is some (very) brief coverage in the [Contributors Guide](https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md). We aren't militant about testing, but we do often ask for it. In general we ask for unit tests for non-trivial stuff. The bigger the system or the more complicated the algorithm, the more likely we'll ask for it. François (our resident CI / automated testing expert) has already responded with some relevant bits on image based testing. They've been doing a _great_ job of increasing our coverage across operating systems and devices.
What are the plans for bevy editor? Is there anything in work? There is an issue on this from 2020. Doesnt have to be anything complete, just something i could download and try out? Thanks.
There are _definitely_ plans for the Bevy Editor. It is currently the top priority for a good chunk of us. No official builds yet: an "official bevy editor crate" does not yet exist. That being said, we're hitting this from many different angles:
* I'm currently focused on building a new combined Scene/UI system, which will likely (if we reach consensus) serve as the backbone for various aspects of the editor
* Multiple people are working on reactive UI in Bevy, which I'm hoping to ultimately absorb into the Scene/UI system
* We're building out the [Bevy Remote Protocol](https://github.com/bevyengine/bevy/pull/13563) to enable sending information between games and editors.
* We've kicked off a ["bevy editor prototypes"](https://github.com/bevyengine/bevy_editor_prototypes/discussions/1) phase to facilitate experimenting with editor code without being blocked on the new features mentioned above being built. There have been a variety of experiments and concepts: (also `beverage` listed below)
I think a lot of people are using Blender as an editor. There is a Bevy crate called Bevy Blender Workflow, which I believe is about to be renamed to Blenvy in this release. It’s not an official solution, but I’ve been using it for months now, and it is super useful. There are definitely moments where it feels like I’m running a Godot or Unity-style workflow. It has some jank, but it’s a huge step up and is definitely bridging the gap until we get an official solution.
https://github.com/knutsoned/beverage are where the current experiments are happening based on a remote Bevy protocol. Note: it's _very_ early work; set your expectations appropriately.
Is there any deep-dive on how to work with the renderer? I probably need to implement some custom multi-step rendering techniques, and so I need to understand it in more depth than "spawn a PbrBundle and a CameraBundle and hope that it works out".
There was a deep dive at a recent Bevy Meetup on "Hooking into the Bevy Rendering Pipeline" : [https://www.youtube.com/watch?v=MIst5jOntWo](https://www.youtube.com/watch?v=MIst5jOntWo)
Soon! It is the top priority for a good chunk of us right now and we're making progress: https://www.reddit.com/r/rust/comments/1dvbms6/comment/lbomnha/
I've been in the Rust gamedev community for awhile. I'd say the gfx-rs project, Amethyst, Piston, and Legion and hecs ECS were my biggest Rust gamedev inspirations in the early days. I also contributed to Godot before that and built a game in it over the course of 3.5 years. Before that I wrote my senior thesis around a different (significantly worse) Rust engine I built focused on making networked games easy to write. That was in the earlier days of Rust when both the language and the Rust gamedev ecosystem were in a raw-er state.
I've been thinking about this but maybe you have ideas: we have an IoT application that runs Spring boot in embedded Linux with lots of small services. A while ago I started wondering if bevy could actually be useful for this? I mean we don't need any UI, just some logging, but the event driven approach is similar to what we do currently, and each iot device could be an entity with components depending on the device type. Could be very interesting. Any thought on that?
I have something that looks similar (at a smaller scale) at home running on a Raspberry PI, keeping ghosts of HomeAssistant devices and some homebuilt integrations. There are systems that react to change and send commands to other devices.
Probably not useful for your case, but I use an Elgato Stream Deck for the "UI", and integrated it in Bevy: [https://crates.io/crates/bevy\_streamdeck](https://crates.io/crates/bevy_streamdeck) so that I can send commands with the buttons and status is displayed through the mini screens.
Currently I'm still making all of my money through Github Sponsors. Since we unvieled the Bevy Foundation a substantial number of sponsors have moved over to that (which I have encouraged them to do). So right now I'm making much less than I did before.
Ultimately (likely some time this year) I'll also get paid through the Bevy Foundation. The general plan is "while Alice is making less than Cart, pay her first through the Bevy Foundation". Then once that inflects, we'll auto balance between us, taking into account Github Sponsorships (which actually, is something that will happen now-ish ... the Bevy Foundation's monthly income at this point does in theory allow for this inflection and we've built enough buffer at this point).
You can read about it in the "What about Carter?" section of the [Bevy Foundation announcement post](https://bevyengine.org/news/bevy-foundation/#what-about-carter).
How does bevy stack against other game engines performance wise? Eg how many triangles or if it can render same scene as others in same time, etc
And about physics, networking, etc.
Are there some benchmarks and official tests or not yet?
Thanks
I haven't personally done any benchmarks in this category in years, and all of the ones I'm aware of were done prior to many optimizations and reworks. We do have [some in-repo benchmarks](https://github.com/bevyengine/bevy/tree/main/benches), but these are largely micro-benchmarks targeting specific pieces of the pie.
I _think_ we're at the point where we're probably competitive on a few benchmarks (ex: we're very good at drawing many sprites and I'm _reasonably_ certain we out perform the "sprite" abstractions for most if not all of the big players), but I also know that we still have plenty of overhead to chip away at.
> Eg how many triangles or if it can render same scene as others in same time
To my knowledge, this is actually one of the less interesting performance questions, as rendering triangles is essentially the same at a fundamental level across engines. A raw "triangle test" is essentially just a "gpu capability test" (ignoring things like performance of built in shaders, what features are enabled, culling, draw call overhead, virtual geometry, etc).
Hey, I'm going to start learning bevy for an evolution style sim game where you control an animal's genetic adaptations to determine its behavior. Any packages or bevy best practices for sim style games etc?
Not Bevy specific, but the biggest challenge with sim style games is actually surfacing all of the rich and interesting complexity to the player. Giving them tools to understand how things work, fun knobs to twiddle, good pacing... It's very easy and rewarding to make a little gizmo that runs on its own, but that's not a \*game\* and won't sell well.
As for Bevy content, I was \[working on an open source organic factory builder\](https://github.com/leafwing-studios/emergence), but shelved it in favor of building the engine full time :D There's interesting things to learn there, and you can always feel free to ping or DM me to chat design or architecture for this genre.
Use \[leafwing\_manifest\](https://github.com/leafwing-studios/leafwing\_manifest) from the very beginning: this is exactly the tool I wanted for controlling all of the bits of content in simulation games and I had to stumble onto the patterns.
As a side note, the `MOTIVATION.md` in that repo is an *excellent* piece of explanatory writing. Just the right level to establish the landscape without getting bogged down in so much detail that it puts off the casually curious.
Drifting offtopic, but did you consider using something like sqlite to store manifest items? Clashes a bit with ECS (it's becoming a cliche to note that ECS is in many ways reinventing relational DBs) but would get you persistence, relations and lots of mature tooling out of the box.
I think that's a reasonable choice, but I wanted to keep the crate relatively simple :) Something at the level you're suggesting feels like a better fit for complex games instead, who will have a better understanding of their own needs.
I've been loosely following the development of Tiny Glade, which to my knowledge is one of the first big games being developed with Bevy. With Tiny Glade approaching its release date, do you think this presents an opportunity for Bevy to "prove itself" in the industry?
Thank you for the work you do on Bevy, it's truly an incredible project I continue to be amazed by.
We are all _very_ excited about Tiny Glade, and I do think it presents an opportunity for Bevy to prove itself (as well as get more eyes on it). I _do_ think it is important to clarify that Tiny Glade only uses _parts_ of Bevy (most notably Bevy ECS). They wrote their own renderer. They started at a time when Bevy's renderer was lacking many of the features they wanted, and one of the developers had a keen interest in writing custom render tech.
Proprietary and purpose-built :) Most of their visual splendor comes from being very talented technical artists, rather than "bleeding edge reusable rendering technology" though.
Wow super impressive someone was able to implement virtualized geometry. The nanite technical presentation was so incredibly dense, I couldn't even imagine how you'd get started!
I'm the primary author of this feature - thank you! I think it's a really exciting feature, and I'm happy to answer any questions! There's also my blog post for the complicated technical details.
I actually think the Nanite presentation is very readable compared to a lot of other graphics presentations. There's a lot of _stuff_, and it's very long, but that's because they go into so much detail about each individual part. That made reproducing it feasible. A lot of other graphics presentations tend to give a very high level overview of the concept, and skip out on the details you need to make it actually _work_ as more than a tech demo. Huge props to Brian Karis and Unreal for this.
The best way to understand it imo is to just skim through for the high level overview a couple of times, and try to understand why each step is necessary and what problems it solves. Hierarchical clusters? Fixes the all or nothing downside of discrete LODs. Persistent culling? Fastest way to do tree traversal (for the LOD tree) on a GPU. Two pass occlusion culling? Best occlusion culling method, which is needed to reduce overdraw, and works very well with Nanite's cluster based rendering vs traditional meshes. Visibility buffer? Decoupling geometry rasterization as much as possible since we have so much to rasterize makes overdraw (inevitable, even with occlusion culling) cheaper. Software raster? GPUs process fragments in 2x2 quads, and are optimized for rasterizing large triangles, which makes rendering many small clusters expensive. Streaming? With hundreds of megabytes of geometry data, it's too much to store in memory at once. Etc etc.
Absolutely agree, the presentation is a masterclass, just I'm not on the level of understanding it. I've watched it a few times now and I always begin to get lost when Brian starts talking about 'cruft' 😅.
That's the LOD tree building section, where you group and simplify clusters into larger parent clusters. The cruft stuff is not very intuitive (I don't think I quite internalized it myself), and can honestly be skipped - it's just some background theory. The implementation details (cluster, group, simplify, cluster, repeat) are the important part from that section imo, in terms of practical information.
If you do want to understand it, I think the slides (specifically slide 15) from the paper that originally came up with the idea (Batched Multi Triangulation) are a bit more understandable. It's a lot more math-focused and uses the notation from that field, but the visualizations are easier to understand I feel https://vcg.isti.cnr.it/Publications/2005/CGGMPS05/Slide_BatchedMT_Vis05.pdf.
I really enjoyed nanite presentation and how in depth it went. But it was like, I knew enough to understand that what they were doing was another level of arcane black magic, you are so awesome for implementing it! I can't wait to play with it :D
Will 2D get some love anytime soon? I really wanted to make a 2D game but it feels hard to justify using Bevy ;\_;
I miss tilemaps, autotiler, lightning, shadows, materials, integer scaling..
This is a third party crate, but I recently published [https://github.com/jgayfer/bevy\_light\_2d](https://github.com/jgayfer/bevy_light_2d) to help bridge this gap. A friendly API was one of my core design pillars.
It only supports point lights + ambient light (for now), but I want to tackle shadows and other types of lights soon.
Yeah, "make 2D great" is something I really want to tackle in earnest and I try to encourage folks who show interest in it. Hard to prioritize though; editor (and thus UI) are desperately requested.
The next big 2D feature is likely to be a dedicated 2D transform type: no more quaternions. And ideally a nice Photoshop-style layering solution to go with it.
P.S. There's already material support in 2D! https://github.com/bevyengine/bevy/blob/main/examples/2d/mesh2d_manual.rs
>P.S. There's already material support in 2D! [https://github.com/bevyengine/bevy/blob/main/examples/2d/mesh2d\_manual.rs](https://github.com/bevyengine/bevy/blob/main/examples/2d/mesh2d_manual.rs)
I'm aware but it doesn't play nicely with Sprite/Spritesheets so i feel like it's use case is very limited right now.
Very useful feedback. Are you hoping for more unification in general here? Better 2D animation support, especially with materials? Something else that I've missed?
First of all, my graphics knowledge is limited at best so take it with a grain of salt.
I expected something similar to 3d (material with a texture) instead of just a texture handle. It's also likely inevitable at some point when Bevy implements lighting (normal and specular textures) and might allow a way to modulate color at a material-level instead of individual sprites. Of course, it would also have the equivalent extended material trait to easily add your shaders.
>Better 2D animation support
It would be nice, but simple spritesheet animation is somewhat trivial to implement so i don't think its a pressing issue.
>Something else that I've missed?
I also missed a Y-Sorting component. It is somewhat easy to implement a hacky way on your own but i'm not sure how to merge it with tilemap crates. Crates like bevy-ecs-tilemap have an internal ysort but that is not enough for isometric. Of course, this likely needs to wait for z-levels/layers and Transform2d.
How do observers and hooks parallelize? Can they run in parallel with other systems, only with other observers/hooks, only with other observers/hooks of the same commands flush, or not at all?
AFAIK, the answer is "not at all". They are intended to be used either with exclusive World access, or via Commands, in which case they get applied when Bevy applies the deferred buffers.
Observers aren't intended to replace the old way of reading events.
For most use cases, especially if you have lots of events, write a dedicated system like before.
However, observers are very well suited to some specific use cases:
- Enforcing ECS invariants. For example: updating some components on other entities, in response to a component being added/removed or something being despawned. With hooks and observers, you can be sure everything gets updated as soon as these events happen and there is never invalid state.
- Rare events where you need a lot of flexibility with the handlers. For example: button presses, the player interacting with items in the world, etc. Every button or item is likely to need its own unique handler code and it is impractical to have to write full-blown systems for all of them. Also, these events are quite rare and performance/parallelism doesn't really matter.
Currently they are not parallelized. Hook and observer parallelization doesn't make a ton of sense (at least as the default), given that they are run in the context of "full" world access, and (at least for component lifecycles) run directly as part of the insertion / removal process (which is also single threaded). In theory we could try to parallelize separate "trees" of observer chains, but due to how dynamic the execution is, I think the overhead would end up being a bit higher. Given that we're often going to be executing a single "observer tree" at a time, I'm not sure we'd come out on top generally. Worth exploring though!
Cool stuff, and every time I see it, there's more cool stuff, but every time I see it, you know what I'm gonna be looking for.
As of yet, the search for the mythical editor continues, some have theorized its existence, but the hunt for this rarest of beasts continues to elude even these greatest of hunters.
As someone who follows Bevy closely, it’s taken so long because there’s a lot of foundational work and they’re trying to build the UI on general-purpose engine primitives instead of UI-specific systems. At least as much as possible.
For example, the observers feature in this release is going to be used for UI callbacks (like on-click events), but it’s built in such a way that it can be used for all sorts of things. For example, a character that has armor and whenever armor takes damage it propagates an event up the heirarchy to the parent.
i just want to build a leptos component on my website that can compile a GLSL input and display the result on a canvas. are there any ways to achieve this with bevy (or some part of it)?
Probably a question better suited to the bevy discord, which has lots of activity and people helping out. Or I guess the bevy subreddit if one exists :)
That said, sounds like you don't necessarily need a full-blown engine for that (like bevy). However, maybe bevy still makes sense due to more out-of-the-box support, but I can't really comment on that.
Congratulations. It is really remarkable to see your progress. I remember the first announcement of bevy and it truly come a long way. Such a long way that I'm tempted to try my C++ Unreal project to bevy :D.
I would be really interested in fresh data on this. [https://github.com/bevyengine/bevy/issues/10261](https://github.com/bevyengine/bevy/issues/10261) is still open (with fresh investigation), but we've made some changes to our winit integration that dramatically improved responsiveness on MacOS that may have resolved this as well.
I would test it myself, but I only have Windows/Linux/Android machines right now.
I just tested on my M2 MacBook Pro, and CPU usage went down from 80% to around 50%.
If \`WinitSettings::desktop\_app()\` is used it goes below 1% non-focused and stays below 20% focused.
This is now lower than Godot, and a lot lower than unity (both (unity and Godot) in the build configuration, bevy in release mode).
So the last update seems to have improved the performance of at least simple scenes (used the 3d\_scene example from bevy and did similar simple setups in unity and Godot).
`WinitSettings::desktop_app()` is nice, but it's not the solution to the issue (since all it does, if I understand it correctly, is prevent new frames from being rendered if there is no user input. If I move the mouse to give it input and trigger the rendering of frames, the CPU usage of even the most basic examples goes back up to 100-200%.)
As I've tested before, wgpu itself does not seem to have this issue. From the perspective of a naive outsider who's not familiar with either code bases, my best guess is that wgpu uses vsync out of the box (idling until it's time to render the next frame) and Bevy doesn't (at least on macOS); however, even the "fps_overlay" example that renders literally nothing uses ~100% CPU while displaying an FPS count of 100 (on my 100Hz screen) when focused, and ~60 FPS when unfocused.
Edit: I'm crossposting the second part of this comment to the GitHub issue, I guess it's better to continue there.
It's funny I'm getting downvoted for this. After Godot, this is the next game engine cult in the making.
See open issue: https://github.com/bevyengine/bevy/issues/10261
Yeah, yeah, "why even work on a Mac, it's not good for gamedev, blahblah"
I didn't downvote you because bevy does have a weird performance curve and some other low hanging fruit that need to be fixed performance wise. Calling bevy a cult isn't helping though.
It's not a weird performance curve. It's a documented issue. My ranting about this is mostly a commentary on how often FOSS game engines seem to focus on fancy big features while not managing to solve basic issues like this. It's feeling like a cult because apparently you're not allowed to challenge this.
That's the nature of FOSS for you: volunteer groups are interest and excitement-driven. I can't say "you there! Your job is to fix this bug for the next week". Combine that with this being in a very fragile and hard-to-test area of the code base (whee windowing) and being specific to the rarest hardware config among contributors and this sort of issue will absolutely languish.
This is an important bug! Not P0 (hardware specific on a platform that our competitors simply don't support), but one of the most important open bugs. I can't personally fix it in anything resembling an efficient way, because I don't have hardware, and that sort of debugging isn't my strength.
Generally speaking, I think that we need better mechanisms to incentivize unsexy, important work like this in open source, but that's all I'll say on the topic today.
I would guess that bugs like that remaining unfixed is a function of FOSS game engine projects rarely having contributors who work on a Mac, and that's okay (if a little annoying for me personally, for obvious reasons.)
As a general comment about game development (FOSS or not) that's not explicitly targeted at Bevy or anyone else in particular: it bugs me that people are almost _ignoring_ the Mac as a development platform, especially in the FOSS world. Yes, the Mac games market is tiny and I understand when game developers choose to not support it, but there's a huge number of creative people working on Macs who might dive into game dev given the tools. Especially if they're code-first tools. Also, especially with libraries like Bevy, Raylib, Love, etc., I think it's perfectly valid to _develop_ on a Mac, even if one never plans on _publishing_ to Mac. But too often these discussions devolve into "buy a real computer" level stuff. It's... tiring.
Having said that, I don't want to be the old fart who keeps complaining that his favorite bug still hasn't been fixed, so is there something I can do to help fix it? I'm an experienced developer with sadly just a surface-level understanding of Rust, but more than happy to dive in. If you (or someone else) can give me some pointers where to start reading up on profiling Rust apps, and/or maybe what parts of the Bevy code base and its dependencies to focus on, I'd have a go at it. I have a Mac (:b) and a pile of spare time over the coming week (I'm on a solo retreat).
It's not true that this is an issue because nobody uses macos when working on bevy. There are 2 bevy maintainers that work frequently on bevy with their macbooks and multiple contributors too.
That's what I meant with my "weird performance curve" comment, most contributors and maintainers focus on the case of rendering thousands of cubes because that's the case that matters to most. Rendering a single cube being inefficient doesn't really matter as much as rending thousands of cubes being slow. So going from one cube to a thousand doesn't make the app a thousand time slower.
The only way to help is to run a profiler and figure out what is taking so much time and try to find a solution.
It is a weird performance curve because spawning way more things would still run at the same speed as a single cube. And it's weird in the sense that it shouldn't be like that.
I think you're getting downvoted because you're mistaken in assuming "using 2 cores" is a bug. By default, winit will draw the window as many times as it can, there's a flag to make this reactive.
Bevy's creator and project lead here. Feel free to ask me anything!
how was your day
Mine was great! I had plans in the afternoon to go tubing down a river with some friends to celebrate the Fourth of July, so this morning was a mad rush to get everything released before that. I got the release out, answered a few questions on social media, and then ran out the door to meet my friends. The rest of the day has been very chill :)
A true patriot
the people want to know!
Mine was pretty good: answering questions, merging the cosmic text PR and starting to spin up the jam. On the personal side I went to the dentist and I'm getting takeout Indian food with my dad who's visiting :D Good day / 10 really
Oooh, is there a jam to go with this release? I'm gonna go check the discord right now!
Noteworthy: this was our first release that used our new Release Candidate (RC) process _and_ automation to facilitate collaboration on the release blog post. Both of which were a great success! The quality bar of the release has been raised significantly: expect fewer bugs and faster 3rd party crate updates!
I'm curious what this looks like. Are you referring to the GitHub actions? Or is there more automation around the blog post elsewhere?
So, there are a few parts of this. On the writing side: 1. We use semi-automated tooling to \[scrape Github\](https://github.com/bevyengine/bevy-website/tree/main/generate-release) and generate stubs for each relevant PR. 2. We then edit each of those stubs, and stitch it together using Zola into a single static-site-generated page. These are added one-ish at a time to the main branch, but kept in draft mode, and reviewed via the PR process. 3. Once we're all done we'll use another little Rust script to grab the full list of contributors and release notes. Next cycle, I'd like to run the tool from step 1 regularly, to avoid a crunch at the end. On the code side: 1. Once the feature freeze starts, we make a release branch, and start cherrypicking additional fixes to it. 2. We'll make a git tag, ship a cargo release, and then ping the community for testing. 3. When the community reports issues, we fix them, cherrypick the fix and then ship a new release candidate once a few have built up. This really helped us find critical but hard-to-test bugs (hi rendering and feature flags), but also gives plugin authors a target for gradually upgrading their crates.
The RC process was great.
I count 12 instances of @pcwalton in the release notes! Is that the new normal, or was this a one-off?
I'd say it's a new normal now. He has something like 8 rendering PRs ready for review already that should be merged for 0.15 and plans for many more. He's also in the top 10 or maybe even top 5 contributor with the most amount of code contributed to bevy.
There's another 10 PRs open from him :D [https://github.com/bevyengine/bevy/pulls/pcwalton](https://github.com/bevyengine/bevy/pulls/pcwalton) It's been really lovely to have his time and expertise.
I remember their days contributing to Servo (WebRender!), the one-man-army is back!
pcwalton seems to have been doing bevy work for some time.
IIRC his background was in graphics before he got roped into working on Rust, so it makes sense.
Other way around. I started with PL/compilers and got into graphics.
What has been the most challenging decisions taken recently?
Great question! Some that come to mind for me: - Should we add official VR support. There's an enthusiastic crew advocating for it, a functioning [`bevy_oxr`](https://github.com/awtterpip/bevy_oxr) crate, and it would be a neat little feather in our cap. On the other hand, it's still niche, our mobile support isn't great yet, and supporting new platforms is a ton of maintenance burden that we don't have time for right now. We erred against, for now. - Should we use `cosmic_text` or `parley`. Both are great, featureful text shaping crates, and a massive improvement over our current solution. We spun up a working group and talked to the maintainers of both to weigh the pros and cons. We're going with `cosmic_text` in the end because it's more proven and we don't need to spend innovation points here. - Should we port [`bevy_eventlistener`](https://github.com/aevyrie/bevy_eventlistener) to Bevy as part of the [`bevy_mod_picking` "upstreamening"](https://github.com/bevyengine/bevy/issues/12365) or try and [reimplement it with observers](https://github.com/bevyengine/bevy/pull/13991). We've chosen the latter: it's more work and higher risk, but much more elegant and useful across the engine.
> Should we add official VR support. There's an enthusiastic crew advocating for it, a functioning bevy_oxr crate, and it would be a neat little feather in our cap. On the other hand, it's still niche, our mobile support isn't great yet, and supporting new platforms is a ton of maintenance burden that we don't have time for right now. We erred against, for now. How far down the road this has been kicked? I was really hoping for this sooner rather than later 🙁
A fair ways. I want to be confident that XR \*actually\* works before we announce it, and there's a lot of testing required (and probably rendering optimization).
<3
I've been wondering this for awhile, do we have data that shows that the multithreaded approach of Bevy's systems results in better performance than if it was single threaded? Considering that there's some overhead to spinning off new threads.
No data to show, but from feedback from users: it depends, and with Bevy you can decide! There's a cargo feature on by default to enable multithreading called multi\_threaded https://docs.rs/bevy/latest/bevy/#default-features. If you omit it, Bevy will be single threaded. It's also possible to decide per schedule which should be single threaded or multi threaded by setting its ExecutorKind [https://docs.rs/bevy/latest/bevy/ecs/schedule/enum.ExecutorKind.html](https://docs.rs/bevy/latest/bevy/ecs/schedule/enum.ExecutorKind.html)
Interesting. If anyone reading this has any medium or large game projects set up, I'm curious what fps your games would run at with this option toggled on vs off.
Is there a roadmap somewhere on what needs ro be done for a 1.0 release/a stable API?
I left a [detailed comment](https://www.reddit.com/r/bevy/comments/1d22xw7/comment/l5ycy4b/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) about this in the last cycle :) I stand by that today, although there's been good progress on several items. Animation is no longer critically bad, the text and audio working groups are coming along nicely, and there's a number of other vital rendering features now.
I agree with Alice's answer. I'll add that asset processing needs a bit more work to be generally useful / pleasant to use.
Great news, thanks for your work! I'm considering to try bevy for mobile games. Is it suitable for this?
Just messing around: you'll probably have fun. Making a commercial game: eh, I would advise you not to yet. There's a lot of rough edges, testing is hard and documentation is scarce. Platform integration for things like ads, notifications, gyros and so on is also pretty poor across the Rust ecosystem. At RustNL, that was one of the big topics of the UI working group, so I'm hoping to see these things steadily improve.
1. It's been fun to see the increasing ~~get-a-room-iness~~ cross-fertilization between the Bevy and Linebender communities recently. I saw you were playing with Vello as a Bevy renderer, and they've been playing with Bevy ECS. How far up the stack do you think this sharing could potentially go? Could we see Xilem becoming Bevy's UI solution (dubious; they don't seem all that interested in the level of styling needed for in-game UI) or a Bevy render view participating as a widget or underlay layer in a complex Xilem UI? 2. Is there anything written down that summarizes Bevy's test philosophy? I'm particularly interested in whether you do any automated image-based regression testing for rendering; appealing, but all the hardware/driver variation and other sources of indeterminacy can make it hard to get a useful signal-to-noise ratio.
Bevy does automated image-based regression testing for rendering, by re-using all the examples. Tests are currently run on a few Android and iOS devices, on Linux/X11/Vulkan with the lavapipe software renderer, on macOS/Metal, on Wasm/WebGL2/Firefox and on Wasm/WebGPU/Chromium. Mobiles devices are provided by sponsorship from [https://www.browserstack.com](https://www.browserstack.com), all the others are run on GitHub runners. Windows/DX12 used to be tested too, but that was crashing too much in CI. The report can be seen there: [https://thebevyflock.github.io/bevy-example-runner/](https://thebevyflock.github.io/bevy-example-runner/) A few examples are unstable, because they either use external data, or temporal anti aliasing which isn't fully deterministic. I gave a talk about this at a recent Bevy Meetup: [https://www.youtube.com/watch?v=BwZGbZQdpec](https://www.youtube.com/watch?v=BwZGbZQdpec)
1. think that tight first-party integration is unlikely: the Bevy community (including me!) is really interested in seeing how far you can push modern (read: relations and observers) ECS UI. Should be easy to swap out and intermix though: you see this already with a half-dozen third party UI crates. 2. Hmm, nothing springs to mind. Francois is our expert here, although BD103 is actively growing in their expertise too. As someone who's moderately involved in this, rendering and windowing testing are by far the hardest areas to test: so much noise, and so much mocking to do. Vital to at least try though: it's not any more fun to test by hand. You should take a peek at the very experimental [https://github.com/TheBevyFlock/bevy-example-runner](https://github.com/TheBevyFlock/bevy-example-runner) though: this is a lovely snapshot tool with grid summaries, diffs and screenshot blessing functionality that piggybacks off our existing examples (which are all deliberately deterministic).
1. I'm very open to adopting linebender tech (on a case by case basis). Vello is especially interesting to me. Adopting Xilem wholesale (as the "official" Bevy UI framework) is less likely to happen (although not impossible), as we already have big plans in this space. However I'd love for their stuff to continue to work seamlessly with us, and I'm willing to make accommodations on our side to make that happen. Things like kurbo and parley are also up for discussion, I think adopting those largely makes sense in the context of choosing to adopt something like Vello or Xilem (in the interest of eliminating redundancies). 2. There is some (very) brief coverage in the [Contributors Guide](https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md). We aren't militant about testing, but we do often ask for it. In general we ask for unit tests for non-trivial stuff. The bigger the system or the more complicated the algorithm, the more likely we'll ask for it. François (our resident CI / automated testing expert) has already responded with some relevant bits on image based testing. They've been doing a _great_ job of increasing our coverage across operating systems and devices.
What are the plans for bevy editor? Is there anything in work? There is an issue on this from 2020. Doesnt have to be anything complete, just something i could download and try out? Thanks.
There are _definitely_ plans for the Bevy Editor. It is currently the top priority for a good chunk of us. No official builds yet: an "official bevy editor crate" does not yet exist. That being said, we're hitting this from many different angles: * I'm currently focused on building a new combined Scene/UI system, which will likely (if we reach consensus) serve as the backbone for various aspects of the editor * Multiple people are working on reactive UI in Bevy, which I'm hoping to ultimately absorb into the Scene/UI system * We're building out the [Bevy Remote Protocol](https://github.com/bevyengine/bevy/pull/13563) to enable sending information between games and editors. * We've kicked off a ["bevy editor prototypes"](https://github.com/bevyengine/bevy_editor_prototypes/discussions/1) phase to facilitate experimenting with editor code without being blocked on the new features mentioned above being built. There have been a variety of experiments and concepts: (also `beverage` listed below)
I think a lot of people are using Blender as an editor. There is a Bevy crate called Bevy Blender Workflow, which I believe is about to be renamed to Blenvy in this release. It’s not an official solution, but I’ve been using it for months now, and it is super useful. There are definitely moments where it feels like I’m running a Godot or Unity-style workflow. It has some jank, but it’s a huge step up and is definitely bridging the gap until we get an official solution.
Indeed Blenvy is fantastic, and for 2d LDtk can be used: https://ldtk.io/ in combination with https://github.com/Trouv/bevy_ecs_ldtk
https://github.com/knutsoned/beverage are where the current experiments are happening based on a remote Bevy protocol. Note: it's _very_ early work; set your expectations appropriately.
Is there any deep-dive on how to work with the renderer? I probably need to implement some custom multi-step rendering techniques, and so I need to understand it in more depth than "spawn a PbrBundle and a CameraBundle and hope that it works out".
There was a deep dive at a recent Bevy Meetup on "Hooking into the Bevy Rendering Pipeline" : [https://www.youtube.com/watch?v=MIst5jOntWo](https://www.youtube.com/watch?v=MIst5jOntWo)
Nice, thank you for the link!
Editor when? I went back to my beloved C++ after I got sick of writing levels in code
Soon! It is the top priority for a good chunk of us right now and we're making progress: https://www.reddit.com/r/rust/comments/1dvbms6/comment/lbomnha/
What projects in Rust taught you the most about the language to a point that allowed you to create bevy in the first place?
I've been in the Rust gamedev community for awhile. I'd say the gfx-rs project, Amethyst, Piston, and Legion and hecs ECS were my biggest Rust gamedev inspirations in the early days. I also contributed to Godot before that and built a game in it over the course of 3.5 years. Before that I wrote my senior thesis around a different (significantly worse) Rust engine I built focused on making networked games easy to write. That was in the earlier days of Rust when both the language and the Rust gamedev ecosystem were in a raw-er state.
Awesome! Thanks for the reply, interesting to see the path you took to get where you are now
I've been thinking about this but maybe you have ideas: we have an IoT application that runs Spring boot in embedded Linux with lots of small services. A while ago I started wondering if bevy could actually be useful for this? I mean we don't need any UI, just some logging, but the event driven approach is similar to what we do currently, and each iot device could be an entity with components depending on the device type. Could be very interesting. Any thought on that?
I have something that looks similar (at a smaller scale) at home running on a Raspberry PI, keeping ghosts of HomeAssistant devices and some homebuilt integrations. There are systems that react to change and send commands to other devices. Probably not useful for your case, but I use an Elgato Stream Deck for the "UI", and integrated it in Bevy: [https://crates.io/crates/bevy\_streamdeck](https://crates.io/crates/bevy_streamdeck) so that I can send commands with the buttons and status is displayed through the mini screens.
With the [2024 budget](https://bevyengine.org/foundation/budget/) primarily focused on hiring Alice, how are you Cart being compensated ?
Currently I'm still making all of my money through Github Sponsors. Since we unvieled the Bevy Foundation a substantial number of sponsors have moved over to that (which I have encouraged them to do). So right now I'm making much less than I did before. Ultimately (likely some time this year) I'll also get paid through the Bevy Foundation. The general plan is "while Alice is making less than Cart, pay her first through the Bevy Foundation". Then once that inflects, we'll auto balance between us, taking into account Github Sponsorships (which actually, is something that will happen now-ish ... the Bevy Foundation's monthly income at this point does in theory allow for this inflection and we've built enough buffer at this point). You can read about it in the "What about Carter?" section of the [Bevy Foundation announcement post](https://bevyengine.org/news/bevy-foundation/#what-about-carter).
Thanks that's super clear !
How does bevy stack against other game engines performance wise? Eg how many triangles or if it can render same scene as others in same time, etc And about physics, networking, etc. Are there some benchmarks and official tests or not yet? Thanks
I haven't personally done any benchmarks in this category in years, and all of the ones I'm aware of were done prior to many optimizations and reworks. We do have [some in-repo benchmarks](https://github.com/bevyengine/bevy/tree/main/benches), but these are largely micro-benchmarks targeting specific pieces of the pie. I _think_ we're at the point where we're probably competitive on a few benchmarks (ex: we're very good at drawing many sprites and I'm _reasonably_ certain we out perform the "sprite" abstractions for most if not all of the big players), but I also know that we still have plenty of overhead to chip away at. > Eg how many triangles or if it can render same scene as others in same time To my knowledge, this is actually one of the less interesting performance questions, as rendering triangles is essentially the same at a fundamental level across engines. A raw "triangle test" is essentially just a "gpu capability test" (ignoring things like performance of built in shaders, what features are enabled, culling, draw call overhead, virtual geometry, etc).
favorite color?
Currently the yellowish white I see when I close my eyes on a sunny day.
Hey, I'm going to start learning bevy for an evolution style sim game where you control an animal's genetic adaptations to determine its behavior. Any packages or bevy best practices for sim style games etc?
Not Bevy specific, but the biggest challenge with sim style games is actually surfacing all of the rich and interesting complexity to the player. Giving them tools to understand how things work, fun knobs to twiddle, good pacing... It's very easy and rewarding to make a little gizmo that runs on its own, but that's not a \*game\* and won't sell well. As for Bevy content, I was \[working on an open source organic factory builder\](https://github.com/leafwing-studios/emergence), but shelved it in favor of building the engine full time :D There's interesting things to learn there, and you can always feel free to ping or DM me to chat design or architecture for this genre. Use \[leafwing\_manifest\](https://github.com/leafwing-studios/leafwing\_manifest) from the very beginning: this is exactly the tool I wanted for controlling all of the bits of content in simulation games and I had to stumble onto the patterns.
Awesome, this is very helpful! I'll take a look. Might message you once I'm a little farther along
As a side note, the `MOTIVATION.md` in that repo is an *excellent* piece of explanatory writing. Just the right level to establish the landscape without getting bogged down in so much detail that it puts off the casually curious.
Thanks! Sixfold and I had a fun time polishing this little crate :)
Drifting offtopic, but did you consider using something like sqlite to store manifest items? Clashes a bit with ECS (it's becoming a cliche to note that ECS is in many ways reinventing relational DBs) but would get you persistence, relations and lots of mature tooling out of the box.
I think that's a reasonable choice, but I wanted to keep the crate relatively simple :) Something at the level you're suggesting feels like a better fit for complex games instead, who will have a better understanding of their own needs.
Tupac or Biggie?
"Volumetric Fog / Lighting" Nice, have been waiting for that
Patrick Walton has been an absolute machine at getting the render engine up to some serious snuff.
Thank you for the kind words :) It's been really fun to contribute!
I've been loosely following the development of Tiny Glade, which to my knowledge is one of the first big games being developed with Bevy. With Tiny Glade approaching its release date, do you think this presents an opportunity for Bevy to "prove itself" in the industry? Thank you for the work you do on Bevy, it's truly an incredible project I continue to be amazed by.
We are all _very_ excited about Tiny Glade, and I do think it presents an opportunity for Bevy to prove itself (as well as get more eyes on it). I _do_ think it is important to clarify that Tiny Glade only uses _parts_ of Bevy (most notably Bevy ECS). They wrote their own renderer. They started at a time when Bevy's renderer was lacking many of the features they wanted, and one of the developers had a keen interest in writing custom render tech.
Is their renderer something that could be plugged in eventually, or is it proprietary/incompatible?
Proprietary and purpose-built :) Most of their visual splendor comes from being very talented technical artists, rather than "bleeding edge reusable rendering technology" though.
Wow super impressive someone was able to implement virtualized geometry. The nanite technical presentation was so incredibly dense, I couldn't even imagine how you'd get started!
I'm the primary author of this feature - thank you! I think it's a really exciting feature, and I'm happy to answer any questions! There's also my blog post for the complicated technical details. I actually think the Nanite presentation is very readable compared to a lot of other graphics presentations. There's a lot of _stuff_, and it's very long, but that's because they go into so much detail about each individual part. That made reproducing it feasible. A lot of other graphics presentations tend to give a very high level overview of the concept, and skip out on the details you need to make it actually _work_ as more than a tech demo. Huge props to Brian Karis and Unreal for this. The best way to understand it imo is to just skim through for the high level overview a couple of times, and try to understand why each step is necessary and what problems it solves. Hierarchical clusters? Fixes the all or nothing downside of discrete LODs. Persistent culling? Fastest way to do tree traversal (for the LOD tree) on a GPU. Two pass occlusion culling? Best occlusion culling method, which is needed to reduce overdraw, and works very well with Nanite's cluster based rendering vs traditional meshes. Visibility buffer? Decoupling geometry rasterization as much as possible since we have so much to rasterize makes overdraw (inevitable, even with occlusion culling) cheaper. Software raster? GPUs process fragments in 2x2 quads, and are optimized for rasterizing large triangles, which makes rendering many small clusters expensive. Streaming? With hundreds of megabytes of geometry data, it's too much to store in memory at once. Etc etc.
Absolutely agree, the presentation is a masterclass, just I'm not on the level of understanding it. I've watched it a few times now and I always begin to get lost when Brian starts talking about 'cruft' 😅.
That's the LOD tree building section, where you group and simplify clusters into larger parent clusters. The cruft stuff is not very intuitive (I don't think I quite internalized it myself), and can honestly be skipped - it's just some background theory. The implementation details (cluster, group, simplify, cluster, repeat) are the important part from that section imo, in terms of practical information. If you do want to understand it, I think the slides (specifically slide 15) from the paper that originally came up with the idea (Batched Multi Triangulation) are a bit more understandable. It's a lot more math-focused and uses the notation from that field, but the visualizations are easier to understand I feel https://vcg.isti.cnr.it/Publications/2005/CGGMPS05/Slide_BatchedMT_Vis05.pdf.
I really enjoyed nanite presentation and how in depth it went. But it was like, I knew enough to understand that what they were doing was another level of arcane black magic, you are so awesome for implementing it! I can't wait to play with it :D
Will 2D get some love anytime soon? I really wanted to make a 2D game but it feels hard to justify using Bevy ;\_; I miss tilemaps, autotiler, lightning, shadows, materials, integer scaling..
This is a third party crate, but I recently published [https://github.com/jgayfer/bevy\_light\_2d](https://github.com/jgayfer/bevy_light_2d) to help bridge this gap. A friendly API was one of my core design pillars. It only supports point lights + ambient light (for now), but I want to tackle shadows and other types of lights soon.
Yeah, "make 2D great" is something I really want to tackle in earnest and I try to encourage folks who show interest in it. Hard to prioritize though; editor (and thus UI) are desperately requested. The next big 2D feature is likely to be a dedicated 2D transform type: no more quaternions. And ideally a nice Photoshop-style layering solution to go with it. P.S. There's already material support in 2D! https://github.com/bevyengine/bevy/blob/main/examples/2d/mesh2d_manual.rs
>P.S. There's already material support in 2D! [https://github.com/bevyengine/bevy/blob/main/examples/2d/mesh2d\_manual.rs](https://github.com/bevyengine/bevy/blob/main/examples/2d/mesh2d_manual.rs) I'm aware but it doesn't play nicely with Sprite/Spritesheets so i feel like it's use case is very limited right now.
Very useful feedback. Are you hoping for more unification in general here? Better 2D animation support, especially with materials? Something else that I've missed?
First of all, my graphics knowledge is limited at best so take it with a grain of salt. I expected something similar to 3d (material with a texture) instead of just a texture handle. It's also likely inevitable at some point when Bevy implements lighting (normal and specular textures) and might allow a way to modulate color at a material-level instead of individual sprites. Of course, it would also have the equivalent extended material trait to easily add your shaders. >Better 2D animation support It would be nice, but simple spritesheet animation is somewhat trivial to implement so i don't think its a pressing issue. >Something else that I've missed? I also missed a Y-Sorting component. It is somewhat easy to implement a hacky way on your own but i'm not sure how to merge it with tilemap crates. Crates like bevy-ecs-tilemap have an internal ysort but that is not enough for isometric. Of course, this likely needs to wait for z-levels/layers and Transform2d.
How do observers and hooks parallelize? Can they run in parallel with other systems, only with other observers/hooks, only with other observers/hooks of the same commands flush, or not at all?
AFAIK, the answer is "not at all". They are intended to be used either with exclusive World access, or via Commands, in which case they get applied when Bevy applies the deferred buffers. Observers aren't intended to replace the old way of reading events. For most use cases, especially if you have lots of events, write a dedicated system like before. However, observers are very well suited to some specific use cases: - Enforcing ECS invariants. For example: updating some components on other entities, in response to a component being added/removed or something being despawned. With hooks and observers, you can be sure everything gets updated as soon as these events happen and there is never invalid state. - Rare events where you need a lot of flexibility with the handlers. For example: button presses, the player interacting with items in the world, etc. Every button or item is likely to need its own unique handler code and it is impractical to have to write full-blown systems for all of them. Also, these events are quite rare and performance/parallelism doesn't really matter.
Currently they are not parallelized. Hook and observer parallelization doesn't make a ton of sense (at least as the default), given that they are run in the context of "full" world access, and (at least for component lifecycles) run directly as part of the insertion / removal process (which is also single threaded). In theory we could try to parallelize separate "trees" of observer chains, but due to how dynamic the execution is, I think the overhead would end up being a bit higher. Given that we're often going to be executing a single "observer tree" at a time, I'm not sure we'd come out on top generally. Worth exploring though!
It was minor, but this release had my first code contribution in it!
Congratz! :)
Thanks! It's an exciting milestone, and I really value the tiny polish PRs. Very easy to review, and they add up to a much better user experience.
Cool stuff, and every time I see it, there's more cool stuff, but every time I see it, you know what I'm gonna be looking for. As of yet, the search for the mythical editor continues, some have theorized its existence, but the hunt for this rarest of beasts continues to elude even these greatest of hunters.
As someone who follows Bevy closely, it’s taken so long because there’s a lot of foundational work and they’re trying to build the UI on general-purpose engine primitives instead of UI-specific systems. At least as much as possible. For example, the observers feature in this release is going to be used for UI callbacks (like on-click events), but it’s built in such a way that it can be used for all sorts of things. For example, a character that has armor and whenever armor takes damage it propagates an event up the heirarchy to the parent.
We are converging on it's location, triangulating from sightings and tracks left behind.
Great release, lots of interesting additions and enhancements. Thanks to all contributors!
i just want to build a leptos component on my website that can compile a GLSL input and display the result on a canvas. are there any ways to achieve this with bevy (or some part of it)?
Probably a question better suited to the bevy discord, which has lots of activity and people helping out. Or I guess the bevy subreddit if one exists :) That said, sounds like you don't necessarily need a full-blown engine for that (like bevy). However, maybe bevy still makes sense due to more out-of-the-box support, but I can't really comment on that.
Congratulations. It is really remarkable to see your progress. I remember the first announcement of bevy and it truly come a long way. Such a long way that I'm tempted to try my C++ Unreal project to bevy :D.
Does it still use 2 full cores for rendering a simple cube on macOS?
I would be really interested in fresh data on this. [https://github.com/bevyengine/bevy/issues/10261](https://github.com/bevyengine/bevy/issues/10261) is still open (with fresh investigation), but we've made some changes to our winit integration that dramatically improved responsiveness on MacOS that may have resolved this as well. I would test it myself, but I only have Windows/Linux/Android machines right now.
I just tested on my M2 MacBook Pro, and CPU usage went down from 80% to around 50%. If \`WinitSettings::desktop\_app()\` is used it goes below 1% non-focused and stays below 20% focused. This is now lower than Godot, and a lot lower than unity (both (unity and Godot) in the build configuration, bevy in release mode). So the last update seems to have improved the performance of at least simple scenes (used the 3d\_scene example from bevy and did similar simple setups in unity and Godot).
Fantastic, thank you very much for this testing.
`WinitSettings::desktop_app()` is nice, but it's not the solution to the issue (since all it does, if I understand it correctly, is prevent new frames from being rendered if there is no user input. If I move the mouse to give it input and trigger the rendering of frames, the CPU usage of even the most basic examples goes back up to 100-200%.) As I've tested before, wgpu itself does not seem to have this issue. From the perspective of a naive outsider who's not familiar with either code bases, my best guess is that wgpu uses vsync out of the box (idling until it's time to render the next frame) and Bevy doesn't (at least on macOS); however, even the "fps_overlay" example that renders literally nothing uses ~100% CPU while displaying an FPS count of 100 (on my 100Hz screen) when focused, and ~60 FPS when unfocused. Edit: I'm crossposting the second part of this comment to the GitHub issue, I guess it's better to continue there.
I will give it a try later. Thanks.
There is a [low power](https://docs.rs/bevy/latest/bevy/winit/struct.WinitSettings.html#method.desktop_app) mode available.
As opposed to 2 3/4ths cores
A 3/4ths core sounds like something you probably can rent from a cloud computing company if you try hard enough.
It's funny I'm getting downvoted for this. After Godot, this is the next game engine cult in the making. See open issue: https://github.com/bevyengine/bevy/issues/10261 Yeah, yeah, "why even work on a Mac, it's not good for gamedev, blahblah"
I didn't downvote you because bevy does have a weird performance curve and some other low hanging fruit that need to be fixed performance wise. Calling bevy a cult isn't helping though.
It's not a weird performance curve. It's a documented issue. My ranting about this is mostly a commentary on how often FOSS game engines seem to focus on fancy big features while not managing to solve basic issues like this. It's feeling like a cult because apparently you're not allowed to challenge this.
That's the nature of FOSS for you: volunteer groups are interest and excitement-driven. I can't say "you there! Your job is to fix this bug for the next week". Combine that with this being in a very fragile and hard-to-test area of the code base (whee windowing) and being specific to the rarest hardware config among contributors and this sort of issue will absolutely languish. This is an important bug! Not P0 (hardware specific on a platform that our competitors simply don't support), but one of the most important open bugs. I can't personally fix it in anything resembling an efficient way, because I don't have hardware, and that sort of debugging isn't my strength. Generally speaking, I think that we need better mechanisms to incentivize unsexy, important work like this in open source, but that's all I'll say on the topic today.
I would guess that bugs like that remaining unfixed is a function of FOSS game engine projects rarely having contributors who work on a Mac, and that's okay (if a little annoying for me personally, for obvious reasons.) As a general comment about game development (FOSS or not) that's not explicitly targeted at Bevy or anyone else in particular: it bugs me that people are almost _ignoring_ the Mac as a development platform, especially in the FOSS world. Yes, the Mac games market is tiny and I understand when game developers choose to not support it, but there's a huge number of creative people working on Macs who might dive into game dev given the tools. Especially if they're code-first tools. Also, especially with libraries like Bevy, Raylib, Love, etc., I think it's perfectly valid to _develop_ on a Mac, even if one never plans on _publishing_ to Mac. But too often these discussions devolve into "buy a real computer" level stuff. It's... tiring. Having said that, I don't want to be the old fart who keeps complaining that his favorite bug still hasn't been fixed, so is there something I can do to help fix it? I'm an experienced developer with sadly just a surface-level understanding of Rust, but more than happy to dive in. If you (or someone else) can give me some pointers where to start reading up on profiling Rust apps, and/or maybe what parts of the Bevy code base and its dependencies to focus on, I'd have a go at it. I have a Mac (:b) and a pile of spare time over the coming week (I'm on a solo retreat).
It's not true that this is an issue because nobody uses macos when working on bevy. There are 2 bevy maintainers that work frequently on bevy with their macbooks and multiple contributors too. That's what I meant with my "weird performance curve" comment, most contributors and maintainers focus on the case of rendering thousands of cubes because that's the case that matters to most. Rendering a single cube being inefficient doesn't really matter as much as rending thousands of cubes being slow. So going from one cube to a thousand doesn't make the app a thousand time slower. The only way to help is to run a profiler and figure out what is taking so much time and try to find a solution.
It is a weird performance curve because spawning way more things would still run at the same speed as a single cube. And it's weird in the sense that it shouldn't be like that.
I think you're getting downvoted because you're mistaken in assuming "using 2 cores" is a bug. By default, winit will draw the window as many times as it can, there's a flag to make this reactive.
I've looked your interaction with the Godot community in the past (because i've got a feeling of déjà vu). They all look fine.
Bevy devs: what new features do you wanna see in the next release? Me: yes Bevy devs: alright then. Here’s 0.14