2024-09-22 01:18:40 +00:00
|
|
|
//! Shows how to modify mesh assets after spawning.
|
|
|
|
|
|
|
|
use bevy::{
|
2024-09-24 11:42:59 +00:00
|
|
|
gltf::GltfLoaderSettings,
|
|
|
|
input::common_conditions::input_just_pressed,
|
|
|
|
prelude::*,
|
|
|
|
render::{mesh::VertexAttributeValues, render_asset::RenderAssetUsages},
|
2024-09-22 01:18:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
App::new()
|
|
|
|
.add_plugins(DefaultPlugins)
|
|
|
|
.add_systems(Startup, (setup, spawn_text))
|
|
|
|
.add_systems(
|
|
|
|
Update,
|
|
|
|
alter_handle.run_if(input_just_pressed(KeyCode::Space)),
|
|
|
|
)
|
|
|
|
.add_systems(
|
|
|
|
Update,
|
|
|
|
alter_mesh.run_if(input_just_pressed(KeyCode::Enter)),
|
|
|
|
)
|
|
|
|
.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Component, Debug)]
|
|
|
|
enum Shape {
|
|
|
|
Cube,
|
|
|
|
Sphere,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Shape {
|
|
|
|
fn get_model_path(&self) -> String {
|
|
|
|
match self {
|
|
|
|
Shape::Cube => "models/cube/cube.gltf".into(),
|
|
|
|
Shape::Sphere => "models/sphere/sphere.gltf".into(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn set_next_variant(&mut self) {
|
|
|
|
*self = match self {
|
|
|
|
Shape::Cube => Shape::Sphere,
|
|
|
|
Shape::Sphere => Shape::Cube,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Component, Debug)]
|
|
|
|
struct Left;
|
|
|
|
|
|
|
|
fn setup(
|
|
|
|
mut commands: Commands,
|
|
|
|
asset_server: Res<AssetServer>,
|
|
|
|
mut materials: ResMut<Assets<StandardMaterial>>,
|
|
|
|
) {
|
|
|
|
let left_shape = Shape::Cube;
|
|
|
|
let right_shape = Shape::Cube;
|
|
|
|
|
|
|
|
// In normal use, you can call `asset_server.load`, however see below for an explanation of
|
|
|
|
// `RenderAssetUsages`.
|
|
|
|
let left_shape_model = asset_server.load_with_settings(
|
|
|
|
GltfAssetLabel::Primitive {
|
|
|
|
mesh: 0,
|
|
|
|
// This field stores an index to this primitive in its parent mesh. In this case, we
|
|
|
|
// want the first one. You might also have seen the syntax:
|
|
|
|
//
|
|
|
|
// models/cube/cube.gltf#Scene0
|
|
|
|
//
|
|
|
|
// which accomplishes the same thing.
|
|
|
|
primitive: 0,
|
|
|
|
}
|
|
|
|
.from_asset(left_shape.get_model_path()),
|
|
|
|
// `RenderAssetUsages::all()` is already the default, so the line below could be omitted.
|
|
|
|
// It's helpful to know it exists, however.
|
|
|
|
//
|
|
|
|
// `RenderAssetUsages` tell Bevy whether to keep the data around:
|
|
|
|
// - for the GPU (`RenderAssetUsages::RENDER_WORLD`),
|
|
|
|
// - for the CPU (`RenderAssetUsages::MAIN_WORLD`),
|
|
|
|
// - or both.
|
|
|
|
// `RENDER_WORLD` is necessary to render the mesh, `MAIN_WORLD` is necessary to inspect
|
|
|
|
// and modify the mesh (via `ResMut<Assets<Mesh>>`).
|
|
|
|
//
|
|
|
|
// Since most games will not need to modify meshes at runtime, many developers opt to pass
|
|
|
|
// only `RENDER_WORLD`. This is more memory efficient, as we don't need to keep the mesh in
|
|
|
|
// RAM. For this example however, this would not work, as we need to inspect and modify the
|
|
|
|
// mesh at runtime.
|
|
|
|
|settings: &mut GltfLoaderSettings| settings.load_meshes = RenderAssetUsages::all(),
|
|
|
|
);
|
|
|
|
|
|
|
|
// Here, we rely on the default loader settings to achieve a similar result to the above.
|
|
|
|
let right_shape_model = asset_server.load(
|
|
|
|
GltfAssetLabel::Primitive {
|
|
|
|
mesh: 0,
|
|
|
|
primitive: 0,
|
|
|
|
}
|
|
|
|
.from_asset(right_shape.get_model_path()),
|
|
|
|
);
|
|
|
|
|
|
|
|
// Add a material asset directly to the materials storage
|
|
|
|
let material_handle = materials.add(StandardMaterial {
|
|
|
|
base_color: Color::srgb(0.6, 0.8, 0.6),
|
|
|
|
..default()
|
|
|
|
});
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Left,
|
|
|
|
Name::new("Left Shape"),
|
Migrate meshes and materials to required components (#15524)
# Objective
A big step in the migration to required components: meshes and
materials!
## Solution
As per the [selected
proposal](https://hackmd.io/@bevy/required_components/%2Fj9-PnF-2QKK0on1KQ29UWQ):
- Deprecate `MaterialMesh2dBundle`, `MaterialMeshBundle`, and
`PbrBundle`.
- Add `Mesh2d` and `Mesh3d` components, which wrap a `Handle<Mesh>`.
- Add `MeshMaterial2d<M: Material2d>` and `MeshMaterial3d<M: Material>`,
which wrap a `Handle<M>`.
- Meshes *without* a mesh material should be rendered with a default
material. The existence of a material is determined by
`HasMaterial2d`/`HasMaterial3d`, which is required by
`MeshMaterial2d`/`MeshMaterial3d`. This gets around problems with the
generics.
Previously:
```rust
commands.spawn(MaterialMesh2dBundle {
mesh: meshes.add(Circle::new(100.0)).into(),
material: materials.add(Color::srgb(7.5, 0.0, 7.5)),
transform: Transform::from_translation(Vec3::new(-200., 0., 0.)),
..default()
});
```
Now:
```rust
commands.spawn((
Mesh2d(meshes.add(Circle::new(100.0))),
MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))),
Transform::from_translation(Vec3::new(-200., 0., 0.)),
));
```
If the mesh material is missing, previously nothing was rendered. Now,
it renders a white default `ColorMaterial` in 2D and a
`StandardMaterial` in 3D (this can be overridden). Below, only every
other entity has a material:
![Näyttökuva 2024-09-29
181746](https://github.com/user-attachments/assets/5c8be029-d2fe-4b8c-ae89-17a72ff82c9a)
![Näyttökuva 2024-09-29
181918](https://github.com/user-attachments/assets/58adbc55-5a1e-4c7d-a2c7-ed456227b909)
Why white? This is still open for discussion, but I think white makes
sense for a *default* material, while *invalid* asset handles pointing
to nothing should have something like a pink material to indicate that
something is broken (I don't handle that in this PR yet). This is kind
of a mix of Godot and Unity: Godot just renders a white material for
non-existent materials, while Unity renders nothing when no materials
exist, but renders pink for invalid materials. I can also change the
default material to pink if that is preferable though.
## Testing
I ran some 2D and 3D examples to test if anything changed visually. I
have not tested all examples or features yet however. If anyone wants to
test more extensively, it would be appreciated!
## Implementation Notes
- The relationship between `bevy_render` and `bevy_pbr` is weird here.
`bevy_render` needs `Mesh3d` for its own systems, but `bevy_pbr` has all
of the material logic, and `bevy_render` doesn't depend on it. I feel
like the two crates should be refactored in some way, but I think that's
out of scope for this PR.
- I didn't migrate meshlets to required components yet. That can
probably be done in a follow-up, as this is already a huge PR.
- It is becoming increasingly clear to me that we really, *really* want
to disallow raw asset handles as components. They caused me a *ton* of
headache here already, and it took me a long time to find every place
that queried for them or inserted them directly on entities, since there
were no compiler errors for it. If we don't remove the `Component`
derive, I expect raw asset handles to be a *huge* footgun for users as
we transition to wrapper components, especially as handles as components
have been the norm so far. I personally consider this to be a blocker
for 0.15: we need to migrate to wrapper components for asset handles
everywhere, and remove the `Component` derive. Also see
https://github.com/bevyengine/bevy/issues/14124.
---
## Migration Guide
Asset handles for meshes and mesh materials must now be wrapped in the
`Mesh2d` and `MeshMaterial2d` or `Mesh3d` and `MeshMaterial3d`
components for 2D and 3D respectively. Raw handles as components no
longer render meshes.
Additionally, `MaterialMesh2dBundle`, `MaterialMeshBundle`, and
`PbrBundle` have been deprecated. Instead, use the mesh and material
components directly.
Previously:
```rust
commands.spawn(MaterialMesh2dBundle {
mesh: meshes.add(Circle::new(100.0)).into(),
material: materials.add(Color::srgb(7.5, 0.0, 7.5)),
transform: Transform::from_translation(Vec3::new(-200., 0., 0.)),
..default()
});
```
Now:
```rust
commands.spawn((
Mesh2d(meshes.add(Circle::new(100.0))),
MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))),
Transform::from_translation(Vec3::new(-200., 0., 0.)),
));
```
If the mesh material is missing, a white default material is now used.
Previously, nothing was rendered if the material was missing.
The `WithMesh2d` and `WithMesh3d` query filter type aliases have also
been removed. Simply use `With<Mesh2d>` or `With<Mesh3d>`.
---------
Co-authored-by: Tim Blackbird <justthecooldude@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2024-10-01 21:33:17 +00:00
|
|
|
Mesh3d(left_shape_model),
|
|
|
|
MeshMaterial3d(material_handle.clone()),
|
|
|
|
Transform::from_xyz(-3.0, 0.0, 0.0),
|
2024-09-22 01:18:40 +00:00
|
|
|
left_shape,
|
|
|
|
));
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Right Shape"),
|
Migrate meshes and materials to required components (#15524)
# Objective
A big step in the migration to required components: meshes and
materials!
## Solution
As per the [selected
proposal](https://hackmd.io/@bevy/required_components/%2Fj9-PnF-2QKK0on1KQ29UWQ):
- Deprecate `MaterialMesh2dBundle`, `MaterialMeshBundle`, and
`PbrBundle`.
- Add `Mesh2d` and `Mesh3d` components, which wrap a `Handle<Mesh>`.
- Add `MeshMaterial2d<M: Material2d>` and `MeshMaterial3d<M: Material>`,
which wrap a `Handle<M>`.
- Meshes *without* a mesh material should be rendered with a default
material. The existence of a material is determined by
`HasMaterial2d`/`HasMaterial3d`, which is required by
`MeshMaterial2d`/`MeshMaterial3d`. This gets around problems with the
generics.
Previously:
```rust
commands.spawn(MaterialMesh2dBundle {
mesh: meshes.add(Circle::new(100.0)).into(),
material: materials.add(Color::srgb(7.5, 0.0, 7.5)),
transform: Transform::from_translation(Vec3::new(-200., 0., 0.)),
..default()
});
```
Now:
```rust
commands.spawn((
Mesh2d(meshes.add(Circle::new(100.0))),
MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))),
Transform::from_translation(Vec3::new(-200., 0., 0.)),
));
```
If the mesh material is missing, previously nothing was rendered. Now,
it renders a white default `ColorMaterial` in 2D and a
`StandardMaterial` in 3D (this can be overridden). Below, only every
other entity has a material:
![Näyttökuva 2024-09-29
181746](https://github.com/user-attachments/assets/5c8be029-d2fe-4b8c-ae89-17a72ff82c9a)
![Näyttökuva 2024-09-29
181918](https://github.com/user-attachments/assets/58adbc55-5a1e-4c7d-a2c7-ed456227b909)
Why white? This is still open for discussion, but I think white makes
sense for a *default* material, while *invalid* asset handles pointing
to nothing should have something like a pink material to indicate that
something is broken (I don't handle that in this PR yet). This is kind
of a mix of Godot and Unity: Godot just renders a white material for
non-existent materials, while Unity renders nothing when no materials
exist, but renders pink for invalid materials. I can also change the
default material to pink if that is preferable though.
## Testing
I ran some 2D and 3D examples to test if anything changed visually. I
have not tested all examples or features yet however. If anyone wants to
test more extensively, it would be appreciated!
## Implementation Notes
- The relationship between `bevy_render` and `bevy_pbr` is weird here.
`bevy_render` needs `Mesh3d` for its own systems, but `bevy_pbr` has all
of the material logic, and `bevy_render` doesn't depend on it. I feel
like the two crates should be refactored in some way, but I think that's
out of scope for this PR.
- I didn't migrate meshlets to required components yet. That can
probably be done in a follow-up, as this is already a huge PR.
- It is becoming increasingly clear to me that we really, *really* want
to disallow raw asset handles as components. They caused me a *ton* of
headache here already, and it took me a long time to find every place
that queried for them or inserted them directly on entities, since there
were no compiler errors for it. If we don't remove the `Component`
derive, I expect raw asset handles to be a *huge* footgun for users as
we transition to wrapper components, especially as handles as components
have been the norm so far. I personally consider this to be a blocker
for 0.15: we need to migrate to wrapper components for asset handles
everywhere, and remove the `Component` derive. Also see
https://github.com/bevyengine/bevy/issues/14124.
---
## Migration Guide
Asset handles for meshes and mesh materials must now be wrapped in the
`Mesh2d` and `MeshMaterial2d` or `Mesh3d` and `MeshMaterial3d`
components for 2D and 3D respectively. Raw handles as components no
longer render meshes.
Additionally, `MaterialMesh2dBundle`, `MaterialMeshBundle`, and
`PbrBundle` have been deprecated. Instead, use the mesh and material
components directly.
Previously:
```rust
commands.spawn(MaterialMesh2dBundle {
mesh: meshes.add(Circle::new(100.0)).into(),
material: materials.add(Color::srgb(7.5, 0.0, 7.5)),
transform: Transform::from_translation(Vec3::new(-200., 0., 0.)),
..default()
});
```
Now:
```rust
commands.spawn((
Mesh2d(meshes.add(Circle::new(100.0))),
MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))),
Transform::from_translation(Vec3::new(-200., 0., 0.)),
));
```
If the mesh material is missing, a white default material is now used.
Previously, nothing was rendered if the material was missing.
The `WithMesh2d` and `WithMesh3d` query filter type aliases have also
been removed. Simply use `With<Mesh2d>` or `With<Mesh3d>`.
---------
Co-authored-by: Tim Blackbird <justthecooldude@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2024-10-01 21:33:17 +00:00
|
|
|
Mesh3d(right_shape_model),
|
|
|
|
MeshMaterial3d(material_handle),
|
|
|
|
Transform::from_xyz(3.0, 0.0, 0.0),
|
2024-09-22 01:18:40 +00:00
|
|
|
right_shape,
|
|
|
|
));
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Point Light"),
|
2024-10-01 03:20:43 +00:00
|
|
|
PointLight::default(),
|
|
|
|
Transform::from_xyz(4.0, 5.0, 4.0),
|
2024-09-22 01:18:40 +00:00
|
|
|
));
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Camera"),
|
2024-10-05 01:59:52 +00:00
|
|
|
Camera3d::default(),
|
|
|
|
Transform::from_xyz(0.0, 3.0, 20.0).looking_at(Vec3::ZERO, Vec3::Y),
|
2024-09-22 01:18:40 +00:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
fn spawn_text(mut commands: Commands) {
|
2024-10-17 01:01:32 +00:00
|
|
|
commands.spawn((
|
|
|
|
Name::new("Instructions"),
|
|
|
|
Text::new(
|
|
|
|
"Space: swap meshes by mutating a Handle<Mesh>\n\
|
|
|
|
Return: mutate the mesh itself, changing all copies of it",
|
|
|
|
),
|
Merge Style properties into Node. Use ComputedNode for computed properties. (#15975)
# Objective
Continue improving the user experience of our UI Node API in the
direction specified by [Bevy's Next Generation Scene / UI
System](https://github.com/bevyengine/bevy/discussions/14437)
## Solution
As specified in the document above, merge `Style` fields into `Node`,
and move "computed Node fields" into `ComputedNode` (I chose this name
over something like `ComputedNodeLayout` because it currently contains
more than just layout info. If we want to break this up / rename these
concepts, lets do that in a separate PR). `Style` has been removed.
This accomplishes a number of goals:
## Ergonomics wins
Specifying both `Node` and `Style` is now no longer required for
non-default styles
Before:
```rust
commands.spawn((
Node::default(),
Style {
width: Val::Px(100.),
..default()
},
));
```
After:
```rust
commands.spawn(Node {
width: Val::Px(100.),
..default()
});
```
## Conceptual clarity
`Style` was never a comprehensive "style sheet". It only defined "core"
style properties that all `Nodes` shared. Any "styled property" that
couldn't fit that mold had to be in a separate component. A "real" style
system would style properties _across_ components (`Node`, `Button`,
etc). We have plans to build a true style system (see the doc linked
above).
By moving the `Style` fields to `Node`, we fully embrace `Node` as the
driving concept and remove the "style system" confusion.
## Next Steps
* Consider identifying and splitting out "style properties that aren't
core to Node". This should not happen for Bevy 0.15.
---
## Migration Guide
Move any fields set on `Style` into `Node` and replace all `Style`
component usage with `Node`.
Before:
```rust
commands.spawn((
Node::default(),
Style {
width: Val::Px(100.),
..default()
},
));
```
After:
```rust
commands.spawn(Node {
width: Val::Px(100.),
..default()
});
```
For any usage of the "computed node properties" that used to live on
`Node`, use `ComputedNode` instead:
Before:
```rust
fn system(nodes: Query<&Node>) {
for node in &nodes {
let computed_size = node.size();
}
}
```
After:
```rust
fn system(computed_nodes: Query<&ComputedNode>) {
for computed_node in &computed_nodes {
let computed_size = computed_node.size();
}
}
```
2024-10-18 22:25:33 +00:00
|
|
|
Node {
|
2024-10-17 01:01:32 +00:00
|
|
|
position_type: PositionType::Absolute,
|
|
|
|
top: Val::Px(12.),
|
|
|
|
left: Val::Px(12.),
|
|
|
|
..default()
|
|
|
|
},
|
|
|
|
));
|
2024-09-22 01:18:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn alter_handle(
|
|
|
|
asset_server: Res<AssetServer>,
|
2024-11-01 18:25:42 +00:00
|
|
|
right_shape: Single<(&mut Mesh3d, &mut Shape), Without<Left>>,
|
2024-09-22 01:18:40 +00:00
|
|
|
) {
|
|
|
|
// Mesh handles, like other parts of the ECS, can be queried as mutable and modified at
|
|
|
|
// runtime. We only spawned one shape without the `Left` marker component.
|
2024-11-01 18:25:42 +00:00
|
|
|
let (mut mesh, mut shape) = right_shape.into_inner();
|
2024-09-22 01:18:40 +00:00
|
|
|
|
|
|
|
// Switch to a new Shape variant
|
|
|
|
shape.set_next_variant();
|
|
|
|
|
|
|
|
// Modify the handle associated with the Shape on the right side. Note that we will only
|
|
|
|
// have to load the same path from storage media once: repeated attempts will re-use the
|
|
|
|
// asset.
|
Migrate meshes and materials to required components (#15524)
# Objective
A big step in the migration to required components: meshes and
materials!
## Solution
As per the [selected
proposal](https://hackmd.io/@bevy/required_components/%2Fj9-PnF-2QKK0on1KQ29UWQ):
- Deprecate `MaterialMesh2dBundle`, `MaterialMeshBundle`, and
`PbrBundle`.
- Add `Mesh2d` and `Mesh3d` components, which wrap a `Handle<Mesh>`.
- Add `MeshMaterial2d<M: Material2d>` and `MeshMaterial3d<M: Material>`,
which wrap a `Handle<M>`.
- Meshes *without* a mesh material should be rendered with a default
material. The existence of a material is determined by
`HasMaterial2d`/`HasMaterial3d`, which is required by
`MeshMaterial2d`/`MeshMaterial3d`. This gets around problems with the
generics.
Previously:
```rust
commands.spawn(MaterialMesh2dBundle {
mesh: meshes.add(Circle::new(100.0)).into(),
material: materials.add(Color::srgb(7.5, 0.0, 7.5)),
transform: Transform::from_translation(Vec3::new(-200., 0., 0.)),
..default()
});
```
Now:
```rust
commands.spawn((
Mesh2d(meshes.add(Circle::new(100.0))),
MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))),
Transform::from_translation(Vec3::new(-200., 0., 0.)),
));
```
If the mesh material is missing, previously nothing was rendered. Now,
it renders a white default `ColorMaterial` in 2D and a
`StandardMaterial` in 3D (this can be overridden). Below, only every
other entity has a material:
![Näyttökuva 2024-09-29
181746](https://github.com/user-attachments/assets/5c8be029-d2fe-4b8c-ae89-17a72ff82c9a)
![Näyttökuva 2024-09-29
181918](https://github.com/user-attachments/assets/58adbc55-5a1e-4c7d-a2c7-ed456227b909)
Why white? This is still open for discussion, but I think white makes
sense for a *default* material, while *invalid* asset handles pointing
to nothing should have something like a pink material to indicate that
something is broken (I don't handle that in this PR yet). This is kind
of a mix of Godot and Unity: Godot just renders a white material for
non-existent materials, while Unity renders nothing when no materials
exist, but renders pink for invalid materials. I can also change the
default material to pink if that is preferable though.
## Testing
I ran some 2D and 3D examples to test if anything changed visually. I
have not tested all examples or features yet however. If anyone wants to
test more extensively, it would be appreciated!
## Implementation Notes
- The relationship between `bevy_render` and `bevy_pbr` is weird here.
`bevy_render` needs `Mesh3d` for its own systems, but `bevy_pbr` has all
of the material logic, and `bevy_render` doesn't depend on it. I feel
like the two crates should be refactored in some way, but I think that's
out of scope for this PR.
- I didn't migrate meshlets to required components yet. That can
probably be done in a follow-up, as this is already a huge PR.
- It is becoming increasingly clear to me that we really, *really* want
to disallow raw asset handles as components. They caused me a *ton* of
headache here already, and it took me a long time to find every place
that queried for them or inserted them directly on entities, since there
were no compiler errors for it. If we don't remove the `Component`
derive, I expect raw asset handles to be a *huge* footgun for users as
we transition to wrapper components, especially as handles as components
have been the norm so far. I personally consider this to be a blocker
for 0.15: we need to migrate to wrapper components for asset handles
everywhere, and remove the `Component` derive. Also see
https://github.com/bevyengine/bevy/issues/14124.
---
## Migration Guide
Asset handles for meshes and mesh materials must now be wrapped in the
`Mesh2d` and `MeshMaterial2d` or `Mesh3d` and `MeshMaterial3d`
components for 2D and 3D respectively. Raw handles as components no
longer render meshes.
Additionally, `MaterialMesh2dBundle`, `MaterialMeshBundle`, and
`PbrBundle` have been deprecated. Instead, use the mesh and material
components directly.
Previously:
```rust
commands.spawn(MaterialMesh2dBundle {
mesh: meshes.add(Circle::new(100.0)).into(),
material: materials.add(Color::srgb(7.5, 0.0, 7.5)),
transform: Transform::from_translation(Vec3::new(-200., 0., 0.)),
..default()
});
```
Now:
```rust
commands.spawn((
Mesh2d(meshes.add(Circle::new(100.0))),
MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))),
Transform::from_translation(Vec3::new(-200., 0., 0.)),
));
```
If the mesh material is missing, a white default material is now used.
Previously, nothing was rendered if the material was missing.
The `WithMesh2d` and `WithMesh3d` query filter type aliases have also
been removed. Simply use `With<Mesh2d>` or `With<Mesh3d>`.
---------
Co-authored-by: Tim Blackbird <justthecooldude@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2024-10-01 21:33:17 +00:00
|
|
|
mesh.0 = asset_server.load(
|
2024-09-22 01:18:40 +00:00
|
|
|
GltfAssetLabel::Primitive {
|
|
|
|
mesh: 0,
|
|
|
|
primitive: 0,
|
|
|
|
}
|
|
|
|
.from_asset(shape.get_model_path()),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn alter_mesh(
|
|
|
|
mut is_mesh_scaled: Local<bool>,
|
2024-11-01 18:25:42 +00:00
|
|
|
left_shape: Single<&Mesh3d, With<Left>>,
|
2024-09-22 01:18:40 +00:00
|
|
|
mut meshes: ResMut<Assets<Mesh>>,
|
|
|
|
) {
|
|
|
|
// Obtain a mutable reference to the Mesh asset.
|
2024-11-01 18:25:42 +00:00
|
|
|
let Some(mesh) = meshes.get_mut(*left_shape) else {
|
2024-09-22 01:18:40 +00:00
|
|
|
return;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Now we can directly manipulate vertices on the mesh. Here, we're just scaling in and out
|
|
|
|
// for demonstration purposes. This will affect all entities currently using the asset.
|
|
|
|
//
|
|
|
|
// To do this, we need to grab the stored attributes of each vertex. `Float32x3` just describes
|
|
|
|
// the format in which the attributes will be read: each position consists of an array of three
|
|
|
|
// f32 corresponding to x, y, and z.
|
|
|
|
//
|
|
|
|
// `ATTRIBUTE_POSITION` is a constant indicating that we want to know where the vertex is
|
|
|
|
// located in space (as opposed to which way its normal is facing, vertex color, or other
|
|
|
|
// details).
|
|
|
|
if let Some(VertexAttributeValues::Float32x3(positions)) =
|
|
|
|
mesh.attribute_mut(Mesh::ATTRIBUTE_POSITION)
|
|
|
|
{
|
|
|
|
// Check a Local value (which only this system can make use of) to determine if we're
|
|
|
|
// currently scaled up or not.
|
|
|
|
let scale_factor = if *is_mesh_scaled { 0.5 } else { 2.0 };
|
|
|
|
|
|
|
|
for position in positions.iter_mut() {
|
|
|
|
// Apply the scale factor to each of x, y, and z.
|
|
|
|
position[0] *= scale_factor;
|
|
|
|
position[1] *= scale_factor;
|
|
|
|
position[2] *= scale_factor;
|
|
|
|
}
|
|
|
|
|
2024-10-20 18:55:17 +00:00
|
|
|
// Flip the local value to reverse the behavior next time the key is pressed.
|
2024-09-22 01:18:40 +00:00
|
|
|
*is_mesh_scaled = !*is_mesh_scaled;
|
|
|
|
}
|
|
|
|
}
|