[binary132]

Wow. This seems like a really huge and impressive release, honestly. My impression of Bevy hasn’t always been the greatest for a number of reasons but I could possibly be convinced to see the light on this one! Kinda wish there was a C API though.

[jms55]

> My impression of Bevy hasn’t always been the greatest for a number of reasons but I could possibly be convinced to see the light on this one!

As one of the Bevy contributors, I'd love to hear what you didn't like in the past, and what you liked from this release. User feedback is super useful - I don't see the same set of pain points most users see since I work on the engine internals.

In general building a game engine is an _extremely_ large task - we're under no illusions that we're going to get it perfect the first time, or even the first few rewrites. But I'm fairly confident in the long term direction of the project, and the community we built and amount of developers contributing means I'm confident that we'll get there eventually :)

[lyu07282]

> As one of the Bevy contributors, I'd love to hear what you didn't like in the past, and what you liked from this release.

One issue that I always had with Bevy's development direction was how it felt a bit incongruent in a way. Like we get all these advanced rendering features but the boring basics are only slowly getting added. But of course it makes sense, its much more fun to work on a super advanced state of the art virtual geometry renderer (that is very impressive stuff) than it is to work on the boring parts.

I hope one day the foundation gets proper funding and can fund development with a clear focus and direction like the Blender foundation.

Why this release feels somehow different is because there are many mundane, boring but very foundational features added, like sorry but I do not give a fuck about chromatic aberration, but I do care about required components, animation masks, additive blending and events, box shadows, cosmic text, ui scrolling, interpolation functions and event propagation / bubbling.

Take the only now added animation masks, what use is an engine that supports visualized geometry (added in previous release) rendering but I can't render the hand movements of a character separate from the body? That's what I mean by incongruent, its not meant as a criticism, that's just how open source works of course but its still frustrating sometimes.

For the things still missing, for example: declarative scenes (in the works with BSN), asset streaming and pipeline events, (proper) rich text rendering, pointer and text selection events to name a few.

So seeing these "boring" things slowly getting added with each release also makes me very optimistic for the future of Bevy!

(notice how I didn't even mention the editor ;)

[jms55]

You're not at all wrong, but like you said it's the (sometimes unfortunate) reality of open source. We have a lot of rendering contributors, but less so for every other area except probably the core ECS.

Here's to hoping we get more boring contributions in the future!

What is pipeline events though? I haven't heard of that, and google isn't bringing anything up.

P.S. I'm actually the author of the virtual geometry feature, so that was a particularly well chosen example :)

[lyu07282]

> What is pipeline events though? I haven't heard of that, and google isn't bringing anything up.

Last time I checked there is no way to know if the async (render) pipeline compilation is completed. If I add a large scene to the world I don't know when it will be ready to render. In other words, its non-trivial to add a loading screen in many circumstances, or to do things like adding and removing scene bundles without causing pop-in or freezes, something that no game engine should struggle with. With something like pipeline events I mean if we could get events from the render world about the state of the pipelines or some other way to know, then we would at least be able to implement some kind of shader compilation stage / loading screen properly. I care more about that kind of stuff than rendering a gazillion triangles at 60fps, although that is pretty cool ofc.

> P.S. I'm actually the author of the virtual geometry feature, so that was a particularly well chosen example :)

I didn't realize lol It's really impressive work regardless!

[jms55]

Ah yeah pipeline compilation is a very non-trivial problem[1]. Unreal is also struggling with this a lot. I hear you that it's an issue.

The Bevy issue you want to follow is https://github.com/bevyengine/bevy/issues/10871.

[1]: https://therealmjp.github.io/posts/shader-permutations-part1 + https://therealmjp.github.io/posts/shader-permutations-part2

[binary132]

Totally subjective and superficial outsider view, but it has been my perception both that Bevy does not make great use of Rust features (i.e. I’ve heard it relies a lot on dynamic dispatch / there are things that can be done wrong which aren’t caught by the typesystem?) and that it lacks feature parity on certain important points (which I couldn’t be asked to enumerate) — which could be forgivable if its use of Rust’s typesystem was more advantageous given the first point but could be an issue if it wasn’t well differentiated by it.

[jms55]

I mean, kind of. It's a bit of a vague comment. Dynamic dispatch is not bad by itself, and as not-an-ECS-developer, I couldn't actually answer how much it is or is not used in the ECS internals. Probably more than I expect, but not enough to be an issue. Performance is plenty fast, we profile that pretty often.

As for things that can't be caught by the type system, it's not like we can enforce that the logic in system_b that expects a given entity to be alive won't accidentally break if you introduce some system_a later on that despawns the entity at some point. We can't compile-time validate that kind of safety for game logic - it's just not possible.

On the other hand there are things we can do that C++ based engines can't thanks to Rust. Compile-time variable mutability means we can know exactly what set of systems modify which pieces of data, which means we can automatically schedule different systems in parallel without any safety issues, or detect what when and who touched a piece of data last.

In terms of features, Bevy is still early in development. Feature parity with existing, 10-20 year engines with many paid developers is going to take a while. But I think we have some pretty compelling features on our own even today, foremost our focus on ECS and modularity.

In terms of what Rust brings, it has the performance of C++, but with better memory safety (mostly in terms of engine internals - not like user code touches lifetimes that often), thread safety, a way better and standard build system, some modern features like pattern matching and enums, etc. The usual ways in which Rust is better than C++.

The answer isn't so much "why would I want to use an engine in Rust" (although I personally love Rust and would absolutely choose it over a C++) but more "we want to make a new engine". You want C++ levels of performance, but without having to use C++, so Rust is an obviously compelling choice for a game engine.

[binary132]

Like I said: superficial, subjective, outsider perspective. :)

[_nth]

Heyo, another contributor here. I work in rust now professionally, and Bevy is part of what opened my eyes to the power of the language. The project makes deep complex use of rust’s memory safety and type system, but also takes great pains to wrap this complexity in simple and approachable APIs. We’re also almost always one of the first consumers of newly stabilized compiler features, usually bumping MSRV and incorporating the new features (for instance const float arithmetic) within days. I don’t see how it could have been written in any other language.