e369a8ad51
This PR makes a number of changes to how meshes and vertex attributes are handled, which the goal of enabling easy and flexible custom vertex attributes: * Reworks the `Mesh` type to use the newly added `VertexAttribute` internally * `VertexAttribute` defines the name, a unique `VertexAttributeId`, and a `VertexFormat` * `VertexAttributeId` is used to produce consistent sort orders for vertex buffer generation, replacing the more expensive and often surprising "name based sorting" * Meshes can be used to generate a `MeshVertexBufferLayout`, which defines the layout of the gpu buffer produced by the mesh. `MeshVertexBufferLayouts` can then be used to generate actual `VertexBufferLayouts` according to the requirements of a specific pipeline. This decoupling of "mesh layout" vs "pipeline vertex buffer layout" is what enables custom attributes. We don't need to standardize _mesh layouts_ or contort meshes to meet the needs of a specific pipeline. As long as the mesh has what the pipeline needs, it will work transparently. * Mesh-based pipelines now specialize on `&MeshVertexBufferLayout` via the new `SpecializedMeshPipeline` trait (which behaves like `SpecializedPipeline`, but adds `&MeshVertexBufferLayout`). The integrity of the pipeline cache is maintained because the `MeshVertexBufferLayout` is treated as part of the key (which is fully abstracted from implementers of the trait ... no need to add any additional info to the specialization key). * Hashing `MeshVertexBufferLayout` is too expensive to do for every entity, every frame. To make this scalable, I added a generalized "pre-hashing" solution to `bevy_utils`: `Hashed<T>` keys and `PreHashMap<K, V>` (which uses `Hashed<T>` internally) . Why didn't I just do the quick and dirty in-place "pre-compute hash and use that u64 as a key in a hashmap" that we've done in the past? Because its wrong! Hashes by themselves aren't enough because two different values can produce the same hash. Re-hashing a hash is even worse! I decided to build a generalized solution because this pattern has come up in the past and we've chosen to do the wrong thing. Now we can do the right thing! This did unfortunately require pulling in `hashbrown` and using that in `bevy_utils`, because avoiding re-hashes requires the `raw_entry_mut` api, which isn't stabilized yet (and may never be ... `entry_ref` has favor now, but also isn't available yet). If std's HashMap ever provides the tools we need, we can move back to that. Note that adding `hashbrown` doesn't increase our dependency count because it was already in our tree. I will probably break these changes out into their own PR. * Specializing on `MeshVertexBufferLayout` has one non-obvious behavior: it can produce identical pipelines for two different MeshVertexBufferLayouts. To optimize the number of active pipelines / reduce re-binds while drawing, I de-duplicate pipelines post-specialization using the final `VertexBufferLayout` as the key. For example, consider a pipeline that needs the layout `(position, normal)` and is specialized using two meshes: `(position, normal, uv)` and `(position, normal, other_vec2)`. If both of these meshes result in `(position, normal)` specializations, we can use the same pipeline! Now we do. Cool! To briefly illustrate, this is what the relevant section of `MeshPipeline`'s specialization code looks like now: ```rust impl SpecializedMeshPipeline for MeshPipeline { type Key = MeshPipelineKey; fn specialize( &self, key: Self::Key, layout: &MeshVertexBufferLayout, ) -> RenderPipelineDescriptor { let mut vertex_attributes = vec![ Mesh::ATTRIBUTE_POSITION.at_shader_location(0), Mesh::ATTRIBUTE_NORMAL.at_shader_location(1), Mesh::ATTRIBUTE_UV_0.at_shader_location(2), ]; let mut shader_defs = Vec::new(); if layout.contains(Mesh::ATTRIBUTE_TANGENT) { shader_defs.push(String::from("VERTEX_TANGENTS")); vertex_attributes.push(Mesh::ATTRIBUTE_TANGENT.at_shader_location(3)); } let vertex_buffer_layout = layout .get_layout(&vertex_attributes) .expect("Mesh is missing a vertex attribute"); ``` Notice that this is _much_ simpler than it was before. And now any mesh with any layout can be used with this pipeline, provided it has vertex postions, normals, and uvs. We even got to remove `HAS_TANGENTS` from MeshPipelineKey and `has_tangents` from `GpuMesh`, because that information is redundant with `MeshVertexBufferLayout`. This is still a draft because I still need to: * Add more docs * Experiment with adding error handling to mesh pipeline specialization (which would print errors at runtime when a mesh is missing a vertex attribute required by a pipeline). If it doesn't tank perf, we'll keep it. * Consider breaking out the PreHash / hashbrown changes into a separate PR. * Add an example illustrating this change * Verify that the "mesh-specialized pipeline de-duplication code" works properly Please dont yell at me for not doing these things yet :) Just trying to get this in peoples' hands asap. Alternative to #3120 Fixes #3030 Co-authored-by: Carter Anderson <mcanders1@gmail.com> |
||
---|---|---|
.. | ||
2d | ||
3d | ||
android | ||
app | ||
asset | ||
async_tasks | ||
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 | File | Description |
---|---|---|
hello_world |
hello_world.rs |
Runs a minimal example that outputs "hello world" |
Cross-Platform Examples
2D Rendering
Example | File | Description |
---|---|---|
contributors |
2d/contributors.rs |
Displays each contributor as a bouncy bevy-ball! |
many_sprites |
2d/many_sprites.rs |
Displays many sprites in a grid arragement! Used for performance testing. |
move_sprite |
2d/move_sprite.rs |
Changes the transform of a sprite. |
mesh2d |
2d/mesh2d.rs |
Renders a 2d mesh |
mesh2d_manual |
2d/mesh2d_manual.rs |
Renders a custom mesh "manually" with "mid-level" renderer apis. |
rect |
2d/rect.rs |
Renders a rectangle |
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 |
rotation |
2d/rotation.rs |
Demonstrates rotating entities in 2D with quaternions |
3D Rendering
Example | File | Description |
---|---|---|
3d_scene |
3d/3d_scene.rs |
Simple 3D scene with basic shapes and lighting |
lighting |
3d/lighting.rs |
Illustrates various lighting options in a simple scene |
load_gltf |
3d/load_gltf.rs |
Loads and renders a gltf file as a scene |
many_cubes |
3d/many_cubes.rs |
Simple benchmark to test per-entity draw overhead |
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 |
pbr |
3d/pbr.rs |
Demonstrates use of Physically Based Rendering (PBR) properties |
shadow_caster_receiver |
3d/shadow_caster_receiver.rs |
Demonstrates how to prevent meshes from casting/receiving shadows in a 3d scene |
shadow_biases |
3d/shadow_biases.rs |
Demonstrates how shadow biases affect shadows in a 3d scene |
spherical_area_lights |
3d/spherical_area_lights.rs |
Demonstrates how point light radius values affect light behavior. |
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 |
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 |
headless_defaults |
app/headless_defaults.rs |
An application that runs with default plugins, but without an actual renderer |
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 |
without_winit |
app/without_winit.rs |
Create an application without winit (runs single time, no event loop) |
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 |
Async Tasks
Example | File | Description |
---|---|---|
async_compute |
async_tasks/async_compute.rs |
How to use AsyncComputeTaskPool to complete longer running tasks |
external_source_external_thread |
async_tasks/external_source_external_thread.rs |
How to use an external thread to run an infinite task and communicate with a channel |
Audio
Example | File | Description |
---|---|---|
audio |
audio/audio.rs |
Shows how to load and play an audio file |
Diagnostics
Example | File | Description |
---|---|---|
custom_diagnostic |
diagnostics/custom_diagnostic.rs |
Shows how to create a custom diagnostic |
log_diagnostics |
diagnostics/log_diagnostics.rs |
Add a plugin that logs diagnostics, like frames per second (FPS), to the console |
ECS (Entity Component System)
Example | File | Description |
---|---|---|
ecs_guide |
ecs/ecs_guide.rs |
Full guide to Bevy's ECS |
component_change_detection |
ecs/component_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 |
generic_system |
ecs/generic_system.rs |
Shows how to create systems that can be reused with different types |
hierarchy |
ecs/hierarchy.rs |
Creates a hierarchy of parents and children entities |
iter_combinations |
ecs/iter_combinations.rs |
Shows how to iterate over combinations of query results. |
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 |
system_sets |
ecs/system_sets.rs |
Shows SystemSet use along with run criterion |
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" |
game_menu |
game/game_menu.rs |
A simple game menu |
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 |
---|---|---|
custom_vertex_attribute |
shader/custom_vertex_attribute.rs |
Illustrates creating a custom shader material that reads a mesh's custom vertex attribute. |
shader_material |
shader/shader_material.rs |
Illustrates creating a custom material and a shader that uses it |
shader_material_glsl |
shader/shader_material_glsl.rs |
A custom shader using the GLSL shading language. |
shader_instancing |
shader/shader_instancing.rs |
A custom shader showing off rendering a mesh multiple times in one draw call. |
animate_shader |
shader/animate_shader.rs |
Shows how to pass changing data like the time since startup into a shader. |
compute_shader_game_of_life |
shader/compute_shader_game_of_life.rs |
A compute shader simulating Conway's Game of Life |
shader_defs |
shader/shader_defs.rs |
Demonstrates creating a custom material that uses "shaders defs" (a tool to selectively toggle parts of a shader) |
Tests
Example | File | Description |
---|---|---|
how_to_test_systems |
../tests/how_to_test_systems.rs |
How to test systems with commands, queries or resources |
Tools
Example | File | Description |
---|---|---|
bevymark |
tools/bevymark.rs |
A heavy sprite rendering 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 |
Demonstrates creating multiple windows, and rendering to them |
scale_factor_override |
window/scale_factor_override.rs |
Illustrates how to customize the default window settings |
transparent_window |
window/transparent_window.rs |
Illustrates making the window transparent and hiding the window decoration |
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
You need to install the correct rust targets:
aarch64-apple-ios
: iOS devicesx86_64-apple-ios
: iOS simulator on x86 processorsaarch64-apple-ios-sim
: iOS simulator on Apple processors
rustup target add aarch64-apple-ios x86_64-apple-ios aarch64-apple-ios-sim
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.
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 lighting
. For other examples, change the lighting
in the
following commands.
cargo build --release --example lighting --target wasm32-unknown-unknown
wasm-bindgen --out-name wasm_example --out-dir examples/wasm/target --target web target/wasm32-unknown-unknown/release/examples/lighting.wasm
The first command will build the example for the wasm target, creating a binary. Then, wasm-bindgen-cli is used to create javascript bindings to this wasm file, which can be loaded using this example HTML file.
Then serve examples/wasm
directory to browser. i.e.
# cargo install basic-http-server
basic-http-server examples/wasm
# with python
python3 -m http.server --directory examples/wasm
# with ruby
ruby -run -ehttpd examples/wasm
Loading Assets
To load assets, they need to be available in the folder examples/wasm/assets. Cloning this repository will set it up as a symlink on Linux and macOS, but you will need to manually move the assets on Windows.