bevy/examples
Alice Cecile 6121e5f933 Reliable change detection (#1471)
# 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>
2021-03-19 17:53:26 +00:00
..
2d color spaces and representation (#1572) 2021-03-17 23:59:51 +00:00
3d Replace default method calls from Glam types with explicit const (#1645) 2021-03-13 18:23:39 +00:00
android Replace default method calls from Glam types with explicit const (#1645) 2021-03-13 18:23:39 +00:00
app format comments (#1612) 2021-03-11 00:27:30 +00:00
asset Replace default method calls from Glam types with explicit const (#1645) 2021-03-13 18:23:39 +00:00
audio Adopt a Fetch pattern for SystemParams (#1074) 2020-12-15 21:57:16 -08:00
diagnostics format comments (#1612) 2021-03-11 00:27:30 +00:00
ecs Reliable change detection (#1471) 2021-03-19 17:53:26 +00:00
game Redo State architecture (#1424) 2021-03-15 22:12:04 +00:00
input Add keyboard modifier example (#1656) (#1657) 2021-03-14 21:00:36 +00:00
ios Replace default method calls from Glam types with explicit const (#1645) 2021-03-13 18:23:39 +00:00
reflection format comments (#1612) 2021-03-11 00:27:30 +00:00
scene Replace default method calls from Glam types with explicit const (#1645) 2021-03-13 18:23:39 +00:00
shader Replace default method calls from Glam types with explicit const (#1645) 2021-03-13 18:23:39 +00:00
tools color spaces and representation (#1572) 2021-03-17 23:59:51 +00:00
ui Reliable change detection (#1471) 2021-03-19 17:53:26 +00:00
wasm Bevy ECS V2 (#1525) 2021-03-05 07:54:35 +00:00
window Redo State architecture (#1424) 2021-03-15 22:12:04 +00:00
hello_world.rs Adopt a Fetch pattern for SystemParams (#1074) 2020-12-15 21:57:16 -08:00
README.md Add keyboard modifier example (#1656) (#1657) 2021-03-14 21:00:36 +00:00

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!

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