Zig has not hit 1.0 yet, and as recently as a few months ago completely reworked how every form of IO is written. AFAIK, this wasn't a syntax change, but it changed the function signature or type definition of every piece of code that reads/writes a file, establishes a connection, etc. At the current time, there is little guarantee that the code you write today will still work in 5-10 years time.
Thanks for the info, I was hoping there was something like Rust's editions that would allow for mixing libraries with differing language versions that have breaking changes.
Once you understand that a crate is the translation unit in Rust, it doesn't feel as bad. Most medium to large Rust project's will separate out their code into separate crates for both organization and compile time.
I've definitely cloned down my fair share of C projects, mashed the make command into my terminal, and watched the gcc/clang logs fly by and never batted an eye beyond checking the sha256sum on any downloaded tarballs.
There's a valid argument to be made about supply chain attacks, but there does exist tooling to lock that down, and I would argue that any serious software development firm should be auditing every third party dependency they take on.
More traditional game engines tend to be a giant tangle of pointers with much more complex lifetimes than what Rust's borrows would allow. For example, the skeleton used to animate your character is reliant on a centralized hierarchy of transforms, which is deeply interwoven with physics, rendering, gameplay scripting, etc. These relationships and lifetimes is difficult or impossible to model with Rust's borrows, forcing the use of unsafe, and makes it harder to expose safe Rust interfaces to engine users due to Rust's aliasing rules around borrows and essentially forces the use of a scripting runtime. These factors also make it very hard to make performant multithreaded code without littering locks or channels everywhere, in any language or runtime, not just with Rust.
Bevy's ECS handles this by flattening these relationships. Instead of pointer chasing through the physics system to fetch rigidbodies which then point to the transforms, you expose the backing ECS memory as a query view: `Query<(&mut Transform, &Rigidbody)>` directly fetches all entities that have the two components without relying on one to hold a reference to the other. The lifetimes of the queried components is strictly bound to the surrounding function (a system in ECS terminology) by the borrow checker, and all of the unsafe used to create those borrows is neatly packaged behind the ECS crate boundary. This is so effective that the majority of Bevy's crates can have `forbid(unsafe_code)` enabled.
The downside here is that all of the complexity is now centralized into the bevy_ecs crate: there are many parts in it that are basically C written in Rust, but that does mean that we can focus all of our memory safety efforts on that one crate instead of making that collective responsibility of everyone in the ecosystem.
Of course, we do expose unsafe APIs from the ECS, but the use of this escape hatch explicitly demarcated, and generally you'll only see incremental performance improvements (no big-O algorithmic gains) over their safe variants. With the sole exception of `Query::get_unchecked_mut` allowing parallel access to mutable components that cannot be proven to be safe from static analysis (e.g. parallel hierarchy traversals), which enables parallelism where it otherwise would not be feasible.
I'm running a nanode for a few personal projects and their dashboard was showing something close to 8mbps since 05/29/2024. Went almost 2TB over for the month of June. Nearly 4x'ed my bill. It's not a lot, but it seems like someone's use case like mine (streaming music) could have easily exploded their monthly compute budget on this.
Just checked with nethogs, the VPS averages ~250kbps, so this is a near 32x increase in reported bandwidth usage on my end.
A scripting language is an explicit non-goal for first-party support, but there have been tools for using the ECS entirely without Rust types which can be exposed via FFI or embedded languages like Lua.
Just search "_by_id" in the bevy_ecs docs, and you'll find all of the associated APIs for access. There are then (unsafe) APIs for creating the internal mappings necessary to use them. These are normally called via the monomorphized generics automatically, but need to be manually called since we don't have compile time knowledge of the data being stored and accessed.
Given the fact that foreign values inherently require the use of unsafe due to not being able to verify anything about the value and it's behavior, yes, it's generally not recommended unless you're looking to write your own scripting integration plugin. Likewise, most of these scripting language runtimes are almost always not threadsafe in the slightest, requiring either single threading all scripted behavior, expensive locks, and heavy use of marshalling, which negates a lot of the performance benefits of the engine.
For more developer experience oriented reasons why this is done, I strongly suggest reading cart's reasons for making Bevy to begin with: https://github.com/bevyengine/bevy/discussions/8107#discussi.... More specifically the "Turtles all the way down" bullet point.
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.
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.
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 :)
I'm one of the maintainers of Bevy. In my opinion, Godot clearly has a significant lead in many fronts, some moreso than others. A clear few that are lagging behind are:
Editor: Godot has one, Bevy does not.
Animation support: Godot has support for complex animation blending and animating anything that can be serialized. Bevy does not.
Audio: Bevy's audio is pretty simple right now and lacks direct world entity driven spatial audio.
Rendering: Godot has pretty deep support for higher performance and higher fidelity rendering techniques like automatic instancing and
Everything in this list is being worked on, but require time to bake. Everything else more or less has most of the core pieces in place that Godot has, though may be missing a few small features here or there.
Where is Bevy ahead?
Multithreaded CPU performance. I can almost guarantee your average Bevy app will have higher thread utilization than your average Godot/Unity/Unreal game, and this will continue to scale as more complex computations are required for various engine systems are added.
Testability: ECS makes it really easy to write dependency injection based unit tests, something otherwise difficult to test end-to-end with engines like Godot and Unity.
Extendability and customization: Bevy is plugins all the way down. Godot definitely takes a much more monolithic approach to building an engine, and making significant changes to the core engine will require forking. Where Godot requires exposing deeper APIs for exposing functionality, Bevy already supports ripping out the relevant plugins and subsituting just those with your own.
Memory safety: As the mantra goes, every 1k LoC of C/C++, there's one CVE that is yet to be found, and 70% of those are memory safety issues. Bevy heavily leverages unsafe in the ECS, but rarely touches it in the other core engine crates. We can with high confidence say there are no memory safety problems or problems caused by undefined behavior in Bevy due to Rust's strong safety guarantees.
This question might be a little less fair -- what's the state of Bevy vs Fyrox?
And if you have a guess, how long will animation and editor support take? A wild guess is fine (though if you break out animation a bit, I'd be grateful).
Fyrox definitely has a better end-to-end feature offering right now, but I personally think Bevy has the stronger ecosystem.
Animation support is growing rapidly. I'm one of the two SMEs (subject matter experts) focused on this area, and we just rounded out the final parts of the animation composition RFC. I'm hoping to get that feature to land in 0.11, but may take until 0.12 to be fully available. There's also an open PR for animating morph targets, the primary other way of deforming meshes for animation, which I think should land in 0.11. I'm also working on inverse kinematics implementation, which should round out the core "animate to move things" features. More powerful animation features are likely going to be reliant on an editor going forward though.
The editor is definitely something we're pushing hard on. Cart recently just opened a PR rewriting the asset system to better support preprocessing and more complex asset interactions, something we desperately needed for the development of an editor. I'd like to say we'll break ground on the editor before Q3 of this year, but that might be an overaggressive target.
We explicitly label easy first issues in our issue tracker: https://github.com/bevyengine/bevy/issues?q=is%3Aissue+is%3A.... These should get you up to speed with the contribution process and, at the very minimum, get your feet wet with hacking against the engine, if not dive deeper into various specifics.
I strongly suggest any of the docs issues, as it doesn't require you to write any actual functionality, but forces you to get to know the architecture, the language, and the core parts of the engine itself.
Rendering is definitely moving really fast and we have a lot of accumulated domain expertise in the area now. If you're looking to potentially bootstrap or collaborate on design in a new space: animation or audio both need a lot more love. I'm one of the two animation SMEs and I still am playing catchup to the state of the art.
I want to step back a bit. All of these require a more involved and production ready asset system, which we've sorely needed for a few releases now.
I'm one of the two developers currently behind our longer term animation efforts, and I am keeping up with the state of the art in terms of animation compression, streaming, composition, and generation, but there's still a sizable amount of groundwork and plumbing before any of that can even be attempted. We definitely need a lot more eyes on this area of the engine.
