Thanks to 170 contributors, 623 pull requests, and our generous sponsors, I'm happy to announce the Bevy 0.6 release on crates.io!
For those who don't know, Bevy is a refreshingly simple data-driven game engine built in Rust. You can check out Quick Start Guide to get started. Bevy is also free and open source forever! You can grab the full source code on GitHub. Check out Bevy Assets for a collection of community-developed plugins, games, and learning resources.
To update an existing Bevy App or Plugin to Bevy 0.6, check out our 0.5 to 0.6 Migration Guide.
There are a ton of improvements, bug fixes and quality of life tweaks in this release. Here are some of the highlights:
.system()
!Read on for details!
Bevy 0.6 introduces a brand new modern renderer that is:
I promise I'll qualify all of those fluffy buzzwords below. I am confident that the New Bevy Renderer will be a rallying point for the Bevy graphics ecosystem and (hopefully) the Rust graphics ecosystem at large. We still have plenty of work to do, but I'm proud of what we have accomplished so far and I'm excited for the future!
Before we cover what's new, it's worth discussing why we embarked on such a massive effort. The old Bevy Renderer got a number of things right:
However, it also had a number of significant shortcomings:
The shortcomings above were acceptable in Bevy's early days, but were clearly holding us back as Bevy grew from a one person side project to the most popular Rust game engine on GitHub (and one of the most popular open source game engines ... period). A "passable" renderer no longer cuts it when we have hundreds of contributors, a paid full-time developer, thousands of individual users, and a growing number of companies paying people to work on Bevy apps and features. It was time for a change.
For a deeper view into our decision-making and development process (including the alternatives we considered) check out the New Renderer Tracking Issue.
Pipelined Rendering is a cornerstone of the new renderer. It accomplishes a number of goals:
From a high level, traditional "non-pipelined rendering" looks like this:
Pipelined rendering looks like this:
Much better!
Bevy apps are now split into the Main App, which is where app logic occurs, and the Render App, which has its own separate ECS World and Schedule. The Render App consists of the following ECS stages, which developers add ECS Systems to when they are composing new render features:
So pipelined rendering actually looks more like this, with the next app update occurring after the extract step:
As a quick callout, pipelined rendering doesn't actually happen in parallel yet. I have a branch with parallel pipelining enabled, but running app logic in a separate thread currently breaks "non send" resources (because the main app is moved to a separate thread, breaking non send guarantees). There will be a fix for this soon, I just wanted to get the new renderer in peoples' hands as soon as possible! When we enable parallel pipelining, no user-facing code changes will be required.
The New Bevy Renderer has a Render Graph, much like the old Bevy renderer. Render Graphs are a way to logically model GPU command construction in a modular way. Graph Nodes pass GPU resources like Textures and Buffers (and sometimes Entities) to each other, forming a directed acyclic graph. When a Graph Node runs, it uses its graph inputs and the Render World to construct GPU command lists.
The biggest change to this API is that we now support Sub Graphs, which are basically "namespaced" Render Graphs that can be run from any Node in the graph with arbitrary inputs. This enables us to define things like a "2d" and "3d" sub graph, which users can insert custom logic into. This opens two doors simultaneously:
Bevy has always used wgpu, a native GPU abstraction layer with support for most graphics backends: Vulkan, Metal, DX12, OpenGL, WebGL2, and WebGPU (and WIP DX11 support). But the old renderer hid it behind our own hardware abstraction layer. In practice, this was largely just a mirror of the wgpu API. It gave us the ability to build our own graphics backends without bothering the wgpu folks, but in practice it created a lot of pain (due to being an imperfect mirror), overhead (due to introducing a dynamic API and requiring global mutex locks over GPU resource collections), and complexity (bevy_render -> wgpu -> Vulkan). In return, we didn't get many practical benefits ... just slightly more autonomy.
The truth of the matter is that wgpu already occupies exactly the space we want it to:
However, initially there were a couple of reasons not to make it our "public facing API":
Almost immediately after we voiced these concerns, @kvark kicked off a relicensing effort that switched wgpu to the Rust-standard dual MIT/Apache-2.0 license. They also removed gfx-hal in favor of a much simpler and flatter architecture. Soon after, @zicklag added a WebGL2 backend. Having resolved all of my remaining hangups, it was clear to me that @kvark's priorities were aligned with mine and that I could trust them to adjust to community feedback.
The New Bevy Renderer tosses out our old intermediate GPU abstraction layer in favor of using wgpu directly as our "low-level" GPU api. The result is a simpler (and faster) architecture with full and direct access to wgpu. Feedback from Bevy Renderer feature developers so far has been very positive.
Bevy was also updated to use the latest and greatest wgpu version: 0.12.
The new renderer is what I like to call "ECS-driven":
RenderPhase<T: PhaseItem>
Components, where T defines the "type and scope" of thing being rendered in the phase (ex: "transparent 3d entities in the main pass"). At its core, a RenderPhase
is a (potentially sorted) list of Entities to be drawn.SetStandardMaterialBindGroup
, DrawMesh
, SetItemPipeline
, etc. Bevy provides a number of built-in DrawCommands and users can also define their own.If that seems complicated ... don't worry! These are what I like to call "mid-level" renderer APIs. They provide the necessary tools for experienced render feature developers to build modular render plugins with relative ease. We also provide easy to use high-level APIs like Materials, which cover the majority of "custom shader logic" use cases.
The new renderer is very flexible and unopinionated by default. However, too much flexibility isn't always desirable. We want a rich Bevy renderer plugin ecosystem where developers have enough freedom to implement what they want, while still maximizing compatibility across plugins.
The new bevy_core_pipeline
crate is our answer to this problem. It defines a "core" set of Views / Cameras (2d and 3d), Sub Graphs (ClearPass, MainPass2d, MainPass3d), and Render Phases (Transparent2d
, Opaque3d
, AlphaMask3d
, Transparent3d
). This provides a "common ground" for render feature developers to build on while still maintaining compatibility with each other. As long as developers operate within these constraints, they should be compatible with the wider ecosystem. Developers are also free to operate outside these constraints, but that also increases the likelihood that they will be incompatible.
Bevy's built-in render features build on top of the Core Pipeline (ex: bevy_sprite
and bevy_pbr
). The Core Pipeline will continue to expand with things like a standardized "post-processing" effect stack.
The new renderer structure gives developers fine-grained control over how entities are drawn. Developers can manually define Extract, Prepare, and Queue systems to draw entities using arbitrary render commands in custom or built-in
RenderPhases
. However this level of control necessitates understanding the render pipeline internals and involve more boilerplate than most users are willing to tolerate. Sometimes all you want to do is slot your custom material shader into the existing pipelines!
The new
Material
trait enables users to ignore nitty gritty details in favor of a simpler interface: just implement the
Material
trait and add a
MaterialPlugin
for your type. The new shader_material.rs example illustrates this.
// register the plugin for a CustomMaterial
app.add_plugin
There is also a
SpecializedMaterial
variant, which enables "specializing" shaders and pipelines using custom per-entity keys. This extra flexibility isn't always needed, but when you need it, you will be glad to have it! For example, the built-in StandardMaterial uses specialization to toggle whether or not the Entity should receive lighting in the shader.
We also have big plans to make
Materials
even better:
Drawing things is expensive! It requires writing data from the CPU to the GPU, constructing draw calls, and running shaders. We can save a lot of time by not drawing things that the camera can't see. "Frustum culling" is the act of excluding objects that are outside the bounds of the camera's "view frustum", to avoid wasting work drawing them. For large scenes, this can be the difference between a crisp 60 frames per second and chugging to a grinding halt.
Bevy 0.6 now automatically does frustum culling for 3d objects using their axis-aligned bounding boxes. We might also enable this for 2d objects in future releases, but the wins there will be less pronounced, as drawing sprites is now much cheaper thanks to the new batched rendering.
Directional Lights can now cast "directional shadows", which are "sun-like" shadows cast from a light source infinitely far away. These can be enabled by setting DirectionalLight::shadows_enabled
to true
.
Note: directional shadows currently require more manual configuration than necessary (check out the shadow_projection
field in the DirectionalLight
setup in the shadow_biases.rs example). We will soon make this automatic and better quality over a larger range through cascaded shadow maps.
Point lights can now cast "omnidirectional shadows", which can be enabled by setting PointLight::shadows_enabled
to true
:
Mesh entities can opt out of casting shadows by adding the
NotShadowCaster
component.
commands.entity.insert;
Likewise, they can opt out of receiving shadows by adding the
NotShadowReceiver
component.
commands.entity.insert;
PointLight
Components can now define a radius
value, which controls the size of the sphere that emits light. A normal zero-sized "point light" has a radius of zero.
(Note that lights with a radius don't normally take up physical space in the world ... I added meshes to help illustrate light position and size)
Bevy's StandardMaterial now has an alpha_mode
field, which can be set to AlphaMode::Opaque
, AlphaMode::Mask(f32)
, or AlphaMode::Blend
. This field is properly set when loading GLTF scenes.
Modern scenes often have many point lights. But when rendering scenes, calculating lighting for each light, for each rendered fragment rapidly becomes prohibitively expensive as the number of lights in the scene increases. Clustered Forward Rendering is a popular approach that increases the number of lights you can have in a scene by dividing up the view frustum into "clusters" (a 3d grid of sub-volumes). Each cluster is assigned lights based on whether they can affect that cluster. This is a form of "culling" that enables fragments to ignore lights that aren't assigned to their cluster.
In practice this can significantly increase the number of lights in the scene:
Clusters are 3d subdivisions of the view frustum. They are cuboids in projected space so for a perspective projection, they are stretched and skewed in view space. When debugging them in screen space, you are looking along a row of clusters and so they look like squares. Different colors within a square represent mesh surfaces being at different depths in the scene and so they belong to different clusters:
The current implementation is limited to at most 256 lights as we initially prioritized cross-platform compatibility so that everyone could benefit. WebGL2 specifically does not support storage buffers and so the implementation is currently constrained by the maximum uniform buffer size. We can support many more lights on other platforms by using storage buffers, which we will add support for in a future release.
Click here for a video that illustrates Bevy's clustered forward rendering.
Sprites are now rendered in batches according to their texture within a z-level. They are also opportunistically batched across z-levels. This yields significant performance wins because it drastically reduces the number of draw calls required. Combine that with the other performance improvements in the new Bevy Renderer and things start to get very interesting! On my machine, the old Bevy renderer generally started dropping below 60fps at around 8,000 sprites in our "bevymark" benchmark. With the new renderer on that same machine I can get about 100,000 sprites!
My machine: Nvidia GTX 1070, Intel i7 7700k, 16GB ram, Arch Linux
Sprite entities are now simpler to spawn:
No need to manage sprite materials! Their texture handle is now a direct component and color can now be set directly on the
Sprite
component.
// Old (Bevy 0.5)
Bevy now uses WGSL for our built-in shaders and examples. WGSL is a new shader language being developed for WebGPU (although it is a "cross platform" shader language just like GLSL). Bevy still supports GLSL shaders, but WGSL is nice enough that, for now, we are treating it as our "officially recommended" shader language. WGSL is still being developed and polished, but given how much investment it is receiving I believe it is worth betting on. Consider this the start of the "official Bevy shader language" conversation, not the end of it.
: View;
mesh: Mesh;
;
;
view
Bevy now has its own custom shader preprocessor. It currently supports #import
, #ifdef FOO
, #ifndef FOO
, #else
, and #endif
, but we will be expanding it with more features to enable simple, flexible shader code reuse and extension.
Shader preprocessors are often used to conditionally enable shader code:
#ifdef TEXTURE
var sprite_texture: ;
#endif
This pattern is very useful when defining complicated / configurable shaders (such as Bevy's PBR shader).
The new preprocessor supports importing other shader files (which pulls in their entire contents). This comes in two forms:
Asset path imports:
#import "shaders/cool_function.wgsl"
Plugin-provided imports, which can be registered by Bevy Plugins with arbitrary paths:
#import mesh_view_bind_group
We also plan to experiment with using Naga for "partial imports" of specific, named symbols (ex: import a specific function or struct from a file). It's a 'far out' idea, but this could also enable using Naga's intermediate shader representation as a way of combining pieces of shader code written in different languages into one shader.
When shaders use a preprocessor and have multiple permutations, the associated "render pipeline" needs to be updated to accommodate those permutations (ex: different Vertex Attributes, Bind Groups, etc). To make this process straightforward, we added the SpecializedPipeline trait, which allows defining specializations for a given key:
Implementors of this trait can then easily and cheaply access specialized pipeline variants (with automatic per-key caching and hot-reloading). If this feels too abstract / advanced, don't worry! This is a "mid-level power-user tool", not something most Bevy App developers need to contend with.
Bevy now uses Naga for all of its shader needs. As a result, we were able to remove all of our complicated non-rust shader dependencies: glsl_to_spirv
, shaderc
, and spirv_reflect
. glsl_to_spirv
was a major producer of platform-specific build dependencies and bugs, so this is a huge win!
Render logic for internal Bevy crates had to be rewritten in a number of cases to take advantage of the new renderer. The following people helped with this effort:
Bevy now has built-in support for deploying to the web using WebGL2 / WASM, thanks to @zicklag adding a native WebGL2 backend to wgpu. There is now no need for the third party bevy_webgl2
plugin. Any Bevy app can be deployed to the web by running the following commands:
cargo build --target wasm32-unknown-unknown
wasm-bindgen --out-dir OUTPUT_DIR --target web TARGET_DIR
The New Bevy Renderer developers prioritized cross-platform compatibility for the initial renderer feature implementation and so had to carefully operate within the limits of WebGL2 (ex: storage buffers and compute shaders aren't supported in WebGL2), but the results were worth it! Over time, features will be implemented that leverage more modern/advanced features such as compute shaders. But it is important to us that everyone has access to a solid visual experience for their games and applications regardless of their target platform(s).
You can try out Bevy's WASM support in your browser using our new Bevy Examples page:
For improved precision in the "useful range", the industry has largely adopted "reverse projections" with an "infinite" far plane. The new Bevy renderer was adapted to use the "right-handed infinite reverse z" projection. This Nvidia article does a great job of explaining why this is so worthwhile.
The new renderer makes it possible for users to write compute shaders. Our new "compute shader game of life" example (by @jakobhellermann) illustrates how to write compute shaders in Bevy.
The "multiple windows" example has been updated to use the new renderer APIs. Thanks to the new renderer APIs, this example is now much nicer to look at (and will look even nicer when we add high-level Render Targets).
Bevy's old Bytes
abstraction has been replaced with a fork of the crevice crate (by @LPGhatguy), which makes it possible to write normal Rust types to GPU-friendly data layouts. Namely std140 (uniform buffers default to this layout) and std430 (storage buffers default to this layout). Bevy exports AsStd140
and AsStd430
derives:
Coupling an AsStd140
derive with our new UniformVec<T>
type makes it easy to write Rust types to shader-ready uniform buffers:
// WGSL shader
;
mesh: Mesh;
We (in the short term) forked crevice for a couple of reasons:
Ultimately, we'd like to move back upstream if possible. A big thanks to the crevice developers for building such useful software!
Bevy now has a built-in "uv sphere" mesh primitive.
from
The Mesh
type now has a compute_flat_normals()
function. Imported GLTF meshes without normals now automatically have flat normals computed, in accordance with the GLTF spec.
@DJMcNab fixed nasty non-linear loading of GLTF nodes, which made them load much faster. One complicated scene went from 40 seconds to 0.2 seconds. Awesome!
@mockersf made GLTF textures load asynchronously in Bevy's "IO task pool", which almost halved GLTF scene load times in some cases.
We are also in the process of adding "compressed texture loading", which will substantially speed up GLTF scene loading, especially for large scenes!
.system()
!
#
One of our highest priorities for Bevy ECS is "ergonomics". In the past I have made wild claims that Bevy ECS is the most ergonomic ECS in existence. We've spent gratuitous amounts of R&D pioneering new API techniques and I believe the results speak for themselves:
// This is a standalone Bevy 0.5 App that adds a simple `gravity` system to the App's schedule
// and automatically runs it in parallel with other systems
I believe we were already the best in the market by a wide margin (especially if you take into account our automatic parallelization and change detection), but we had one thing holding us back from perfection ... that pesky .system()
! We've tried removing it a number of times, but due to rustc limitations and safety issues, it always eluded us. Finally, @DJMcNab found a solution. As a result, in Bevy 0.6 you can now register the system above like this:
// pure bliss!
new
.add_plugins
.add_system
.run;
In Bevy 0.6 types no longer implement the
Component
trait by default. Before you get angry ... stick with me for a second. I promise this is for the best! In past Bevy versions, we got away with "auto implementing"
Component
for types using this "blanket impl":
This removed the need for users to manually implement
Component
for their types. Early on this seemed like an ergonomics win with no downsides. But Bevy ECS, our understanding of the problem space, and our plans for the future have changed a lot since then:
#help
channel threads on our Discord. This class of error is very hard to debug because things just silently "don't work". When not everything is a Component, rustc can properly yell at you with informative errors when you mess up.on_insert(world: &mut World)
to the Component trait. Very useful! Hopefully by now you're convinced that this is the right move. If not ... I'm sorry ... you still need to implement Component manually in Bevy 0.6. You can either derive Component:
// defaults to "Table" storage
;
// overrides the default storage
;
Or you can manually implement it:
;
Mutable queries can now be immutably iterated, returning immutable references to components:
Compare that to the complicated QuerySet that this would have needed in previous Bevy versions to avoid conflicting immutable and mutable Queries:
// Gross!
Have you ever wanted to use "system params" directly with a Bevy World? With
SystemState
, now you can!
let mut system_state: = new;
let = system_state.get;
For those working directly with World
, this is a game changer. It makes it possible to mutably access multiple disjoint Components and Resources (often eliminating the need for more costly abstractions like WorldCell
).
SystemState
does all of the same caching that a normal Bevy system does, so reusing the same SystemState results in uber-fast World access.
The new Bevy renderer requires strict separation between the "main app" and the "render app". To enable this, we added the concept of "sub-apps":
;
let mut render_app = empty;
app.add_sub_app;
// later
app.sub_app_mut
.add_system;
.add_system;
We plan on exposing more control over scheduling, running, and working with sub-apps in the future.
You can now iterate all combinations of N entities for a given query:
This is especially useful for things like "checking for entities for collisions with all other entities". There is also an iter_combinations_mut
variant. Just be careful ... the time complexity of this grows exponentially as the number of entities in your combinations increases. With great power comes great responsibility!
The new iter_combinations example illustrates how to use this new API to calculate gravity between objects in a "solar system":
System Commands got a nice performance boost by changing how command buffers are stored and reused:
This benchmark spawns entities with a variety of component compositions to ensure we cover a variety of cases. Treat these numbers as relatives, not absolutes.
System and Query lifetimes were made more explicit by splitting out the 'system
and 'world
, lifetimes and using them explicitly where possible. This enables Rust to reason about ECS lifetimes more effectively, especially for read-only lifetimes. This was particularly important because it enabled the new Bevy Renderer to convince wgpu that ECS resources actually live for as long as the Render World.
Note that this does make the lifetimes on SystemParam derives slightly more complicated as a result:
Bevy ECS received a solid number of soundness and correctness bug fixes this release, alongside some unsafe code block removals. Queries and internal storages like Tables and BlobVecs in particular had a number of fixes and improvements in these areas. As Bevy ECS matures, our bar for unsafe code blocks and soundness must also mature. Bevy ECS will probably never be 100% free of unsafe code blocks, because we are modeling parallel data access that Rust literally cannot reason about without our help. But we are committed to removing as much unsafe code as we can (and we have a number of refactors in the works to further improve the situation).
// Despawns all descendants of an entity (its children, its childrens' children, etc)
commands.entity.despawn_descendants;
// Removes the given children from the entity
commands.entity.remove_children;
UI now respects the flexbox Overflow::Hidden
property. This can be used to cut off child content, which is useful when building things like scrollable lists:
Text2d
now supports arbitrary transformations using the Transform component:
Note that while Transform::scale
does have its uses, it is generally still a good idea to adjust text size using the "font size" to ensure it renders "crisply".
Winit's "window transparency" feature is now exposed in Bevy's Window type. This allows users to build "widget like" apps without backgrounds or window decorations (on platforms that support it). Here is a Bevy app with a transparent background, rendering a Bevy Logo sprite on top of my Linux desktop background. Seamless! Cool!
Bevy Transforms now have friendly "directional" functions that return relative vectors:
// Points to the left of the transform
let left: Vec4 = transform.left;
// Points to the right of the transform
let right: Vec4 = transform.right;
// Points up from the transform
let up: Vec4 = transform.up;
// Points down from the transform
let down: Vec4 = transform.down;
// Points forward from the transform
let forward: Vec4 = transform.forward;
// Points back from the transform
let back: Vec4 = transform.back;
Transforms now have helpful with_translation()
, with_rotation()
, and with_scale()
builder methods:
.with_scale
from_xyz
Bevy has been updated to use Rust 2021. This means we can take advantage of the new Cargo feature resolver by default (which both Bevy and the new wgpu version require). Make sure you update your crates to Rust 2021 or you will need to manually enable the new feature resolver with resolver = "2"
in your Cargo.toml.
[]
= "your_app"
= "0.1.0"
= "2021"
Note that "virtual Cargo workspaces" still need to manually define resolver = "2"
, even in Rust 2021. Refer to the Rust 2021 documentation for details.
[]
= "2" # Important! wgpu/Bevy needs this!
= [ "my_crate1", "my_crate2" ]
Bevy 0.6 adds a Gamepads
resource, which automatically maintains a collection of connected gamepads.
Input
collections now have an any_pressed()
function, which returns true when any of the given inputs are pressed.
The new renderer now has tracing spans for frames, the render app schedule, and the Render Graph (with named Sub Graphs spans). The system executor now has finer grained spans, filling in most of the remaining blanks. Applying System Commands also now has spans.
(ignore those weird characters in the spans ... we're investigating that)
Bevy now supports the tracy profiler via the trace_tracy
Cargo feature.
Types can now derive the new FromReflect
trait, which enables creating "clones" of a type using arbitrary Reflect
impls. This is currently used to make reflected collection types (like Vec
) work properly, but it will also be useful for "round trip" conversions to and from Reflect
types.
let foo = from_reflect.unwrap;
To make it easier to search for and discuss common Bevy errors, we decided to add a formal error codes system, much like the one that rustc uses;
Error codes and their descriptions also have an automatically-generated page on the Bevy website.
The curated awesome-bevy GitHub repo containing a list of Bevy plugins, crates, apps, and learning resources is now reborn as Bevy Assets!
Bevy Assets introduces:
This is just the beginning! We have plans to integrate with crates.io and GitHub, improve indexing / tagging / searchability, add asset-specific pages, prettier styles, content delivery, and more. Ultimately we want this to grow into something that can enable first-class, modern asset-driven workflows.
We have automatically migrated existing awesome-bevy entries, but we encourage creators to customize them! If you are working on something Bevy related, you are highly encouraged to add a Bevy Assets entry.
Thanks to the relevant contributors (all 246 of them), Bevy is now dual licensed under MIT and Apache-2.0, at the developers' option. This means developers have the flexibility to choose the license that best suits their specific needs. I want to stress that this is now less restrictive than MIT-only, not more.
I originally chose to license Bevy exclusively under MIT for a variety of reasons:
However, there were a variety of issues that have come up that make dual-licensing Bevy under both MIT and Apache-2.0 compelling:
I've been at my scalability limits for a while. It has been * cough * ... challenging ... to build the engine features I need to, review every single pull request quickly, and preserve my mental health. I've made it this far ... sometimes by overworking myself and sometimes by letting PRs sit unmerged for longer than I'd like. By scaling out, we can have our cake and eat it too!
After much discussion about naming conventions and colors, we finally have a fresh new set of issue labels (loosely inspired by the rust repo). The Bevy Triage Team can finally express themselves fully!
We now have a relatively complete Contributors Guide. If you are interested in contributing code or documentation to Bevy, that is a great place to start!
We made a ton of CI improvements this release:
S-Needs-Triage
labelBevy development continues to pick up steam, and we have no intention to slow down now! In addition to the many RFCs we have in the works, we also plan on tackling the following over the next few months:
In the last two Bevy releases we made massive, sweeping changes to core systems. Bevy 0.5 was "the one where we rewrote Bevy ECS". Bevy 0.6 was "the one where we rewrote Bevy Render". These massive reworks took time, and as a result held back a bunch of other useful features and bug fixes. They also created pressure to "crunch" and finish big features quickly to unblock releases. Crunching is unhealthy and should be avoided at all costs!
The Bevy Community has reached relative consensus that we should have a more regular, more predictable release schedule. One where large features can't gum up the system.
From now on, we will cut releases approximately once every three months (as an upper bound ... sometimes we might release early if it makes sense). After the end of a release cycle, we will start preparing to cut a release. If there are small tweaks that need to be made or "life happens" ... we will happily postpone releases. But we won't hold releases back for "big ticket" items anymore.
We are balancing a lot of different concerns here:
We will refine this process over time and see what works best.
We will break ground on the Bevy Editor this year. To do that, we need a number of improvements to Bevy UI:
We now have a plethora of UI experiments in the Bevy community. Over the next few months we will refine our scope and begin the process of "selecting a winner".
Preprocessing assets is a critical part of a production game engine. It cuts down on startup times, reduces our CPU and GPU memory footprint, enables more complicated development workflows, makes it easier to ship assets with games, and cuts down on the final size of a deployed game. We've made it this far without an asset preprocessing system ... but barely. Solving this problem ASAP is a high priority for me.
Nested scenes, property overrides, inline assets, and nicer syntax are all on the agenda. We already have a number of working experiments in these areas, so we should see relatively quick progress here.
The current Bevy Book is a great way to learn how to set up Bevy and dip your toes into writing Bevy Apps. But it barely scratches the surface of what Bevy can do.
To solve this problem @alice-i-cecile has started working on a new Bevy Book, with the goal of being a complete learning resource for Bevy. If you are interested in helping out, please reach out to them!
The Bevy Community is a vibrant and active place. Currently most community content is posted in the #showcase
section of The Bevy Discord. The upcoming Monthly Bevy Newsletter will be a consolidated, shareable resource that we will post to places like Reddit and Twitter.
Sponsorships help make my full time work on Bevy sustainable. If you believe in Bevy's mission, consider sponsoring me (@cart) ... every bit helps!
A huge thanks to the 170 contributors that made this release (and associated docs) possible! In random order:
#[derive(Component)]
on all component structsOverflow::Hidden
style property for UIiter_combinations
on query to iterate over combinations of query resultsRenderPipelineCache
set_cursor_icon(...)
to Window
iter_mut()
for Assets typeWorldQuery
for WithBundle
Commands
performance.system
.system()
, part 2.system()
, part 3.system()
, part 4 (run criteria).system()
, part 6 (chaining)iter_combinators
examples prettier sub_app
return an &App
and add sub_app_mut() -> &mut App
wasm-bindgen
feature on gilrsTrackedRenderPass
String
and &String
as Id
for AssetServer.get_handle(id)
ron
winit
& fix cargo-deny
listsbevy_asset
and bevy_ecs
.insert_resource(T::default())
calls with init_resource::<T>()
ScheduleRunnerPlugin
Fetch
with_capacity()
.SystemParam
on private typesComponent
macro's component
storage
attribute.Camera::world_to_screen()
Query::get_component
Default
implementation of Image
so that size and data matchAssetServer::get_handle_path
LoadState
with invalid asset extensionPipelineCompiler::compile_pipeline()
step_modeQuery::for_each_mut