![]() # Problem Definition The current change tracking (via flags for both components and resources) fails to detect changes made by systems that are scheduled to run earlier in the frame than they are. This issue is discussed at length in [#68](https://github.com/bevyengine/bevy/issues/68) and [#54](https://github.com/bevyengine/bevy/issues/54). This is very much a draft PR, and contributions are welcome and needed. # Criteria 1. Each change is detected at least once, no matter the ordering. 2. Each change is detected at most once, no matter the ordering. 3. Changes should be detected the same frame that they are made. 4. Competitive ergonomics. Ideally does not require opting-in. 5. Low CPU overhead of computation. 6. Memory efficient. This must not increase over time, except where the number of entities / resources does. 7. Changes should not be lost for systems that don't run. 8. A frame needs to act as a pure function. Given the same set of entities / components it needs to produce the same end state without side-effects. **Exact** change-tracking proposals satisfy criteria 1 and 2. **Conservative** change-tracking proposals satisfy criteria 1 but not 2. **Flaky** change tracking proposals satisfy criteria 2 but not 1. # Code Base Navigation There are three types of flags: - `Added`: A piece of data was added to an entity / `Resources`. - `Mutated`: A piece of data was able to be modified, because its `DerefMut` was accessed - `Changed`: The bitwise OR of `Added` and `Changed` The special behavior of `ChangedRes`, with respect to the scheduler is being removed in [#1313](https://github.com/bevyengine/bevy/pull/1313) and does not need to be reproduced. `ChangedRes` and friends can be found in "bevy_ecs/core/resources/resource_query.rs". The `Flags` trait for Components can be found in "bevy_ecs/core/query.rs". `ComponentFlags` are stored in "bevy_ecs/core/archetypes.rs", defined on line 446. # Proposals **Proposal 5 was selected for implementation.** ## Proposal 0: No Change Detection The baseline, where computations are performed on everything regardless of whether it changed. **Type:** Conservative **Pros:** - already implemented - will never miss events - no overhead **Cons:** - tons of repeated work - doesn't allow users to avoid repeating work (or monitoring for other changes) ## Proposal 1: Earlier-This-Tick Change Detection The current approach as of Bevy 0.4. Flags are set, and then flushed at the end of each frame. **Type:** Flaky **Pros:** - already implemented - simple to understand - low memory overhead (2 bits per component) - low time overhead (clear every flag once per frame) **Cons:** - misses systems based on ordering - systems that don't run every frame miss changes - duplicates detection when looping - can lead to unresolvable circular dependencies ## Proposal 2: Two-Tick Change Detection Flags persist for two frames, using a double-buffer system identical to that used in events. A change is observed if it is found in either the current frame's list of changes or the previous frame's. **Type:** Conservative **Pros:** - easy to understand - easy to implement - low memory overhead (4 bits per component) - low time overhead (bit mask and shift every flag once per frame) **Cons:** - can result in a great deal of duplicated work - systems that don't run every frame miss changes - duplicates detection when looping ## Proposal 3: Last-Tick Change Detection Flags persist for two frames, using a double-buffer system identical to that used in events. A change is observed if it is found in the previous frame's list of changes. **Type:** Exact **Pros:** - exact - easy to understand - easy to implement - low memory overhead (4 bits per component) - low time overhead (bit mask and shift every flag once per frame) **Cons:** - change detection is always delayed, possibly causing painful chained delays - systems that don't run every frame miss changes - duplicates detection when looping ## Proposal 4: Flag-Doubling Change Detection Combine Proposal 2 and Proposal 3. Differentiate between `JustChanged` (current behavior) and `Changed` (Proposal 3). Pack this data into the flags according to [this implementation proposal](https://github.com/bevyengine/bevy/issues/68#issuecomment-769174804). **Type:** Flaky + Exact **Pros:** - allows users to acc - easy to implement - low memory overhead (4 bits per component) - low time overhead (bit mask and shift every flag once per frame) **Cons:** - users must specify the type of change detection required - still quite fragile to system ordering effects when using the flaky `JustChanged` form - cannot get immediate + exact results - systems that don't run every frame miss changes - duplicates detection when looping ## [SELECTED] Proposal 5: Generation-Counter Change Detection A global counter is increased after each system is run. Each component saves the time of last mutation, and each system saves the time of last execution. Mutation is detected when the component's counter is greater than the system's counter. Discussed [here](https://github.com/bevyengine/bevy/issues/68#issuecomment-769174804). How to handle addition detection is unsolved; the current proposal is to use the highest bit of the counter as in proposal 1. **Type:** Exact (for mutations), flaky (for additions) **Pros:** - low time overhead (set component counter on access, set system counter after execution) - robust to systems that don't run every frame - robust to systems that loop **Cons:** - moderately complex implementation - must be modified as systems are inserted dynamically - medium memory overhead (4 bytes per component + system) - unsolved addition detection ## Proposal 6: System-Data Change Detection For each system, track which system's changes it has seen. This approach is only worth fully designing and implementing if Proposal 5 fails in some way. **Type:** Exact **Pros:** - exact - conceptually simple **Cons:** - requires storing data on each system - implementation is complex - must be modified as systems are inserted dynamically ## Proposal 7: Total-Order Change Detection Discussed [here](https://github.com/bevyengine/bevy/issues/68#issuecomment-754326523). This proposal is somewhat complicated by the new scheduler, but I believe it should still be conceptually feasible. This approach is only worth fully designing and implementing if Proposal 5 fails in some way. **Type:** Exact **Pros:** - exact - efficient data storage relative to other exact proposals **Cons:** - requires access to the scheduler - complex implementation and difficulty grokking - must be modified as systems are inserted dynamically # Tests - We will need to verify properties 1, 2, 3, 7 and 8. Priority: 1 > 2 = 3 > 8 > 7 - Ideally we can use identical user-facing syntax for all proposals, allowing us to re-use the same syntax for each. - When writing tests, we need to carefully specify order using explicit dependencies. - These tests will need to be duplicated for both components and resources. - We need to be sure to handle cases where ambiguous system orders exist. `changing_system` is always the system that makes the changes, and `detecting_system` always detects the changes. The component / resource changed will be simple boolean wrapper structs. ## Basic Added / Mutated / Changed 2 x 3 design: - Resources vs. Components - Added vs. Changed vs. Mutated - `changing_system` runs before `detecting_system` - verify at the end of tick 2 ## At Least Once 2 x 3 design: - Resources vs. Components - Added vs. Changed vs. Mutated - `changing_system` runs after `detecting_system` - verify at the end of tick 2 ## At Most Once 2 x 3 design: - Resources vs. Components - Added vs. Changed vs. Mutated - `changing_system` runs once before `detecting_system` - increment a counter based on the number of changes detected - verify at the end of tick 2 ## Fast Detection 2 x 3 design: - Resources vs. Components - Added vs. Changed vs. Mutated - `changing_system` runs before `detecting_system` - verify at the end of tick 1 ## Ambiguous System Ordering Robustness 2 x 3 x 2 design: - Resources vs. Components - Added vs. Changed vs. Mutated - `changing_system` runs [before/after] `detecting_system` in tick 1 - `changing_system` runs [after/before] `detecting_system` in tick 2 ## System Pausing 2 x 3 design: - Resources vs. Components - Added vs. Changed vs. Mutated - `changing_system` runs in tick 1, then is disabled by run criteria - `detecting_system` is disabled by run criteria until it is run once during tick 3 - verify at the end of tick 3 ## Addition Causes Mutation 2 design: - Resources vs. Components - `adding_system_1` adds a component / resource - `adding system_2` adds the same component / resource - verify the `Mutated` flag at the end of the tick - verify the `Added` flag at the end of the tick First check tests for: https://github.com/bevyengine/bevy/issues/333 Second check tests for: https://github.com/bevyengine/bevy/issues/1443 ## Changes Made By Commands - `adding_system` runs in Update in tick 1, and sends a command to add a component - `detecting_system` runs in Update in tick 1 and 2, after `adding_system` - We can't detect the changes in tick 1, since they haven't been processed yet - If we were to track these changes as being emitted by `adding_system`, we can't detect the changes in tick 2 either, since `detecting_system` has already run once after `adding_system` :( # Benchmarks See: [general advice](https://github.com/bevyengine/bevy/blob/master/docs/profiling.md), [Criterion crate](https://github.com/bheisler/criterion.rs) There are several critical parameters to vary: 1. entity count (1 to 10^9) 2. fraction of entities that are changed (0% to 100%) 3. cost to perform work on changed entities, i.e. workload (1 ns to 1s) 1 and 2 should be varied between benchmark runs. 3 can be added on computationally. We want to measure: - memory cost - run time We should collect these measurements across several frames (100?) to reduce bootup effects and accurately measure the mean, variance and drift. Entity-component change detection is much more important to benchmark than resource change detection, due to the orders of magnitude higher number of pieces of data. No change detection at all should be included in benchmarks as a second control for cases where missing changes is unacceptable. ## Graphs 1. y: performance, x: log_10(entity count), color: proposal, facet: performance metric. Set cost to perform work to 0. 2. y: run time, x: cost to perform work, color: proposal, facet: fraction changed. Set number of entities to 10^6 3. y: memory, x: frames, color: proposal # Conclusions 1. Is the theoretical categorization of the proposals correct according to our tests? 2. How does the performance of the proposals compare without any load? 3. How does the performance of the proposals compare with realistic loads? 4. At what workload does more exact change tracking become worth the (presumably) higher overhead? 5. When does adding change-detection to save on work become worthwhile? 6. Is there enough divergence in performance between the best solutions in each class to ship more than one change-tracking solution? # Implementation Plan 1. Write a test suite. 2. Verify that tests fail for existing approach. 3. Write a benchmark suite. 4. Get performance numbers for existing approach. 5. Implement, test and benchmark various solutions using a Git branch per proposal. 6. Create a draft PR with all solutions and present results to team. 7. Select a solution and replace existing change detection. Co-authored-by: Brice DAVIER <bricedavier@gmail.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com> |
||
---|---|---|
.. | ||
2d | ||
3d | ||
android | ||
app | ||
asset | ||
audio | ||
diagnostics | ||
ecs | ||
game | ||
input | ||
ios | ||
reflection | ||
scene | ||
shader | ||
tools | ||
ui | ||
wasm | ||
window | ||
hello_world.rs | ||
README.md |
Examples
These examples demonstrate the main features of Bevy and how to use them.
To run an example, use the command cargo run --example <Example>
, and add the option --features x11
or --features wayland
to force the example to run on a specific window compositor, e.g.
cargo run --features wayland --example hello_world
⚠️ Note: for users of releases on crates.io!
There are often large differences and incompatible API changes between the latest crates.io release and the development version of Bevy in the git main branch!
If you are using a released version of bevy, you need to make sure you are viewing the correct version of the examples!
- Latest release: https://github.com/bevyengine/bevy/tree/latest/examples
- Specific version, such as
0.4
: https://github.com/bevyengine/bevy/tree/v0.4.0/examples
When you clone the repo locally to run the examples, use git checkout
to get the correct version:
# `latest` always points to the newest release
git checkout latest
# or use a specific version
git checkout v0.4.0
Table of Contents
The Bare Minimum
Hello, World!
Example | Main | Description |
---|---|---|
hello_world |
hello_world.rs |
Runs a minimal example that outputs "hello world" |
Cross-Platform Examples
2D Rendering
Example | Main | Description |
---|---|---|
contributors |
2d/contributors.rs |
Displays each contributor as a bouncy bevy-ball! |
sprite |
2d/sprite.rs |
Renders a sprite |
sprite_sheet |
2d/sprite_sheet.rs |
Renders an animated sprite |
text2d |
2d/text2d.rs |
Generates text in 2d |
sprite_flipping |
2d/sprite_flipping.rs |
Renders a sprite flipped along an axis |
texture_atlas |
2d/texture_atlas.rs |
Generates a texture atlas (sprite sheet) from individual sprites |
3D Rendering
Example | File | Description |
---|---|---|
3d_scene |
3d/3d_scene.rs |
Simple 3D scene with basic shapes and lighting |
load_gltf |
3d/load_gltf.rs |
Loads and renders a gltf file as a scene |
msaa |
3d/msaa.rs |
Configures MSAA (Multi-Sample Anti-Aliasing) for smoother edges |
orthographic |
3d/orthographic.rs |
Shows how to create a 3D orthographic view (for isometric-look games or CAD applications) |
parenting |
3d/parenting.rs |
Demonstrates parent->child relationships and relative transformations |
spawner |
3d/spawner.rs |
Renders a large number of cubes with changing position and material |
texture |
3d/texture.rs |
Shows configuration of texture materials |
update_gltf_scene |
3d/update_gltf_scene.rs |
Update a scene from a gltf file, either by spawning the scene as a child of another entity, or by accessing the entities of the scene |
wireframe |
3d/wireframe.rs |
Showcases wireframe rendering |
z_sort_debug |
3d/z_sort_debug.rs |
Visualizes camera Z-ordering |
Application
Example | File | Description |
---|---|---|
custom_loop |
app/custom_loop.rs |
Demonstrates how to create a custom runner (to update an app manually). |
drag_and_drop |
app/drag_and_drop.rs |
An example that shows how to handle drag and drop in an app. |
empty |
app/empty.rs |
An empty application (does nothing) |
empty_defaults |
app/empty_defaults.rs |
An empty application with default plugins |
headless |
app/headless.rs |
An application that runs without default plugins |
logs |
app/logs.rs |
Illustrate how to use generate log output |
plugin |
app/plugin.rs |
Demonstrates the creation and registration of a custom plugin |
plugin_group |
app/plugin_group.rs |
Demonstrates the creation and registration of a custom plugin group |
return_after_run |
app/return_after_run.rs |
Show how to return to main after the Bevy app has exited |
thread_pool_resources |
app/thread_pool_resources.rs |
Creates and customizes the internal thread pool |
Assets
Example | File | Description |
---|---|---|
asset_loading |
asset/asset_loading.rs |
Demonstrates various methods to load assets |
custom_asset |
asset/custom_asset.rs |
Implements a custom asset loader |
custom_asset_io |
asset/custom_asset_io.rs |
Implements a custom asset io loader |
hot_asset_reloading |
asset/hot_asset_reloading.rs |
Demonstrates automatic reloading of assets when modified on disk |
Audio
Example | File | Description |
---|---|---|
audio |
audio/audio.rs |
Shows how to load and play an audio file |
Diagnostics
Example | File | Description |
---|---|---|
log_diagnostics |
diagnostics/log_diagnostics.rs |
Add a plugin that logs diagnostics to the console |
custom_diagnostic |
diagnostics/custom_diagnostic.rs |
Shows how to create a custom diagnostic |
ECS (Entity Component System)
Example | File | Description |
---|---|---|
ecs_guide |
ecs/ecs_guide.rs |
Full guide to Bevy's ECS |
change_detection |
ecs/change_detection.rs |
Change detection on components |
event |
ecs/event.rs |
Illustrates event creation, activation, and reception |
fixed_timestep |
ecs/fixed_timestep.rs |
Shows how to create systems that run every fixed timestep, rather than every tick |
hierarchy |
ecs/hierarchy.rs |
Creates a hierarchy of parents and children entities |
parallel_query |
ecs/parallel_query.rs |
Illustrates parallel queries with ParallelIterator |
removal_detection |
ecs/removal_detection.rs |
Query for entities that had a specific component removed in a previous stage during the current frame. |
startup_system |
ecs/startup_system.rs |
Demonstrates a startup system (one that runs once when the app starts up) |
state |
ecs/state.rs |
Illustrates how to use States to control transitioning from a Menu state to an InGame state |
system_chaining |
ecs/system_chaining.rs |
Chain two systems together, specifying a return type in a system (such as Result ) |
system_param |
ecs/system_param.rs |
Illustrates creating custom system parameters with SystemParam |
timers |
ecs/timers.rs |
Illustrates ticking Timer resources inside systems and handling their state |
Games
Example | File | Description |
---|---|---|
alien_cake_addict |
game/alien_cake_addict.rs |
Eat the cakes. Eat them all. An example 3D game |
breakout |
game/breakout.rs |
An implementation of the classic game "Breakout" |
Input
Example | File | Description |
---|---|---|
char_input_events |
input/char_input_events.rs |
Prints out all chars as they are inputted. |
gamepad_input |
input/gamepad_input.rs |
Shows handling of gamepad input, connections, and disconnections |
gamepad_input_events |
input/gamepad_input_events.rs |
Iterates and prints gamepad input and connection events |
keyboard_input |
input/keyboard_input.rs |
Demonstrates handling a key press/release |
keyboard_input_events |
input/keyboard_input_events.rs |
Prints out all keyboard events |
keyboard_modifiers |
input/keyboard_modifiers.rs |
Demonstrates using key modifiers (ctrl, shift) |
mouse_input |
input/mouse_input.rs |
Demonstrates handling a mouse button press/release |
mouse_input_events |
input/mouse_input_events.rs |
Prints out all mouse events (buttons, movement, etc.) |
touch_input |
input/touch_input.rs |
Displays touch presses, releases, and cancels |
touch_input_events |
input/touch_input_events.rs |
Prints out all touch inputs |
Reflection
Example | File | Description |
---|---|---|
reflection |
reflection/reflection.rs |
Demonstrates how reflection in Bevy provides a way to dynamically interact with Rust types |
generic_reflection |
reflection/generic_reflection.rs |
Registers concrete instances of generic types that may be used with reflection |
reflection_types |
reflection/reflection_types.rs |
Illustrates the various reflection types available |
trait_reflection |
reflection/trait_reflection.rs |
Allows reflection with trait objects |
Scene
Example | File | Description |
---|---|---|
scene |
scene/scene.rs |
Demonstrates loading from and saving scenes to files |
Shaders
Example | File | Description |
---|---|---|
array_texture |
shader/array_texture.rs |
Illustrates how to create a texture for use with a texture2DArray shader uniform variable |
hot_shader_reloading |
shader/hot_shader_reloading.rs |
Illustrates how to load shaders such that they can be edited while the example is still running |
mesh_custom_attribute |
shader/mesh_custom_attribute.rs |
Illustrates how to add a custom attribute to a mesh and use it in a custom shader |
shader_custom_material |
shader/shader_custom_material.rs |
Illustrates creating a custom material and a shader that uses it |
shader_defs |
shader/shader_defs.rs |
Demonstrates creating a custom material that uses "shaders defs" (a tool to selectively toggle parts of a shader) |
Tools
Example | File | Description |
---|---|---|
bevymark |
tools/bevymark.rs |
A heavy workload to benchmark your system with Bevy |
UI (User Interface)
Example | File | Description |
---|---|---|
button |
ui/button.rs |
Illustrates creating and updating a button |
font_atlas_debug |
ui/font_atlas_debug.rs |
Illustrates how FontAtlases are populated (used to optimize text rendering internally) |
text |
ui/text.rs |
Illustrates creating and updating text |
text_debug |
ui/text_debug.rs |
An example for debugging text layout |
ui |
ui/ui.rs |
Illustrates various features of Bevy UI |
Window
Example | File | Description |
---|---|---|
clear_color |
window/clear_color.rs |
Creates a solid color window |
multiple_windows |
window/multiple_windows.rs |
Creates two windows and cameras viewing the same mesh |
scale_factor_override |
window/scale_factor_override.rs |
Illustrates how to customize the default window settings |
window_settings |
window/window_settings.rs |
Demonstrates customizing default window settings |
Platform-Specific Examples
Android
Setup
rustup target add aarch64-linux-android armv7-linux-androideabi
cargo install cargo-apk
The Android SDK must be installed, and the environment variable ANDROID_SDK_ROOT
set to the root Android sdk
folder.
When using NDK (Side by side)
, the environment variable ANDROID_NDK_ROOT
must also be set to one of the NDKs in sdk\ndk\[NDK number]
.
Build & Run
To run on a device setup for Android development, run:
cargo apk run --example android
⚠️ At this time Bevy does not work in Android Emulator.
When using Bevy as a library, the following fields must be added to Cargo.toml
:
[package.metadata.android]
build_targets = ["aarch64-linux-android", "armv7-linux-androideabi"]
target_sdk_version = 29
min_sdk_version = 16
Please reference cargo-apk
README for other Android Manifest fields.
Old phones
Bevy by default targets Android API level 29 in its examples which is the Play Store's minimum API to upload or update apps. Users of older phones may want to use an older API when testing.
To use a different API, the following fields must be updated in Cargo.toml:
[package.metadata.android]
target_sdk_version = >>API<<
min_sdk_version = >>API or less<<
Example | File | Description |
---|---|---|
android |
android/android.rs |
The 3d/3d_scene.rs example for Android |
iOS
Setup
rustup target add aarch64-apple-ios x86_64-apple-ios
cargo install cargo-lipo
Build & Run
Using bash:
cd examples/ios
make run
In an ideal world, this will boot up, install and run the app for the first
iOS simulator in your xcrun simctl devices list
. If this fails, you can
specify the simulator device UUID via:
DEVICE_ID=${YOUR_DEVICE_ID} make run
If you'd like to see xcode do stuff, you can run
open bevy_ios_example.xcodeproj/
which will open xcode. You then must push the zoom zoom play button and wait for the magic.
The Xcode build GUI will by default build the rust library for both
x86_64-apple-ios
, and aarch64-apple-ios
which may take a while. If you'd
like speed this up, you update the IOS_TARGETS
User-Defined environment
variable in the "cargo_ios
target" to be either x86_64-apple-ios
or
aarch64-apple-ios
depending on your goal.
Note: if you update this variable in Xcode, it will also change the default
used for the Makefile
.
Example | File | Description |
---|---|---|
ios |
ios/src/lib.rs |
The 3d/3d_scene.rs example for iOS |
WASM
Setup
rustup target add wasm32-unknown-unknown
cargo install wasm-bindgen-cli
Build & Run
Following is an example for headless_wasm
. For other examples in wasm/ directory,
change the headless_wasm
in the following commands and edit examples/wasm/index.html
to point to the correct .js
file.
cargo build --example headless_wasm --target wasm32-unknown-unknown --no-default-features
wasm-bindgen --out-dir examples/wasm/target --target web target/wasm32-unknown-unknown/debug/examples/headless_wasm.wasm
Then serve examples/wasm
dir to browser. i.e.
basic-http-server examples/wasm
Example | File | Description |
---|---|---|
hello_wasm |
wasm/hello_wasm.rs |
Runs a minimal example that logs "hello world" to the browser's console |
assets_wasm |
wasm/assets_wasm.rs |
Demonstrates how to load assets from wasm |
headless_wasm |
wasm/headless_wasm.rs |
Sets up a schedule runner and continually logs a counter to the browser's console |
winit_wasm |
wasm/winit_wasm.rs |
Logs user input to the browser's console. Requires the bevy_winit features |