2021-05-23 20:13:55 +00:00
|
|
|
use bevy::{
|
|
|
|
prelude::*,
|
|
|
|
tasks::{AsyncComputeTaskPool, Task},
|
|
|
|
};
|
|
|
|
use futures_lite::future;
|
|
|
|
use rand::Rng;
|
|
|
|
use std::time::{Duration, Instant};
|
|
|
|
|
2021-12-29 17:25:34 +00:00
|
|
|
/// This example shows how to use the ECS and the [`AsyncComputeTaskPool`]
|
2021-05-23 20:13:55 +00:00
|
|
|
/// to spawn, poll, and complete tasks across systems and system ticks.
|
|
|
|
fn main() {
|
2021-07-27 20:21:06 +00:00
|
|
|
App::new()
|
2021-05-23 20:13:55 +00:00
|
|
|
.insert_resource(Msaa { samples: 4 })
|
|
|
|
.add_plugins(DefaultPlugins)
|
2021-07-27 23:42:36 +00:00
|
|
|
.add_startup_system(setup_env)
|
|
|
|
.add_startup_system(add_assets)
|
|
|
|
.add_startup_system(spawn_tasks)
|
|
|
|
.add_system(handle_tasks)
|
2021-05-23 20:13:55 +00:00
|
|
|
.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Number of cubes to spawn across the x, y, and z axis
|
|
|
|
const NUM_CUBES: u32 = 6;
|
|
|
|
|
bevy_derive: Add derives for `Deref` and `DerefMut` (#4328)
# Objective
A common pattern in Rust is the [newtype](https://doc.rust-lang.org/rust-by-example/generics/new_types.html). This is an especially useful pattern in Bevy as it allows us to give common/foreign types different semantics (such as allowing it to implement `Component` or `FromWorld`) or to simply treat them as a "new type" (clever). For example, it allows us to wrap a common `Vec<String>` and do things like:
```rust
#[derive(Component)]
struct Items(Vec<String>);
fn give_sword(query: Query<&mut Items>) {
query.single_mut().0.push(String::from("Flaming Poisoning Raging Sword of Doom"));
}
```
> We could then define another struct that wraps `Vec<String>` without anything clashing in the query.
However, one of the worst parts of this pattern is the ugly `.0` we have to write in order to access the type we actually care about. This is why people often implement `Deref` and `DerefMut` in order to get around this.
Since it's such a common pattern, especially for Bevy, it makes sense to add a derive macro to automatically add those implementations.
## Solution
Added a derive macro for `Deref` and another for `DerefMut` (both exported into the prelude). This works on all structs (including tuple structs) as long as they only contain a single field:
```rust
#[derive(Deref)]
struct Foo(String);
#[derive(Deref, DerefMut)]
struct Bar {
name: String,
}
```
This allows us to then remove that pesky `.0`:
```rust
#[derive(Component, Deref, DerefMut)]
struct Items(Vec<String>);
fn give_sword(query: Query<&mut Items>) {
query.single_mut().push(String::from("Flaming Poisoning Raging Sword of Doom"));
}
```
### Alternatives
There are other alternatives to this such as by using the [`derive_more`](https://crates.io/crates/derive_more) crate. However, it doesn't seem like we need an entire crate just yet since we only need `Deref` and `DerefMut` (for now).
### Considerations
One thing to consider is that the Rust std library recommends _not_ using `Deref` and `DerefMut` for things like this: "`Deref` should only be implemented for smart pointers to avoid confusion" ([reference](https://doc.rust-lang.org/std/ops/trait.Deref.html)). Personally, I believe it makes sense to use it in the way described above, but others may disagree.
### Additional Context
Discord: https://discord.com/channels/691052431525675048/692572690833473578/956648422163746827 (controversiality discussed [here](https://discord.com/channels/691052431525675048/692572690833473578/956711911481835630))
---
## Changelog
- Add `Deref` derive macro (exported to prelude)
- Add `DerefMut` derive macro (exported to prelude)
- Updated most newtypes in examples to use one or both derives
Co-authored-by: MrGVSV <49806985+MrGVSV@users.noreply.github.com>
2022-03-29 02:10:06 +00:00
|
|
|
#[derive(Deref)]
|
2021-05-23 20:13:55 +00:00
|
|
|
struct BoxMeshHandle(Handle<Mesh>);
|
bevy_derive: Add derives for `Deref` and `DerefMut` (#4328)
# Objective
A common pattern in Rust is the [newtype](https://doc.rust-lang.org/rust-by-example/generics/new_types.html). This is an especially useful pattern in Bevy as it allows us to give common/foreign types different semantics (such as allowing it to implement `Component` or `FromWorld`) or to simply treat them as a "new type" (clever). For example, it allows us to wrap a common `Vec<String>` and do things like:
```rust
#[derive(Component)]
struct Items(Vec<String>);
fn give_sword(query: Query<&mut Items>) {
query.single_mut().0.push(String::from("Flaming Poisoning Raging Sword of Doom"));
}
```
> We could then define another struct that wraps `Vec<String>` without anything clashing in the query.
However, one of the worst parts of this pattern is the ugly `.0` we have to write in order to access the type we actually care about. This is why people often implement `Deref` and `DerefMut` in order to get around this.
Since it's such a common pattern, especially for Bevy, it makes sense to add a derive macro to automatically add those implementations.
## Solution
Added a derive macro for `Deref` and another for `DerefMut` (both exported into the prelude). This works on all structs (including tuple structs) as long as they only contain a single field:
```rust
#[derive(Deref)]
struct Foo(String);
#[derive(Deref, DerefMut)]
struct Bar {
name: String,
}
```
This allows us to then remove that pesky `.0`:
```rust
#[derive(Component, Deref, DerefMut)]
struct Items(Vec<String>);
fn give_sword(query: Query<&mut Items>) {
query.single_mut().push(String::from("Flaming Poisoning Raging Sword of Doom"));
}
```
### Alternatives
There are other alternatives to this such as by using the [`derive_more`](https://crates.io/crates/derive_more) crate. However, it doesn't seem like we need an entire crate just yet since we only need `Deref` and `DerefMut` (for now).
### Considerations
One thing to consider is that the Rust std library recommends _not_ using `Deref` and `DerefMut` for things like this: "`Deref` should only be implemented for smart pointers to avoid confusion" ([reference](https://doc.rust-lang.org/std/ops/trait.Deref.html)). Personally, I believe it makes sense to use it in the way described above, but others may disagree.
### Additional Context
Discord: https://discord.com/channels/691052431525675048/692572690833473578/956648422163746827 (controversiality discussed [here](https://discord.com/channels/691052431525675048/692572690833473578/956711911481835630))
---
## Changelog
- Add `Deref` derive macro (exported to prelude)
- Add `DerefMut` derive macro (exported to prelude)
- Updated most newtypes in examples to use one or both derives
Co-authored-by: MrGVSV <49806985+MrGVSV@users.noreply.github.com>
2022-03-29 02:10:06 +00:00
|
|
|
#[derive(Deref)]
|
2021-05-23 20:13:55 +00:00
|
|
|
struct BoxMaterialHandle(Handle<StandardMaterial>);
|
|
|
|
|
|
|
|
/// Startup system which runs only once and generates our Box Mesh
|
|
|
|
/// and Box Material assets, adds them to their respective Asset
|
|
|
|
/// Resources, and stores their handles as resources so we can access
|
|
|
|
/// them later when we're ready to render our Boxes
|
|
|
|
fn add_assets(
|
|
|
|
mut commands: Commands,
|
|
|
|
mut meshes: ResMut<Assets<Mesh>>,
|
|
|
|
mut materials: ResMut<Assets<StandardMaterial>>,
|
|
|
|
) {
|
|
|
|
let box_mesh_handle = meshes.add(Mesh::from(shape::Cube { size: 0.25 }));
|
|
|
|
commands.insert_resource(BoxMeshHandle(box_mesh_handle));
|
|
|
|
|
|
|
|
let box_material_handle = materials.add(Color::rgb(1.0, 0.2, 0.3).into());
|
|
|
|
commands.insert_resource(BoxMaterialHandle(box_material_handle));
|
|
|
|
}
|
|
|
|
|
2022-04-22 06:29:38 +00:00
|
|
|
#[derive(Component)]
|
|
|
|
struct ComputeTransform(Task<Transform>);
|
|
|
|
|
2021-05-23 20:13:55 +00:00
|
|
|
/// This system generates tasks simulating computationally intensive
|
|
|
|
/// work that potentially spans multiple frames/ticks. A separate
|
2021-12-29 17:25:34 +00:00
|
|
|
/// system, `handle_tasks`, will poll the spawned tasks on subsequent
|
2021-05-23 20:13:55 +00:00
|
|
|
/// frames/ticks, and use the results to spawn cubes
|
|
|
|
fn spawn_tasks(mut commands: Commands, thread_pool: Res<AsyncComputeTaskPool>) {
|
|
|
|
for x in 0..NUM_CUBES {
|
|
|
|
for y in 0..NUM_CUBES {
|
|
|
|
for z in 0..NUM_CUBES {
|
|
|
|
// Spawn new task on the AsyncComputeTaskPool
|
|
|
|
let task = thread_pool.spawn(async move {
|
|
|
|
let mut rng = rand::thread_rng();
|
|
|
|
let start_time = Instant::now();
|
|
|
|
let duration = Duration::from_secs_f32(rng.gen_range(0.05..0.2));
|
2022-04-26 18:42:44 +00:00
|
|
|
while start_time.elapsed() < duration {
|
2021-05-23 20:13:55 +00:00
|
|
|
// Spinning for 'duration', simulating doing hard
|
|
|
|
// compute work generating translation coords!
|
|
|
|
}
|
|
|
|
|
|
|
|
// Such hard work, all done!
|
2022-02-06 01:07:55 +00:00
|
|
|
Transform::from_xyz(x as f32, y as f32, z as f32)
|
2021-05-23 20:13:55 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
// Spawn new entity and add our new task as a component
|
2022-04-22 06:29:38 +00:00
|
|
|
commands.spawn().insert(ComputeTransform(task));
|
2021-05-23 20:13:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// This system queries for entities that have our Task<Transform> component. It polls the
|
|
|
|
/// tasks to see if they're complete. If the task is complete it takes the result, adds a
|
2021-12-29 17:25:34 +00:00
|
|
|
/// new [`PbrBundle`] of components to the entity using the result from the task's work, and
|
2021-05-23 20:13:55 +00:00
|
|
|
/// removes the task component from the entity.
|
|
|
|
fn handle_tasks(
|
|
|
|
mut commands: Commands,
|
2022-04-22 06:29:38 +00:00
|
|
|
mut transform_tasks: Query<(Entity, &mut ComputeTransform)>,
|
2021-05-23 20:13:55 +00:00
|
|
|
box_mesh_handle: Res<BoxMeshHandle>,
|
|
|
|
box_material_handle: Res<BoxMaterialHandle>,
|
|
|
|
) {
|
|
|
|
for (entity, mut task) in transform_tasks.iter_mut() {
|
2022-04-22 06:29:38 +00:00
|
|
|
if let Some(transform) = future::block_on(future::poll_once(&mut task.0)) {
|
2021-05-23 20:13:55 +00:00
|
|
|
// Add our new PbrBundle of components to our tagged entity
|
|
|
|
commands.entity(entity).insert_bundle(PbrBundle {
|
bevy_derive: Add derives for `Deref` and `DerefMut` (#4328)
# Objective
A common pattern in Rust is the [newtype](https://doc.rust-lang.org/rust-by-example/generics/new_types.html). This is an especially useful pattern in Bevy as it allows us to give common/foreign types different semantics (such as allowing it to implement `Component` or `FromWorld`) or to simply treat them as a "new type" (clever). For example, it allows us to wrap a common `Vec<String>` and do things like:
```rust
#[derive(Component)]
struct Items(Vec<String>);
fn give_sword(query: Query<&mut Items>) {
query.single_mut().0.push(String::from("Flaming Poisoning Raging Sword of Doom"));
}
```
> We could then define another struct that wraps `Vec<String>` without anything clashing in the query.
However, one of the worst parts of this pattern is the ugly `.0` we have to write in order to access the type we actually care about. This is why people often implement `Deref` and `DerefMut` in order to get around this.
Since it's such a common pattern, especially for Bevy, it makes sense to add a derive macro to automatically add those implementations.
## Solution
Added a derive macro for `Deref` and another for `DerefMut` (both exported into the prelude). This works on all structs (including tuple structs) as long as they only contain a single field:
```rust
#[derive(Deref)]
struct Foo(String);
#[derive(Deref, DerefMut)]
struct Bar {
name: String,
}
```
This allows us to then remove that pesky `.0`:
```rust
#[derive(Component, Deref, DerefMut)]
struct Items(Vec<String>);
fn give_sword(query: Query<&mut Items>) {
query.single_mut().push(String::from("Flaming Poisoning Raging Sword of Doom"));
}
```
### Alternatives
There are other alternatives to this such as by using the [`derive_more`](https://crates.io/crates/derive_more) crate. However, it doesn't seem like we need an entire crate just yet since we only need `Deref` and `DerefMut` (for now).
### Considerations
One thing to consider is that the Rust std library recommends _not_ using `Deref` and `DerefMut` for things like this: "`Deref` should only be implemented for smart pointers to avoid confusion" ([reference](https://doc.rust-lang.org/std/ops/trait.Deref.html)). Personally, I believe it makes sense to use it in the way described above, but others may disagree.
### Additional Context
Discord: https://discord.com/channels/691052431525675048/692572690833473578/956648422163746827 (controversiality discussed [here](https://discord.com/channels/691052431525675048/692572690833473578/956711911481835630))
---
## Changelog
- Add `Deref` derive macro (exported to prelude)
- Add `DerefMut` derive macro (exported to prelude)
- Updated most newtypes in examples to use one or both derives
Co-authored-by: MrGVSV <49806985+MrGVSV@users.noreply.github.com>
2022-03-29 02:10:06 +00:00
|
|
|
mesh: box_mesh_handle.clone(),
|
|
|
|
material: box_material_handle.clone(),
|
2021-05-23 20:13:55 +00:00
|
|
|
transform,
|
2022-03-01 20:52:09 +00:00
|
|
|
..default()
|
2021-05-23 20:13:55 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
// Task is complete, so remove task component from entity
|
2022-04-22 06:29:38 +00:00
|
|
|
commands.entity(entity).remove::<ComputeTransform>();
|
2021-05-23 20:13:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// This system is only used to setup light and camera for the environment
|
|
|
|
fn setup_env(mut commands: Commands) {
|
|
|
|
// Used to center camera on spawned cubes
|
|
|
|
let offset = if NUM_CUBES % 2 == 0 {
|
|
|
|
(NUM_CUBES / 2) as f32 - 0.5
|
|
|
|
} else {
|
|
|
|
(NUM_CUBES / 2) as f32
|
|
|
|
};
|
|
|
|
|
|
|
|
// lights
|
|
|
|
commands.spawn_bundle(PointLightBundle {
|
2022-02-06 01:07:55 +00:00
|
|
|
transform: Transform::from_xyz(4.0, 12.0, 15.0),
|
2022-03-01 20:52:09 +00:00
|
|
|
..default()
|
2021-05-23 20:13:55 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
// camera
|
|
|
|
commands.spawn_bundle(PerspectiveCameraBundle {
|
2022-02-06 01:07:55 +00:00
|
|
|
transform: Transform::from_xyz(offset, offset, 15.0)
|
2021-05-23 20:13:55 +00:00
|
|
|
.looking_at(Vec3::new(offset, offset, 0.0), Vec3::Y),
|
2022-03-01 20:52:09 +00:00
|
|
|
..default()
|
2021-05-23 20:13:55 +00:00
|
|
|
});
|
|
|
|
}
|