2021-04-11 20:13:07 +00:00
|
|
|
use bevy::{
|
|
|
|
|
core::{Time, Timer},
|
|
|
|
|
diagnostic::{Diagnostics, FrameTimeDiagnosticsPlugin, LogDiagnosticsPlugin},
|
|
|
|
|
ecs::prelude::*,
|
|
|
|
|
input::Input,
|
2021-08-26 00:53:51 +00:00
|
|
|
math::Vec3,
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
prelude::{info, App, AssetServer, Handle, MouseButton, Transform},
|
2021-06-21 23:28:52 +00:00
|
|
|
render2::{camera::OrthographicCameraBundle, color::Color, texture::Image},
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
sprite2::{PipelinedSpriteBundle, Sprite},
|
2021-04-11 20:13:07 +00:00
|
|
|
window::WindowDescriptor,
|
|
|
|
|
PipelinedDefaultPlugins,
|
|
|
|
|
};
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
use rand::{random, Rng};
|
2021-04-11 20:13:07 +00:00
|
|
|
|
|
|
|
|
const BIRDS_PER_SECOND: u32 = 10000;
|
2021-07-02 01:05:20 +00:00
|
|
|
const _BASE_COLOR: Color = Color::rgb(5.0, 5.0, 5.0);
|
2021-04-11 20:13:07 +00:00
|
|
|
const GRAVITY: f32 = -9.8 * 100.0;
|
|
|
|
|
const MAX_VELOCITY: f32 = 750.;
|
|
|
|
|
const BIRD_SCALE: f32 = 0.15;
|
|
|
|
|
const HALF_BIRD_SIZE: f32 = 256. * BIRD_SCALE * 0.5;
|
|
|
|
|
|
|
|
|
|
struct BevyCounter {
|
|
|
|
|
pub count: u128,
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
pub color: Color,
|
2021-04-11 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
|
2021-11-22 23:16:36 +00:00
|
|
|
#[derive(Component)]
|
2021-04-11 20:13:07 +00:00
|
|
|
struct Bird {
|
|
|
|
|
velocity: Vec3,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// struct BirdMaterial(Handle<ColorMaterial>);
|
|
|
|
|
|
|
|
|
|
// impl FromWorld for BirdMaterial {
|
|
|
|
|
// fn from_world(world: &mut World) -> Self {
|
|
|
|
|
// let world = world.cell();
|
|
|
|
|
// let mut color_materials = world.get_resource_mut::<Assets<ColorMaterial>>().unwrap();
|
|
|
|
|
// let asset_server = world.get_resource_mut::<AssetServer>().unwrap();
|
|
|
|
|
// BirdMaterial(color_materials.add(asset_server.load("branding/icon.png").into()))
|
|
|
|
|
// }
|
|
|
|
|
// }
|
|
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
|
App::new()
|
|
|
|
|
.insert_resource(WindowDescriptor {
|
|
|
|
|
title: "BevyMark".to_string(),
|
|
|
|
|
width: 800.,
|
|
|
|
|
height: 600.,
|
|
|
|
|
vsync: false,
|
|
|
|
|
resizable: true,
|
|
|
|
|
..Default::default()
|
|
|
|
|
})
|
|
|
|
|
.add_plugins(PipelinedDefaultPlugins)
|
|
|
|
|
.add_plugin(FrameTimeDiagnosticsPlugin::default())
|
|
|
|
|
.add_plugin(LogDiagnosticsPlugin::default())
|
2021-06-21 23:28:52 +00:00
|
|
|
// .add_plugin(WgpuResourceDiagnosticsPlugin::default())
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
.insert_resource(BevyCounter {
|
|
|
|
|
count: 0,
|
|
|
|
|
color: Color::WHITE,
|
|
|
|
|
})
|
2021-04-11 20:13:07 +00:00
|
|
|
// .init_resource::<BirdMaterial>()
|
2021-07-26 23:44:23 +00:00
|
|
|
.add_startup_system(setup)
|
|
|
|
|
.add_system(mouse_handler)
|
|
|
|
|
.add_system(movement_system)
|
|
|
|
|
.add_system(collision_system)
|
|
|
|
|
.add_system(counter_system)
|
2021-04-11 20:13:07 +00:00
|
|
|
.run();
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-21 23:28:52 +00:00
|
|
|
struct BirdTexture(Handle<Image>);
|
2021-04-11 20:13:07 +00:00
|
|
|
|
|
|
|
|
fn setup(
|
|
|
|
|
mut commands: Commands,
|
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
|
|
|
window: Res<WindowDescriptor>,
|
|
|
|
|
mut counter: ResMut<BevyCounter>,
|
2021-04-11 20:13:07 +00:00
|
|
|
asset_server: Res<AssetServer>,
|
|
|
|
|
) {
|
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
|
|
|
let texture = asset_server.load("branding/icon.png");
|
|
|
|
|
if let Some(initial_count) = std::env::args()
|
|
|
|
|
.nth(1)
|
|
|
|
|
.and_then(|arg| arg.parse::<u128>().ok())
|
|
|
|
|
{
|
|
|
|
|
spawn_birds(
|
|
|
|
|
&mut commands,
|
|
|
|
|
&window,
|
|
|
|
|
&mut counter,
|
|
|
|
|
initial_count,
|
|
|
|
|
texture.clone_weak(),
|
|
|
|
|
);
|
|
|
|
|
}
|
2021-04-11 20:13:07 +00:00
|
|
|
commands.spawn_bundle(OrthographicCameraBundle::new_2d());
|
|
|
|
|
// commands.spawn_bundle(UiCameraBundle::default());
|
|
|
|
|
// commands.spawn_bundle(TextBundle {
|
|
|
|
|
// text: Text {
|
|
|
|
|
// sections: vec![
|
|
|
|
|
// TextSection {
|
|
|
|
|
// value: "Bird Count: ".to_string(),
|
|
|
|
|
// style: TextStyle {
|
|
|
|
|
// font: asset_server.load("fonts/FiraSans-Bold.ttf"),
|
|
|
|
|
// font_size: 40.0,
|
|
|
|
|
// color: Color::rgb(0.0, 1.0, 0.0),
|
|
|
|
|
// },
|
|
|
|
|
// },
|
|
|
|
|
// TextSection {
|
|
|
|
|
// value: "".to_string(),
|
|
|
|
|
// style: TextStyle {
|
|
|
|
|
// font: asset_server.load("fonts/FiraSans-Bold.ttf"),
|
|
|
|
|
// font_size: 40.0,
|
|
|
|
|
// color: Color::rgb(0.0, 1.0, 1.0),
|
|
|
|
|
// },
|
|
|
|
|
// },
|
|
|
|
|
// TextSection {
|
|
|
|
|
// value: "\nAverage FPS: ".to_string(),
|
|
|
|
|
// style: TextStyle {
|
|
|
|
|
// font: asset_server.load("fonts/FiraSans-Bold.ttf"),
|
|
|
|
|
// font_size: 40.0,
|
|
|
|
|
// color: Color::rgb(0.0, 1.0, 0.0),
|
|
|
|
|
// },
|
|
|
|
|
// },
|
|
|
|
|
// TextSection {
|
|
|
|
|
// value: "".to_string(),
|
|
|
|
|
// style: TextStyle {
|
|
|
|
|
// font: asset_server.load("fonts/FiraSans-Bold.ttf"),
|
|
|
|
|
// font_size: 40.0,
|
|
|
|
|
// color: Color::rgb(0.0, 1.0, 1.0),
|
|
|
|
|
// },
|
|
|
|
|
// },
|
|
|
|
|
// ],
|
|
|
|
|
// ..Default::default()
|
|
|
|
|
// },
|
|
|
|
|
// style: Style {
|
|
|
|
|
// position_type: PositionType::Absolute,
|
|
|
|
|
// position: Rect {
|
|
|
|
|
// top: Val::Px(5.0),
|
|
|
|
|
// left: Val::Px(5.0),
|
|
|
|
|
// ..Default::default()
|
|
|
|
|
// },
|
|
|
|
|
// ..Default::default()
|
|
|
|
|
// },
|
|
|
|
|
// ..Default::default()
|
|
|
|
|
// });
|
|
|
|
|
|
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
|
|
|
commands.insert_resource(BirdTexture(texture));
|
2021-04-11 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[allow(clippy::too_many_arguments)]
|
|
|
|
|
fn mouse_handler(
|
|
|
|
|
mut commands: Commands,
|
2021-07-02 01:05:20 +00:00
|
|
|
_asset_server: Res<AssetServer>,
|
2021-04-11 20:13:07 +00:00
|
|
|
time: Res<Time>,
|
|
|
|
|
mouse_button_input: Res<Input<MouseButton>>,
|
|
|
|
|
window: Res<WindowDescriptor>,
|
|
|
|
|
bird_texture: Res<BirdTexture>,
|
|
|
|
|
// mut bird_material: ResMut<BirdMaterial>,
|
|
|
|
|
mut counter: ResMut<BevyCounter>,
|
|
|
|
|
// mut materials: ResMut<Assets<ColorMaterial>>,
|
|
|
|
|
) {
|
|
|
|
|
// if mouse_button_input.just_pressed(MouseButton::Left) {
|
|
|
|
|
// let mut rnd = rand::thread_rng();
|
|
|
|
|
// let color = gen_color(&mut rnd);
|
|
|
|
|
|
|
|
|
|
// let texture_handle = asset_server.load("branding/icon.png");
|
|
|
|
|
|
|
|
|
|
// bird_material.0 = materials.add(ColorMaterial {
|
|
|
|
|
// color: BASE_COLOR * color,
|
|
|
|
|
// texture: Some(texture_handle),
|
|
|
|
|
// });
|
|
|
|
|
// }
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
if mouse_button_input.just_released(MouseButton::Left) {
|
|
|
|
|
counter.color = Color::rgb(random(), random(), random());
|
|
|
|
|
}
|
2021-04-11 20:13:07 +00:00
|
|
|
|
|
|
|
|
if mouse_button_input.pressed(MouseButton::Left) {
|
|
|
|
|
let spawn_count = (BIRDS_PER_SECOND as f64 * time.delta_seconds_f64()) as u128;
|
|
|
|
|
spawn_birds(
|
|
|
|
|
&mut commands,
|
|
|
|
|
&window,
|
|
|
|
|
&mut counter,
|
|
|
|
|
spawn_count,
|
|
|
|
|
bird_texture.0.clone(),
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn spawn_birds(
|
|
|
|
|
commands: &mut Commands,
|
|
|
|
|
window: &WindowDescriptor,
|
|
|
|
|
counter: &mut BevyCounter,
|
|
|
|
|
spawn_count: u128,
|
2021-06-21 23:28:52 +00:00
|
|
|
texture: Handle<Image>,
|
2021-04-11 20:13:07 +00:00
|
|
|
) {
|
|
|
|
|
let bird_x = (window.width / -2.) + HALF_BIRD_SIZE;
|
|
|
|
|
let bird_y = (window.height / 2.) - HALF_BIRD_SIZE;
|
|
|
|
|
for count in 0..spawn_count {
|
|
|
|
|
let bird_z = (counter.count + count) as f32 * 0.00001;
|
|
|
|
|
commands
|
|
|
|
|
.spawn_bundle(PipelinedSpriteBundle {
|
|
|
|
|
// material: bird_material.0.clone(),
|
|
|
|
|
texture: texture.clone(),
|
|
|
|
|
transform: Transform {
|
|
|
|
|
translation: Vec3::new(bird_x, bird_y, bird_z),
|
|
|
|
|
scale: Vec3::splat(BIRD_SCALE),
|
|
|
|
|
..Default::default()
|
|
|
|
|
},
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
sprite: Sprite {
|
|
|
|
|
color: counter.color,
|
|
|
|
|
..Default::default()
|
|
|
|
|
},
|
2021-04-11 20:13:07 +00:00
|
|
|
..Default::default()
|
|
|
|
|
})
|
|
|
|
|
.insert(Bird {
|
|
|
|
|
velocity: Vec3::new(
|
|
|
|
|
rand::random::<f32>() * MAX_VELOCITY - (MAX_VELOCITY * 0.5),
|
|
|
|
|
0.,
|
|
|
|
|
0.,
|
|
|
|
|
),
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
counter.count += spawn_count;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn movement_system(time: Res<Time>, mut bird_query: Query<(&mut Bird, &mut Transform)>) {
|
|
|
|
|
for (mut bird, mut transform) in bird_query.iter_mut() {
|
|
|
|
|
transform.translation.x += bird.velocity.x * time.delta_seconds();
|
|
|
|
|
transform.translation.y += bird.velocity.y * time.delta_seconds();
|
|
|
|
|
bird.velocity.y += GRAVITY * time.delta_seconds();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn collision_system(window: Res<WindowDescriptor>, mut bird_query: Query<(&mut Bird, &Transform)>) {
|
|
|
|
|
let half_width = window.width as f32 * 0.5;
|
|
|
|
|
let half_height = window.height as f32 * 0.5;
|
|
|
|
|
|
|
|
|
|
for (mut bird, transform) in bird_query.iter_mut() {
|
|
|
|
|
let x_vel = bird.velocity.x;
|
|
|
|
|
let y_vel = bird.velocity.y;
|
|
|
|
|
let x_pos = transform.translation.x;
|
|
|
|
|
let y_pos = transform.translation.y;
|
|
|
|
|
|
|
|
|
|
if (x_vel > 0. && x_pos + HALF_BIRD_SIZE > half_width)
|
|
|
|
|
|| (x_vel <= 0. && x_pos - HALF_BIRD_SIZE < -(half_width))
|
|
|
|
|
{
|
|
|
|
|
bird.velocity.x = -x_vel;
|
|
|
|
|
}
|
|
|
|
|
if y_vel < 0. && y_pos - HALF_BIRD_SIZE < -half_height {
|
|
|
|
|
bird.velocity.y = -y_vel;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct CountTimer {
|
|
|
|
|
timer: Timer,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Default for CountTimer {
|
|
|
|
|
fn default() -> Self {
|
|
|
|
|
Self {
|
|
|
|
|
timer: Timer::from_seconds(1.0, true),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn counter_system(
|
|
|
|
|
mut timer: Local<CountTimer>,
|
2021-06-26 22:35:07 +00:00
|
|
|
_diagnostics: Res<Diagnostics>,
|
2021-04-11 20:13:07 +00:00
|
|
|
time: Res<Time>,
|
|
|
|
|
counter: Res<BevyCounter>,
|
|
|
|
|
) {
|
|
|
|
|
if timer.timer.tick(time.delta()).finished() {
|
Sprite Batching (#3060)
This implements the following:
* **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example.
* **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite.
* **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`.
* **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.
Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
2021-11-04 20:28:53 +00:00
|
|
|
info!("counter: {}", counter.count);
|
2021-04-11 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Generate a color modulation
|
|
|
|
|
///
|
|
|
|
|
/// Because there is no `Mul<Color> for Color` instead `[f32; 3]` is
|
|
|
|
|
/// used.
|
2021-06-26 22:35:07 +00:00
|
|
|
fn _gen_color(rng: &mut impl Rng) -> [f32; 3] {
|
2021-04-11 20:13:07 +00:00
|
|
|
let r = rng.gen_range(0.2..1.0);
|
|
|
|
|
let g = rng.gen_range(0.2..1.0);
|
|
|
|
|
let b = rng.gen_range(0.2..1.0);
|
|
|
|
|
let v = Vec3::new(r, g, b);
|
|
|
|
|
v.normalize().into()
|
|
|
|
|
}
|
