2019-11-13 03:36:02 +00:00
|
|
|
[package]
|
|
|
|
name = "bevy"
|
2022-03-19 03:54:15 +00:00
|
|
|
version = "0.7.0-dev"
|
2021-10-27 00:12:14 +00:00
|
|
|
edition = "2021"
|
2020-11-10 03:26:08 +00:00
|
|
|
categories = ["game-engines", "graphics", "gui", "rendering"]
|
2020-08-10 00:24:27 +00:00
|
|
|
description = "A refreshingly simple data-driven game engine and app framework"
|
2020-11-10 03:26:08 +00:00
|
|
|
exclude = ["assets/**/*", "tools/**/*", ".github/**/*", "crates/**/*"]
|
2020-08-10 00:24:27 +00:00
|
|
|
homepage = "https://bevyengine.org"
|
|
|
|
keywords = ["game", "engine", "gamedev", "graphics", "bevy"]
|
2021-07-23 21:11:51 +00:00
|
|
|
license = "MIT OR Apache-2.0"
|
2020-11-10 18:58:51 +00:00
|
|
|
readme = "README.md"
|
2020-11-10 03:26:08 +00:00
|
|
|
repository = "https://github.com/bevyengine/bevy"
|
|
|
|
|
|
|
|
[workspace]
|
2021-11-13 22:43:19 +00:00
|
|
|
exclude = ["benches", "crates/bevy_ecs_compile_fail_tests"]
|
2021-12-14 03:58:23 +00:00
|
|
|
members = ["crates/*", "examples/ios", "tools/ci", "errors"]
|
2019-11-13 03:36:02 +00:00
|
|
|
|
2020-03-11 05:20:49 +00:00
|
|
|
[features]
|
2020-09-02 00:02:11 +00:00
|
|
|
default = [
|
2022-04-02 22:36:02 +00:00
|
|
|
"animation",
|
2020-11-10 03:26:08 +00:00
|
|
|
"bevy_audio",
|
|
|
|
"bevy_gilrs",
|
|
|
|
"bevy_winit",
|
|
|
|
"render",
|
|
|
|
"png",
|
|
|
|
"hdr",
|
2021-12-23 19:19:15 +00:00
|
|
|
"vorbis",
|
2020-11-10 03:26:08 +00:00
|
|
|
"x11",
|
2021-12-18 19:38:05 +00:00
|
|
|
"filesystem_watcher",
|
2020-09-02 00:02:11 +00:00
|
|
|
]
|
2020-11-03 00:30:30 +00:00
|
|
|
|
2020-11-10 03:26:08 +00:00
|
|
|
# Force dynamic linking, which improves iterative compile times
|
|
|
|
dynamic = ["bevy_dylib"]
|
2020-10-01 20:04:06 +00:00
|
|
|
|
2021-12-14 03:58:23 +00:00
|
|
|
# Rendering support
|
2021-08-01 19:14:47 +00:00
|
|
|
render = [
|
2021-12-14 03:58:23 +00:00
|
|
|
"bevy_internal/bevy_core_pipeline",
|
2021-08-01 19:14:47 +00:00
|
|
|
"bevy_internal/bevy_pbr",
|
2021-12-14 03:58:23 +00:00
|
|
|
"bevy_internal/bevy_gltf",
|
2021-08-01 19:14:47 +00:00
|
|
|
"bevy_internal/bevy_render",
|
|
|
|
"bevy_internal/bevy_sprite",
|
|
|
|
"bevy_internal/bevy_text",
|
|
|
|
"bevy_internal/bevy_ui",
|
|
|
|
]
|
2020-11-10 03:26:08 +00:00
|
|
|
|
|
|
|
# Optional bevy crates
|
2022-04-02 22:36:02 +00:00
|
|
|
bevy_animation = ["bevy_internal/bevy_animation"]
|
2020-11-10 03:26:08 +00:00
|
|
|
bevy_audio = ["bevy_internal/bevy_audio"]
|
2021-12-14 03:58:23 +00:00
|
|
|
bevy_core_pipeline = ["bevy_internal/bevy_core_pipeline"]
|
2020-11-10 03:26:08 +00:00
|
|
|
bevy_dynamic_plugin = ["bevy_internal/bevy_dynamic_plugin"]
|
|
|
|
bevy_gilrs = ["bevy_internal/bevy_gilrs"]
|
|
|
|
bevy_gltf = ["bevy_internal/bevy_gltf"]
|
2022-01-04 19:49:38 +00:00
|
|
|
bevy_pbr = ["bevy_internal/bevy_pbr"]
|
|
|
|
bevy_render = ["bevy_internal/bevy_render"]
|
|
|
|
bevy_sprite = ["bevy_internal/bevy_sprite"]
|
|
|
|
bevy_text = ["bevy_internal/bevy_text"]
|
|
|
|
bevy_ui = ["bevy_internal/bevy_ui"]
|
2020-11-10 03:26:08 +00:00
|
|
|
bevy_winit = ["bevy_internal/bevy_winit"]
|
|
|
|
|
2022-01-04 19:49:38 +00:00
|
|
|
# Tracing features
|
2021-12-18 00:09:22 +00:00
|
|
|
trace_chrome = ["trace", "bevy_internal/trace_chrome"]
|
|
|
|
trace_tracy = ["trace", "bevy_internal/trace_tracy"]
|
2020-11-11 02:49:49 +00:00
|
|
|
trace = ["bevy_internal/trace"]
|
2020-11-10 03:26:08 +00:00
|
|
|
wgpu_trace = ["bevy_internal/wgpu_trace"]
|
|
|
|
|
2020-08-11 06:30:42 +00:00
|
|
|
# Image format support for texture loading (PNG and HDR are enabled by default)
|
2020-11-10 03:26:08 +00:00
|
|
|
hdr = ["bevy_internal/hdr"]
|
|
|
|
png = ["bevy_internal/png"]
|
2020-12-10 02:34:27 +00:00
|
|
|
tga = ["bevy_internal/tga"]
|
|
|
|
jpeg = ["bevy_internal/jpeg"]
|
2020-12-23 22:53:02 +00:00
|
|
|
bmp = ["bevy_internal/bmp"]
|
2022-03-15 22:26:46 +00:00
|
|
|
basis-universal = ["bevy_internal/basis-universal"]
|
|
|
|
dds = ["bevy_internal/dds"]
|
|
|
|
ktx2 = ["bevy_internal/ktx2"]
|
|
|
|
# For ktx2 supercompression
|
|
|
|
zlib = ["bevy_internal/zlib"]
|
|
|
|
zstd = ["bevy_internal/zstd"]
|
2020-08-11 06:30:42 +00:00
|
|
|
|
2022-03-08 02:11:59 +00:00
|
|
|
# Audio format support (vorbis is enabled by default)
|
2020-11-10 03:26:08 +00:00
|
|
|
flac = ["bevy_internal/flac"]
|
|
|
|
mp3 = ["bevy_internal/mp3"]
|
|
|
|
vorbis = ["bevy_internal/vorbis"]
|
|
|
|
wav = ["bevy_internal/wav"]
|
2020-08-11 06:30:42 +00:00
|
|
|
|
2021-11-13 21:15:22 +00:00
|
|
|
# Enable watching file system for asset hot reload
|
|
|
|
filesystem_watcher = ["bevy_internal/filesystem_watcher"]
|
|
|
|
|
2020-11-10 03:26:08 +00:00
|
|
|
serialize = ["bevy_internal/serialize"]
|
2020-08-22 01:13:50 +00:00
|
|
|
|
2020-08-25 00:06:08 +00:00
|
|
|
# Display server protocol support (X11 is enabled by default)
|
2020-11-10 03:26:08 +00:00
|
|
|
wayland = ["bevy_internal/wayland"]
|
|
|
|
x11 = ["bevy_internal/x11"]
|
2020-05-06 01:44:32 +00:00
|
|
|
|
2022-01-04 19:49:38 +00:00
|
|
|
# Enable rendering of font glyphs using subpixel accuracy
|
2021-01-03 20:39:11 +00:00
|
|
|
subpixel_glyph_atlas = ["bevy_internal/subpixel_glyph_atlas"]
|
|
|
|
|
2022-01-04 19:49:38 +00:00
|
|
|
# Enable systems that allow for automated testing on CI
|
2021-04-14 21:40:36 +00:00
|
|
|
bevy_ci_testing = ["bevy_internal/bevy_ci_testing"]
|
|
|
|
|
2022-02-18 22:56:57 +00:00
|
|
|
# Enable the "debug asset server" for hot reloading internal assets
|
|
|
|
debug_asset_server = ["bevy_internal/debug_asset_server"]
|
|
|
|
|
2022-04-02 22:36:02 +00:00
|
|
|
# Enable animation support, and glTF animation loading
|
|
|
|
animation = ["bevy_internal/animation"]
|
|
|
|
|
2019-11-13 03:36:02 +00:00
|
|
|
[dependencies]
|
2022-03-19 03:54:15 +00:00
|
|
|
bevy_dylib = { path = "crates/bevy_dylib", version = "0.7.0-dev", default-features = false, optional = true }
|
|
|
|
bevy_internal = { path = "crates/bevy_internal", version = "0.7.0-dev", default-features = false }
|
2020-04-06 03:19:02 +00:00
|
|
|
|
2021-12-22 20:59:48 +00:00
|
|
|
[target.'cfg(target_arch = "wasm32")'.dependencies]
|
2022-03-19 03:54:15 +00:00
|
|
|
bevy_internal = { path = "crates/bevy_internal", version = "0.7.0-dev", default-features = false, features = [
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
"webgl",
|
|
|
|
] }
|
2021-12-22 20:59:48 +00:00
|
|
|
|
2020-04-06 03:19:02 +00:00
|
|
|
[dev-dependencies]
|
2021-07-15 21:25:49 +00:00
|
|
|
anyhow = "1.0.4"
|
2021-01-17 21:43:03 +00:00
|
|
|
rand = "0.8.0"
|
2021-12-09 20:14:00 +00:00
|
|
|
ron = "0.7.0"
|
2021-08-01 19:14:47 +00:00
|
|
|
serde = { version = "1", features = ["derive"] }
|
2022-01-05 19:43:11 +00:00
|
|
|
bytemuck = "1.7"
|
2021-05-23 20:13:55 +00:00
|
|
|
# Needed to poll Task examples
|
|
|
|
futures-lite = "1.11.3"
|
2022-02-05 01:52:47 +00:00
|
|
|
crossbeam-channel = "0.5.0"
|
2019-12-24 00:13:05 +00:00
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "hello_world"
|
|
|
|
path = "examples/hello_world.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# 2D Rendering
|
2022-02-02 02:44:51 +00:00
|
|
|
[[example]]
|
|
|
|
name = "move_sprite"
|
|
|
|
path = "examples/2d/move_sprite.rs"
|
|
|
|
|
2022-01-25 22:10:11 +00:00
|
|
|
[[example]]
|
2022-02-25 15:54:03 +00:00
|
|
|
name = "rotation"
|
2022-01-25 22:10:11 +00:00
|
|
|
path = "examples/2d/rotation.rs"
|
|
|
|
|
Add 2d meshes and materials (#3460)
# Objective
The current 2d rendering is specialized to render sprites, we need a generic way to render 2d items, using meshes and materials like we have for 3d.
## Solution
I cloned a good part of `bevy_pbr` into `bevy_sprite/src/mesh2d`, removed lighting and pbr itself, adapted it to 2d rendering, added a `ColorMaterial`, and modified the sprite rendering to break batches around 2d meshes.
~~The PR is a bit crude; I tried to change as little as I could in both the parts copied from 3d and the current sprite rendering to make reviewing easier. In the future, I expect we could make the sprite rendering a normal 2d material, cleanly integrated with the rest.~~ _edit: see <https://github.com/bevyengine/bevy/pull/3460#issuecomment-1003605194>_
## Remaining work
- ~~don't require mesh normals~~ _out of scope_
- ~~add an example~~ _done_
- support 2d meshes & materials in the UI?
- bikeshed names (I didn't think hard about naming, please check if it's fine)
## Remaining questions
- ~~should we add a depth buffer to 2d now that there are 2d meshes?~~ _let's revisit that when we have an opaque render phase_
- ~~should we add MSAA support to the sprites, or remove it from the 2d meshes?~~ _I added MSAA to sprites since it's really needed for 2d meshes_
- ~~how to customize vertex attributes?~~ _#3120_
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2022-01-08 01:29:08 +00:00
|
|
|
[[example]]
|
|
|
|
name = "mesh2d"
|
|
|
|
path = "examples/2d/mesh2d.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "mesh2d_manual"
|
|
|
|
path = "examples/2d/mesh2d_manual.rs"
|
|
|
|
|
Add an example to draw a rectangle (#2957)
# Objective
Every time I come back to Bevy I face the same issue: how do I draw a rectangle again? How did that work? So I go to https://github.com/bevyengine/bevy/tree/main/examples in the hope of finding literally the simplest possible example that draws something on the screen without any dependency such as an image. I don't want to have to add some image first, I just quickly want to get something on the screen with `main.rs` alone so that I can continue building on from that point on. Such an example is particularly helpful for a quick start for smaller projects that don't even need any assets such as images (this is my case currently).
Currently every single example of https://github.com/bevyengine/bevy/tree/main/examples#2d-rendering (which is the first section after hello world that beginners will look for for very minimalistic and quick examples) depends on at least an asset or is too complex. This PR solves this.
It also serves as a great comparison for a beginner to realize what Bevy is really like and how different it is from what they may expect Bevy to be. For example for someone coming from [LÖVE](https://love2d.org/), they will have something like this in their head when they think of drawing a rectangle:
```lua
function love.draw()
love.graphics.setColor(0.25, 0.25, 0.75);
love.graphics.rectangle("fill", 0, 0, 50, 50);
end
```
This, of course, differs quite a lot from what you do in Bevy. I imagine there will be people that just want to see something as simple as this in comparison to have a better understanding for the amount of differences.
## Solution
Add a dead simple example drawing a blue 50x50 rectangle in the center with no more and no less than needed.
2021-12-18 00:52:37 +00:00
|
|
|
[[example]]
|
|
|
|
name = "rect"
|
|
|
|
path = "examples/2d/rect.rs"
|
|
|
|
|
2020-05-04 08:22:25 +00:00
|
|
|
[[example]]
|
|
|
|
name = "sprite"
|
|
|
|
path = "examples/2d/sprite.rs"
|
|
|
|
|
Add Sprite Flipping (#1407)
OK, here's my attempt at sprite flipping. There are a couple of points that I need review/help on, but I think the UX is about ideal:
```rust
.spawn(SpriteBundle {
material: materials.add(texture_handle.into()),
sprite: Sprite {
// Flip the sprite along the x axis
flip: SpriteFlip { x: true, y: false },
..Default::default()
},
..Default::default()
});
```
Now for the issues. The big issue is that for some reason, when flipping the UVs on the sprite, there is a light "bleeding" or whatever you call it where the UV tries to sample past the texture boundry and ends up clipping. This is only noticed when resizing the window, though. You can see a screenshot below.
![image](https://user-images.githubusercontent.com/25393315/107098172-397aaa00-67d4-11eb-8e02-c90c820cd70e.png)
I am quite baffled why the texture sampling is overrunning like it is and could use some guidance if anybody knows what might be wrong.
The other issue, which I just worked around, is that I had to remove the `#[render_resources(from_self)]` annotation from the Spritesheet because the `SpriteFlip` render resource wasn't being picked up properly in the shader when using it. I'm not sure what the cause of that was, but by removing the annotation and re-organizing the shader inputs accordingly the problem was fixed.
I'm not sure if this is the most efficient way to do this or if there is a better way, but I wanted to try it out if only for the learning experience. Let me know what you think!
2021-03-03 19:26:45 +00:00
|
|
|
[[example]]
|
|
|
|
name = "sprite_flipping"
|
|
|
|
path = "examples/2d/sprite_flipping.rs"
|
|
|
|
|
2020-06-02 02:23:11 +00:00
|
|
|
[[example]]
|
|
|
|
name = "sprite_sheet"
|
|
|
|
path = "examples/2d/sprite_sheet.rs"
|
|
|
|
|
2020-12-27 19:19:03 +00:00
|
|
|
[[example]]
|
|
|
|
name = "text2d"
|
|
|
|
path = "examples/2d/text2d.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "texture_atlas"
|
|
|
|
path = "examples/2d/texture_atlas.rs"
|
|
|
|
|
|
|
|
# 3D Rendering
|
2021-01-01 20:58:49 +00:00
|
|
|
[[example]]
|
|
|
|
name = "3d_scene"
|
|
|
|
path = "examples/3d/3d_scene.rs"
|
|
|
|
|
2021-06-02 02:59:17 +00:00
|
|
|
[[example]]
|
2021-12-14 03:58:23 +00:00
|
|
|
name = "lighting"
|
|
|
|
path = "examples/3d/lighting.rs"
|
2021-07-08 02:49:33 +00:00
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
2020-10-18 20:48:15 +00:00
|
|
|
name = "load_gltf"
|
|
|
|
path = "examples/3d/load_gltf.rs"
|
2020-05-01 20:12:47 +00:00
|
|
|
|
2020-07-30 01:15:15 +00:00
|
|
|
[[example]]
|
|
|
|
name = "msaa"
|
|
|
|
path = "examples/3d/msaa.rs"
|
|
|
|
|
2021-02-01 00:22:06 +00:00
|
|
|
[[example]]
|
|
|
|
name = "orthographic"
|
|
|
|
path = "examples/3d/orthographic.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "parenting"
|
|
|
|
path = "examples/3d/parenting.rs"
|
|
|
|
|
2021-03-20 03:22:33 +00:00
|
|
|
[[example]]
|
|
|
|
name = "pbr"
|
|
|
|
path = "examples/3d/pbr.rs"
|
|
|
|
|
2021-06-27 23:10:23 +00:00
|
|
|
[[example]]
|
2021-12-14 03:58:23 +00:00
|
|
|
name = "shadow_biases"
|
|
|
|
path = "examples/3d/shadow_biases.rs"
|
2021-07-19 19:20:59 +00:00
|
|
|
|
2021-08-25 19:44:20 +00:00
|
|
|
[[example]]
|
2021-12-14 03:58:23 +00:00
|
|
|
name = "shadow_caster_receiver"
|
|
|
|
path = "examples/3d/shadow_caster_receiver.rs"
|
2020-05-01 20:12:47 +00:00
|
|
|
|
2021-12-30 21:07:26 +00:00
|
|
|
[[example]]
|
|
|
|
name = "spherical_area_lights"
|
|
|
|
path = "examples/3d/spherical_area_lights.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "texture"
|
|
|
|
path = "examples/3d/texture.rs"
|
|
|
|
|
2022-02-24 00:40:24 +00:00
|
|
|
[[example]]
|
|
|
|
name = "render_to_texture"
|
|
|
|
path = "examples/3d/render_to_texture.rs"
|
|
|
|
|
2022-04-12 19:27:30 +00:00
|
|
|
[[example]]
|
|
|
|
name = "two_passes"
|
|
|
|
path = "examples/3d/two_passes.rs"
|
|
|
|
|
2021-01-01 20:58:49 +00:00
|
|
|
[[example]]
|
|
|
|
name = "update_gltf_scene"
|
|
|
|
path = "examples/3d/update_gltf_scene.rs"
|
|
|
|
|
2021-03-04 01:23:24 +00:00
|
|
|
[[example]]
|
|
|
|
name = "wireframe"
|
|
|
|
path = "examples/3d/wireframe.rs"
|
|
|
|
|
2022-03-29 18:31:13 +00:00
|
|
|
# Animation
|
2022-04-02 22:36:02 +00:00
|
|
|
[[example]]
|
|
|
|
name = "animated_fox"
|
|
|
|
path = "examples/animation/animated_fox.rs"
|
|
|
|
|
2022-04-07 23:53:43 +00:00
|
|
|
[[example]]
|
|
|
|
name = "animated_transform"
|
|
|
|
path = "examples/animation/animated_transform.rs"
|
|
|
|
|
2022-03-29 18:31:13 +00:00
|
|
|
[[example]]
|
|
|
|
name = "custom_skinned_mesh"
|
|
|
|
path = "examples/animation/custom_skinned_mesh.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "gltf_skinned_mesh"
|
|
|
|
path = "examples/animation/gltf_skinned_mesh.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Application
|
2020-11-09 21:04:27 +00:00
|
|
|
[[example]]
|
|
|
|
name = "custom_loop"
|
|
|
|
path = "examples/app/custom_loop.rs"
|
|
|
|
|
2021-01-01 21:31:22 +00:00
|
|
|
[[example]]
|
|
|
|
name = "drag_and_drop"
|
|
|
|
path = "examples/app/drag_and_drop.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "empty"
|
|
|
|
path = "examples/app/empty.rs"
|
|
|
|
|
2020-11-13 01:23:57 +00:00
|
|
|
[[example]]
|
2021-02-22 04:50:05 +00:00
|
|
|
name = "empty_defaults"
|
|
|
|
path = "examples/app/empty_defaults.rs"
|
2020-11-13 01:23:57 +00:00
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "headless"
|
|
|
|
path = "examples/app/headless.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "logs"
|
|
|
|
path = "examples/app/logs.rs"
|
|
|
|
|
2020-05-03 08:30:10 +00:00
|
|
|
[[example]]
|
|
|
|
name = "plugin"
|
|
|
|
path = "examples/app/plugin.rs"
|
|
|
|
|
2020-10-29 20:04:28 +00:00
|
|
|
[[example]]
|
|
|
|
name = "plugin_group"
|
|
|
|
path = "examples/app/plugin_group.rs"
|
|
|
|
|
2020-08-21 05:37:19 +00:00
|
|
|
[[example]]
|
|
|
|
name = "return_after_run"
|
|
|
|
path = "examples/app/return_after_run.rs"
|
|
|
|
|
2020-08-14 17:15:29 +00:00
|
|
|
[[example]]
|
|
|
|
name = "thread_pool_resources"
|
|
|
|
path = "examples/app/thread_pool_resources.rs"
|
|
|
|
|
2022-01-08 10:39:43 +00:00
|
|
|
[[example]]
|
|
|
|
name = "headless_defaults"
|
|
|
|
path = "examples/app/headless_defaults.rs"
|
|
|
|
|
2021-12-15 00:15:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "without_winit"
|
|
|
|
path = "examples/app/without_winit.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Assets
|
2020-05-17 03:18:30 +00:00
|
|
|
[[example]]
|
|
|
|
name = "asset_loading"
|
|
|
|
path = "examples/asset/asset_loading.rs"
|
|
|
|
|
2020-10-01 18:31:06 +00:00
|
|
|
[[example]]
|
2020-10-18 20:48:15 +00:00
|
|
|
name = "custom_asset"
|
|
|
|
path = "examples/asset/custom_asset.rs"
|
2020-10-01 18:31:06 +00:00
|
|
|
|
2020-12-18 19:34:44 +00:00
|
|
|
[[example]]
|
|
|
|
name = "custom_asset_io"
|
|
|
|
path = "examples/asset/custom_asset_io.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "hot_asset_reloading"
|
|
|
|
path = "examples/asset/hot_asset_reloading.rs"
|
|
|
|
|
2021-05-23 20:13:55 +00:00
|
|
|
# Async Tasks
|
|
|
|
[[example]]
|
|
|
|
name = "async_compute"
|
|
|
|
path = "examples/async_tasks/async_compute.rs"
|
|
|
|
|
2022-02-05 01:52:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "external_source_external_thread"
|
|
|
|
path = "examples/async_tasks/external_source_external_thread.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Audio
|
2020-07-16 20:46:51 +00:00
|
|
|
[[example]]
|
|
|
|
name = "audio"
|
|
|
|
path = "examples/audio/audio.rs"
|
|
|
|
|
2022-03-01 01:12:11 +00:00
|
|
|
[[example]]
|
|
|
|
name = "audio_control"
|
|
|
|
path = "examples/audio/audio_control.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Diagnostics
|
|
|
|
[[example]]
|
|
|
|
name = "log_diagnostics"
|
|
|
|
path = "examples/diagnostics/log_diagnostics.rs"
|
|
|
|
|
2020-05-04 21:14:49 +00:00
|
|
|
[[example]]
|
|
|
|
name = "custom_diagnostic"
|
|
|
|
path = "examples/diagnostics/custom_diagnostic.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# ECS (Entity Component System)
|
2020-05-04 21:14:49 +00:00
|
|
|
[[example]]
|
2021-02-22 04:50:05 +00:00
|
|
|
name = "ecs_guide"
|
|
|
|
path = "examples/ecs/ecs_guide.rs"
|
2020-05-04 21:14:49 +00:00
|
|
|
|
2020-12-31 22:29:08 +00:00
|
|
|
[[example]]
|
2021-07-12 20:09:43 +00:00
|
|
|
name = "component_change_detection"
|
|
|
|
path = "examples/ecs/component_change_detection.rs"
|
2020-12-31 22:29:08 +00:00
|
|
|
|
Implement `WorldQuery` derive macro (#2713)
# Objective
- Closes #786
- Closes #2252
- Closes #2588
This PR implements a derive macro that allows users to define their queries as structs with named fields.
## Example
```rust
#[derive(WorldQuery)]
#[world_query(derive(Debug))]
struct NumQuery<'w, T: Component, P: Component> {
entity: Entity,
u: UNumQuery<'w>,
generic: GenericQuery<'w, T, P>,
}
#[derive(WorldQuery)]
#[world_query(derive(Debug))]
struct UNumQuery<'w> {
u_16: &'w u16,
u_32_opt: Option<&'w u32>,
}
#[derive(WorldQuery)]
#[world_query(derive(Debug))]
struct GenericQuery<'w, T: Component, P: Component> {
generic: (&'w T, &'w P),
}
#[derive(WorldQuery)]
#[world_query(filter)]
struct NumQueryFilter<T: Component, P: Component> {
_u_16: With<u16>,
_u_32: With<u32>,
_or: Or<(With<i16>, Changed<u16>, Added<u32>)>,
_generic_tuple: (With<T>, With<P>),
_without: Without<Option<u16>>,
_tp: PhantomData<(T, P)>,
}
fn print_nums_readonly(query: Query<NumQuery<u64, i64>, NumQueryFilter<u64, i64>>) {
for num in query.iter() {
println!("{:#?}", num);
}
}
#[derive(WorldQuery)]
#[world_query(mutable, derive(Debug))]
struct MutNumQuery<'w, T: Component, P: Component> {
i_16: &'w mut i16,
i_32_opt: Option<&'w mut i32>,
}
fn print_nums(mut query: Query<MutNumQuery, NumQueryFilter<u64, i64>>) {
for num in query.iter_mut() {
println!("{:#?}", num);
}
}
```
## TODOs:
- [x] Add support for `&T` and `&mut T`
- [x] Test
- [x] Add support for optional types
- [x] Test
- [x] Add support for `Entity`
- [x] Test
- [x] Add support for nested `WorldQuery`
- [x] Test
- [x] Add support for tuples
- [x] Test
- [x] Add support for generics
- [x] Test
- [x] Add support for query filters
- [x] Test
- [x] Add support for `PhantomData`
- [x] Test
- [x] Refactor `read_world_query_field_type_info`
- [x] Properly document `readonly` attribute for nested queries and the static assertions that guarantee safety
- [x] Test that we never implement `ReadOnlyFetch` for types that need mutable access
- [x] Test that we insert static assertions for nested `WorldQuery` that a user marked as readonly
2022-02-24 00:19:49 +00:00
|
|
|
[[example]]
|
|
|
|
name = "custom_query_param"
|
|
|
|
path = "examples/ecs/custom_query_param.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "event"
|
|
|
|
path = "examples/ecs/event.rs"
|
|
|
|
|
2020-12-13 02:04:42 +00:00
|
|
|
[[example]]
|
|
|
|
name = "fixed_timestep"
|
|
|
|
path = "examples/ecs/fixed_timestep.rs"
|
|
|
|
|
2022-02-08 16:24:46 +00:00
|
|
|
[[example]]
|
|
|
|
name = "generic_system"
|
|
|
|
path = "examples/ecs/generic_system.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "hierarchy"
|
|
|
|
path = "examples/ecs/hierarchy.rs"
|
|
|
|
|
Add a method `iter_combinations` on query to iterate over combinations of query results (#1763)
Related to [discussion on discord](https://discord.com/channels/691052431525675048/742569353878437978/824731187724681289)
With const generics, it is now possible to write generic iterator over multiple entities at once.
This enables patterns of query iterations like
```rust
for [e1, e2, e3] in query.iter_combinations() {
// do something with relation of all three entities
}
```
The compiler is able to infer the correct iterator for given size of array, so either of those work
```rust
for [e1, e2] in query.iter_combinations() { ... }
for [e1, e2, e3] in query.iter_combinations() { ... }
```
This feature can be very useful for systems like collision detection.
When you ask for permutations of size K of N entities:
- if K == N, you get one result of all entities
- if K < N, you get all possible subsets of N with size K, without repetition
- if K > N, the result set is empty (no permutation of size K exist)
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2021-05-17 23:33:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "iter_combinations"
|
|
|
|
path = "examples/ecs/iter_combinations.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "parallel_query"
|
|
|
|
path = "examples/ecs/parallel_query.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "removal_detection"
|
|
|
|
path = "examples/ecs/removal_detection.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "startup_system"
|
|
|
|
path = "examples/ecs/startup_system.rs"
|
|
|
|
|
2020-12-13 02:04:42 +00:00
|
|
|
[[example]]
|
|
|
|
name = "state"
|
|
|
|
path = "examples/ecs/state.rs"
|
|
|
|
|
2020-11-17 02:18:00 +00:00
|
|
|
[[example]]
|
|
|
|
name = "system_chaining"
|
|
|
|
path = "examples/ecs/system_chaining.rs"
|
|
|
|
|
2021-03-03 03:11:11 +00:00
|
|
|
[[example]]
|
|
|
|
name = "system_param"
|
|
|
|
path = "examples/ecs/system_param.rs"
|
|
|
|
|
2021-04-23 19:08:16 +00:00
|
|
|
[[example]]
|
|
|
|
name = "system_sets"
|
|
|
|
path = "examples/ecs/system_sets.rs"
|
|
|
|
|
2020-11-27 19:39:33 +00:00
|
|
|
[[example]]
|
|
|
|
name = "timers"
|
|
|
|
path = "examples/ecs/timers.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Games
|
2021-01-21 22:10:02 +00:00
|
|
|
[[example]]
|
|
|
|
name = "alien_cake_addict"
|
2022-04-10 02:05:21 +00:00
|
|
|
path = "examples/games/alien_cake_addict.rs"
|
2021-01-21 22:10:02 +00:00
|
|
|
|
2020-06-27 04:40:09 +00:00
|
|
|
[[example]]
|
|
|
|
name = "breakout"
|
2022-04-10 02:05:21 +00:00
|
|
|
path = "examples/games/breakout.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "contributors"
|
|
|
|
path = "examples/games/contributors.rs"
|
2020-06-27 04:40:09 +00:00
|
|
|
|
2022-01-14 19:09:42 +00:00
|
|
|
[[example]]
|
|
|
|
name = "game_menu"
|
2022-04-10 02:05:21 +00:00
|
|
|
path = "examples/games/game_menu.rs"
|
2022-01-14 19:09:42 +00:00
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Input
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
2021-02-22 04:50:05 +00:00
|
|
|
name = "char_input_events"
|
|
|
|
path = "examples/input/char_input_events.rs"
|
2020-05-01 20:12:47 +00:00
|
|
|
|
|
|
|
[[example]]
|
2021-02-22 04:50:05 +00:00
|
|
|
name = "gamepad_input"
|
|
|
|
path = "examples/input/gamepad_input.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "gamepad_input_events"
|
|
|
|
path = "examples/input/gamepad_input_events.rs"
|
2020-06-05 06:49:36 +00:00
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "keyboard_input"
|
|
|
|
path = "examples/input/keyboard_input.rs"
|
|
|
|
|
2021-03-14 21:00:36 +00:00
|
|
|
[[example]]
|
|
|
|
name = "keyboard_modifiers"
|
|
|
|
path = "examples/input/keyboard_modifiers.rs"
|
|
|
|
|
2020-06-05 06:49:36 +00:00
|
|
|
[[example]]
|
|
|
|
name = "keyboard_input_events"
|
|
|
|
path = "examples/input/keyboard_input_events.rs"
|
2020-05-01 20:12:47 +00:00
|
|
|
|
2020-11-07 01:15:56 +00:00
|
|
|
[[example]]
|
2021-02-22 04:50:05 +00:00
|
|
|
name = "mouse_input"
|
|
|
|
path = "examples/input/mouse_input.rs"
|
2020-09-18 21:43:47 +00:00
|
|
|
|
2020-10-21 17:27:00 +00:00
|
|
|
[[example]]
|
2021-02-22 04:50:05 +00:00
|
|
|
name = "mouse_input_events"
|
|
|
|
path = "examples/input/mouse_input_events.rs"
|
2020-10-21 17:27:00 +00:00
|
|
|
|
2022-03-08 17:14:08 +00:00
|
|
|
[[example]]
|
|
|
|
name = "mouse_grab"
|
|
|
|
path = "examples/input/mouse_grab.rs"
|
|
|
|
|
2020-10-18 19:24:01 +00:00
|
|
|
[[example]]
|
|
|
|
name = "touch_input"
|
|
|
|
path = "examples/input/touch_input.rs"
|
|
|
|
|
|
|
|
[[example]]
|
2020-10-18 20:20:42 +00:00
|
|
|
name = "touch_input_events"
|
|
|
|
path = "examples/input/touch_input_events.rs"
|
2020-10-18 19:24:01 +00:00
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Reflection
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
2020-11-28 00:39:59 +00:00
|
|
|
name = "reflection"
|
|
|
|
path = "examples/reflection/reflection.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "generic_reflection"
|
|
|
|
path = "examples/reflection/generic_reflection.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "reflection_types"
|
|
|
|
path = "examples/reflection/reflection_types.rs"
|
|
|
|
|
2020-11-28 00:39:59 +00:00
|
|
|
[[example]]
|
|
|
|
name = "trait_reflection"
|
|
|
|
path = "examples/reflection/trait_reflection.rs"
|
2020-05-01 20:12:47 +00:00
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Scene
|
2020-05-22 06:58:11 +00:00
|
|
|
[[example]]
|
2020-11-28 00:39:59 +00:00
|
|
|
name = "scene"
|
|
|
|
path = "examples/scene/scene.rs"
|
2020-05-22 06:58:11 +00:00
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Shaders
|
Mesh vertex buffer layouts (#3959)
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>
2022-02-23 23:21:13 +00:00
|
|
|
[[example]]
|
|
|
|
name = "custom_vertex_attribute"
|
|
|
|
path = "examples/shader/custom_vertex_attribute.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "shader_defs"
|
|
|
|
path = "examples/shader/shader_defs.rs"
|
|
|
|
|
Modular Rendering (#2831)
This changes how render logic is composed to make it much more modular. Previously, all extraction logic was centralized for a given "type" of rendered thing. For example, we extracted meshes into a vector of ExtractedMesh, which contained the mesh and material asset handles, the transform, etc. We looked up bindings for "drawn things" using their index in the `Vec<ExtractedMesh>`. This worked fine for built in rendering, but made it hard to reuse logic for "custom" rendering. It also prevented us from reusing things like "extracted transforms" across contexts.
To make rendering more modular, I made a number of changes:
* Entities now drive rendering:
* We extract "render components" from "app components" and store them _on_ entities. No more centralized uber lists! We now have true "ECS-driven rendering"
* To make this perform well, I implemented #2673 in upstream Bevy for fast batch insertions into specific entities. This was merged into the `pipelined-rendering` branch here: #2815
* Reworked the `Draw` abstraction:
* Generic `PhaseItems`: each draw phase can define its own type of "rendered thing", which can define its own "sort key"
* Ported the 2d, 3d, and shadow phases to the new PhaseItem impl (currently Transparent2d, Transparent3d, and Shadow PhaseItems)
* `Draw` trait and and `DrawFunctions` are now generic on PhaseItem
* Modular / Ergonomic `DrawFunctions` via `RenderCommands`
* RenderCommand is a trait that runs an ECS query and produces one or more RenderPass calls. Types implementing this trait can be composed to create a final DrawFunction. For example the DrawPbr DrawFunction is created from the following DrawCommand tuple. Const generics are used to set specific bind group locations:
```rust
pub type DrawPbr = (
SetPbrPipeline,
SetMeshViewBindGroup<0>,
SetStandardMaterialBindGroup<1>,
SetTransformBindGroup<2>,
DrawMesh,
);
```
* The new `custom_shader_pipelined` example illustrates how the commands above can be reused to create a custom draw function:
```rust
type DrawCustom = (
SetCustomMaterialPipeline,
SetMeshViewBindGroup<0>,
SetTransformBindGroup<2>,
DrawMesh,
);
```
* ExtractComponentPlugin and UniformComponentPlugin:
* Simple, standardized ways to easily extract individual components and write them to GPU buffers
* Ported PBR and Sprite rendering to the new primitives above.
* Removed staging buffer from UniformVec in favor of direct Queue usage
* Makes UniformVec much easier to use and more ergonomic. Completely removes the need for custom render graph nodes in these contexts (see the PbrNode and view Node removals and the much simpler call patterns in the relevant Prepare systems).
* Added a many_cubes_pipelined example to benchmark baseline 3d rendering performance and ensure there were no major regressions during this port. Avoiding regressions was challenging given that the old approach of extracting into centralized vectors is basically the "optimal" approach. However thanks to a various ECS optimizations and render logic rephrasing, we pretty much break even on this benchmark!
* Lifetimeless SystemParams: this will be a bit divisive, but as we continue to embrace "trait driven systems" (ex: ExtractComponentPlugin, UniformComponentPlugin, DrawCommand), the ergonomics of `(Query<'static, 'static, (&'static A, &'static B, &'static)>, Res<'static, C>)` were getting very hard to bear. As a compromise, I added "static type aliases" for the relevant SystemParams. The previous example can now be expressed like this: `(SQuery<(Read<A>, Read<B>)>, SRes<C>)`. If anyone has better ideas / conflicting opinions, please let me know!
* RunSystem trait: a way to define Systems via a trait with a SystemParam associated type. This is used to implement the various plugins mentioned above. I also added SystemParamItem and QueryItem type aliases to make "trait stye" ecs interactions nicer on the eyes (and fingers).
* RenderAsset retrying: ensures that render assets are only created when they are "ready" and allows us to create bind groups directly inside render assets (which significantly simplified the StandardMaterial code). I think ultimately we should swap this out on "asset dependency" events to wait for dependencies to load, but this will require significant asset system changes.
* Updated some built in shaders to account for missing MeshUniform fields
2021-09-23 06:16:11 +00:00
|
|
|
[[example]]
|
2021-12-14 03:58:23 +00:00
|
|
|
name = "shader_material"
|
|
|
|
path = "examples/shader/shader_material.rs"
|
Pipeline Specialization, Shader Assets, and Shader Preprocessing (#3031)
## New Features
This adds the following to the new renderer:
* **Shader Assets**
* Shaders are assets again! Users no longer need to call `include_str!` for their shaders
* Shader hot-reloading
* **Shader Defs / Shader Preprocessing**
* Shaders now support `# ifdef NAME`, `# ifndef NAME`, and `# endif` preprocessor directives
* **Bevy RenderPipelineDescriptor and RenderPipelineCache**
* Bevy now provides its own `RenderPipelineDescriptor` and the wgpu version is now exported as `RawRenderPipelineDescriptor`. This allows users to define pipelines with `Handle<Shader>` instead of needing to manually compile and reference `ShaderModules`, enables passing in shader defs to configure the shader preprocessor, makes hot reloading possible (because the descriptor can be owned and used to create new pipelines when a shader changes), and opens the doors to pipeline specialization.
* The `RenderPipelineCache` now handles compiling and re-compiling Bevy RenderPipelineDescriptors. It has internal PipelineLayout and ShaderModule caches. Users receive a `CachedPipelineId`, which can be used to look up the actual `&RenderPipeline` during rendering.
* **Pipeline Specialization**
* This enables defining per-entity-configurable pipelines that specialize on arbitrary custom keys. In practice this will involve specializing based on things like MSAA values, Shader Defs, Bind Group existence, and Vertex Layouts.
* Adds a `SpecializedPipeline` trait and `SpecializedPipelines<MyPipeline>` resource. This is a simple layer that generates Bevy RenderPipelineDescriptors based on a custom key defined for the pipeline.
* Specialized pipelines are also hot-reloadable.
* This was the result of experimentation with two different approaches:
1. **"generic immediate mode multi-key hash pipeline specialization"**
* breaks up the pipeline into multiple "identities" (the core pipeline definition, shader defs, mesh layout, bind group layout). each of these identities has its own key. looking up / compiling a specific version of a pipeline requires composing all of these keys together
* the benefit of this approach is that it works for all pipelines / the pipeline is fully identified by the keys. the multiple keys allow pre-hashing parts of the pipeline identity where possible (ex: pre compute the mesh identity for all meshes)
* the downside is that any per-entity data that informs the values of these keys could require expensive re-hashes. computing each key for each sprite tanked bevymark performance (sprites don't actually need this level of specialization yet ... but things like pbr and future sprite scenarios might).
* this is the approach rafx used last time i checked
2. **"custom key specialization"**
* Pipelines by default are not specialized
* Pipelines that need specialization implement a SpecializedPipeline trait with a custom key associated type
* This allows specialization keys to encode exactly the amount of information required (instead of needing to be a combined hash of the entire pipeline). Generally this should fit in a small number of bytes. Per-entity specialization barely registers anymore on things like bevymark. It also makes things like "shader defs" way cheaper to hash because we can use context specific bitflags instead of strings.
* Despite the extra trait, it actually generally makes pipeline definitions + lookups simpler: managing multiple keys (and making the appropriate calls to manage these keys) was way more complicated.
* I opted for custom key specialization. It performs better generally and in my opinion is better UX. Fortunately the way this is implemented also allows for custom caches as this all builds on a common abstraction: the RenderPipelineCache. The built in custom key trait is just a simple / pre-defined way to interact with the cache
## Callouts
* The SpecializedPipeline trait makes it easy to inherit pipeline configuration in custom pipelines. The changes to `custom_shader_pipelined` and the new `shader_defs_pipelined` example illustrate how much simpler it is to define custom pipelines based on the PbrPipeline.
* The shader preprocessor is currently pretty naive (it just uses regexes to process each line). Ultimately we might want to build a more custom parser for more performance + better error handling, but for now I'm happy to optimize for "easy to implement and understand".
## Next Steps
* Port compute pipelines to the new system
* Add more preprocessor directives (else, elif, import)
* More flexible vertex attribute specialization / enable cheaply specializing on specific mesh vertex layouts
2021-10-28 19:07:47 +00:00
|
|
|
|
2022-02-28 22:55:14 +00:00
|
|
|
[[example]]
|
|
|
|
name = "shader_material_screenspace_texture"
|
|
|
|
path = "examples/shader/shader_material_screenspace_texture.rs"
|
|
|
|
|
2022-01-05 19:43:11 +00:00
|
|
|
[[example]]
|
|
|
|
name = "shader_material_glsl"
|
|
|
|
path = "examples/shader/shader_material_glsl.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "shader_instancing"
|
|
|
|
path = "examples/shader/shader_instancing.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "animate_shader"
|
|
|
|
path = "examples/shader/animate_shader.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "compute_shader_game_of_life"
|
|
|
|
path = "examples/shader/compute_shader_game_of_life.rs"
|
|
|
|
|
2022-04-10 02:05:21 +00:00
|
|
|
# Stress tests
|
|
|
|
|
2020-11-13 02:03:57 +00:00
|
|
|
[[example]]
|
|
|
|
name = "bevymark"
|
2022-04-10 02:05:21 +00:00
|
|
|
path = "examples/stress_tests/bevymark.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "many_cubes"
|
|
|
|
path = "examples/stress_tests/many_cubes.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "many_lights"
|
|
|
|
path = "examples/stress_tests/many_lights.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "many_sprites"
|
|
|
|
path = "examples/stress_tests/many_sprites.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "transform_hierarchy"
|
|
|
|
path = "examples/stress_tests/transform_hierarchy.rs"
|
|
|
|
|
|
|
|
# Tools
|
2020-11-13 02:03:57 +00:00
|
|
|
|
2022-03-19 19:14:13 +00:00
|
|
|
[[example]]
|
|
|
|
name = "scene_viewer"
|
|
|
|
path = "examples/tools/scene_viewer.rs"
|
|
|
|
|
2022-03-15 05:49:49 +00:00
|
|
|
# Transforms
|
|
|
|
[[example]]
|
|
|
|
name = "global_vs_local_translation"
|
|
|
|
path = "examples/transforms/global_vs_local_translation.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "3d_rotation"
|
|
|
|
path = "examples/transforms/3d_rotation.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "scale"
|
|
|
|
path = "examples/transforms/scale.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "transform"
|
|
|
|
path = "examples/transforms/transform.rs"
|
|
|
|
|
|
|
|
[[example]]
|
|
|
|
name = "translation"
|
|
|
|
path = "examples/transforms/translation.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# UI (User Interface)
|
2020-07-18 21:08:46 +00:00
|
|
|
[[example]]
|
|
|
|
name = "button"
|
|
|
|
path = "examples/ui/button.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "font_atlas_debug"
|
|
|
|
path = "examples/ui/font_atlas_debug.rs"
|
|
|
|
|
2020-05-13 20:09:32 +00:00
|
|
|
[[example]]
|
|
|
|
name = "text"
|
|
|
|
path = "examples/ui/text.rs"
|
|
|
|
|
2020-11-13 00:21:48 +00:00
|
|
|
[[example]]
|
|
|
|
name = "text_debug"
|
|
|
|
path = "examples/ui/text_debug.rs"
|
|
|
|
|
2020-05-01 20:12:47 +00:00
|
|
|
[[example]]
|
|
|
|
name = "ui"
|
|
|
|
path = "examples/ui/ui.rs"
|
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Window
|
2020-06-25 22:24:27 +00:00
|
|
|
[[example]]
|
|
|
|
name = "clear_color"
|
|
|
|
path = "examples/window/clear_color.rs"
|
2021-12-18 19:38:05 +00:00
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "low_power"
|
|
|
|
path = "examples/window/low_power.rs"
|
|
|
|
|
2021-12-18 19:38:05 +00:00
|
|
|
[[example]]
|
|
|
|
name = "multiple_windows"
|
|
|
|
path = "examples/window/multiple_windows.rs"
|
2020-06-25 22:24:27 +00:00
|
|
|
|
2020-12-28 20:26:50 +00:00
|
|
|
[[example]]
|
|
|
|
name = "scale_factor_override"
|
|
|
|
path = "examples/window/scale_factor_override.rs"
|
|
|
|
|
2021-12-08 20:53:35 +00:00
|
|
|
[[example]]
|
|
|
|
name = "transparent_window"
|
|
|
|
path = "examples/window/transparent_window.rs"
|
|
|
|
|
2020-07-20 09:05:56 +00:00
|
|
|
[[example]]
|
|
|
|
name = "window_settings"
|
2020-08-21 05:37:19 +00:00
|
|
|
path = "examples/window/window_settings.rs"
|
2020-09-16 01:05:31 +00:00
|
|
|
|
2021-02-22 04:50:05 +00:00
|
|
|
# Android
|
2020-11-03 00:30:30 +00:00
|
|
|
[[example]]
|
2020-11-10 03:26:08 +00:00
|
|
|
crate-type = ["cdylib"]
|
2020-11-03 20:00:47 +00:00
|
|
|
name = "android"
|
|
|
|
path = "examples/android/android.rs"
|
2020-11-03 00:30:30 +00:00
|
|
|
|
|
|
|
[package.metadata.android]
|
2020-11-12 00:31:16 +00:00
|
|
|
apk_label = "Bevy Example"
|
|
|
|
assets = "assets"
|
|
|
|
res = "assets/android-res"
|
|
|
|
icon = "@mipmap/ic_launcher"
|
2020-11-22 00:38:24 +00:00
|
|
|
build_targets = ["aarch64-linux-android", "armv7-linux-androideabi"]
|
2020-11-03 19:32:48 +00:00
|
|
|
min_sdk_version = 16
|
2020-11-10 03:26:08 +00:00
|
|
|
target_sdk_version = 29
|