bevy/examples/camera/first_person_view_model.rs
Joona Aalto 54006b107b
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

280 lines
11 KiB
Rust

//! This example showcases a 3D first-person camera.
//!
//! The setup presented here is a very common way of organizing a first-person game
//! where the player can see their own arms. We use two industry terms to differentiate
//! the kinds of models we have:
//!
//! - The *view model* is the model that represents the player's body.
//! - The *world model* is everything else.
//!
//! ## Motivation
//!
//! The reason for this distinction is that these two models should be rendered with different field of views (FOV).
//! The view model is typically designed and animated with a very specific FOV in mind, so it is
//! generally *fixed* and cannot be changed by a player. The world model, on the other hand, should
//! be able to change its FOV to accommodate the player's preferences for the following reasons:
//! - *Accessibility*: How prone is the player to motion sickness? A wider FOV can help.
//! - *Tactical preference*: Does the player want to see more of the battlefield?
//! Or have a more zoomed-in view for precision aiming?
//! - *Physical considerations*: How well does the in-game FOV match the player's real-world FOV?
//! Are they sitting in front of a monitor or playing on a TV in the living room? How big is the screen?
//!
//! ## Implementation
//!
//! The `Player` is an entity holding two cameras, one for each model. The view model camera has a fixed
//! FOV of 70 degrees, while the world model camera has a variable FOV that can be changed by the player.
//!
//! We use different `RenderLayers` to select what to render.
//!
//! - The world model camera has no explicit `RenderLayers` component, so it uses the layer 0.
//! All static objects in the scene are also on layer 0 for the same reason.
//! - The view model camera has a `RenderLayers` component with layer 1, so it only renders objects
//! explicitly assigned to layer 1. The arm of the player is one such object.
//! The order of the view model camera is additionally bumped to 1 to ensure it renders on top of the world model.
//! - The light source in the scene must illuminate both the view model and the world model, so it is
//! assigned to both layers 0 and 1.
//!
//! ## Controls
//!
//! | Key Binding | Action |
//! |:---------------------|:--------------|
//! | mouse | Look around |
//! | arrow up | Decrease FOV |
//! | arrow down | Increase FOV |
use std::f32::consts::FRAC_PI_2;
use bevy::{
color::palettes::tailwind, input::mouse::AccumulatedMouseMotion, pbr::NotShadowCaster,
prelude::*, render::view::RenderLayers,
};
fn main() {
App::new()
.add_plugins(DefaultPlugins)
.add_systems(
Startup,
(
spawn_view_model,
spawn_world_model,
spawn_lights,
spawn_text,
),
)
.add_systems(Update, (move_player, change_fov))
.run();
}
#[derive(Debug, Component)]
struct Player;
#[derive(Debug, Component, Deref, DerefMut)]
struct CameraSensitivity(Vec2);
impl Default for CameraSensitivity {
fn default() -> Self {
Self(
// These factors are just arbitrary mouse sensitivity values.
// It's often nicer to have a faster horizontal sensitivity than vertical.
// We use a component for them so that we can make them user-configurable at runtime
// for accessibility reasons.
// It also allows you to inspect them in an editor if you `Reflect` the component.
Vec2::new(0.003, 0.002),
)
}
}
#[derive(Debug, Component)]
struct WorldModelCamera;
/// Used implicitly by all entities without a `RenderLayers` component.
/// Our world model camera and all objects other than the player are on this layer.
/// The light source belongs to both layers.
const DEFAULT_RENDER_LAYER: usize = 0;
/// Used by the view model camera and the player's arm.
/// The light source belongs to both layers.
const VIEW_MODEL_RENDER_LAYER: usize = 1;
fn spawn_view_model(
mut commands: Commands,
mut meshes: ResMut<Assets<Mesh>>,
mut materials: ResMut<Assets<StandardMaterial>>,
) {
let arm = meshes.add(Cuboid::new(0.1, 0.1, 0.5));
let arm_material = materials.add(Color::from(tailwind::TEAL_200));
commands
.spawn((
Player,
CameraSensitivity::default(),
SpatialBundle {
transform: Transform::from_xyz(0.0, 1.0, 0.0),
..default()
},
))
.with_children(|parent| {
parent.spawn((
WorldModelCamera,
Camera3dBundle {
projection: PerspectiveProjection {
fov: 90.0_f32.to_radians(),
..default()
}
.into(),
..default()
},
));
// Spawn view model camera.
parent.spawn((
Camera3dBundle {
camera: Camera {
// Bump the order to render on top of the world model.
order: 1,
..default()
},
projection: PerspectiveProjection {
fov: 70.0_f32.to_radians(),
..default()
}
.into(),
..default()
},
// Only render objects belonging to the view model.
RenderLayers::layer(VIEW_MODEL_RENDER_LAYER),
));
// Spawn the player's right arm.
parent.spawn((
Mesh3d(arm),
MeshMaterial3d(arm_material),
Transform::from_xyz(0.2, -0.1, -0.25),
// Ensure the arm is only rendered by the view model camera.
RenderLayers::layer(VIEW_MODEL_RENDER_LAYER),
// The arm is free-floating, so shadows would look weird.
NotShadowCaster,
));
});
}
fn spawn_world_model(
mut commands: Commands,
mut meshes: ResMut<Assets<Mesh>>,
mut materials: ResMut<Assets<StandardMaterial>>,
) {
let floor = meshes.add(Plane3d::new(Vec3::Y, Vec2::splat(10.0)));
let cube = meshes.add(Cuboid::new(2.0, 0.5, 1.0));
let material = materials.add(Color::WHITE);
// The world model camera will render the floor and the cubes spawned in this system.
// Assigning no `RenderLayers` component defaults to layer 0.
commands.spawn((Mesh3d(floor), MeshMaterial3d(material.clone())));
commands.spawn((
Mesh3d(cube.clone()),
MeshMaterial3d(material.clone()),
Transform::from_xyz(0.0, 0.25, -3.0),
));
commands.spawn((
Mesh3d(cube),
MeshMaterial3d(material),
Transform::from_xyz(0.75, 1.75, 0.0),
));
}
fn spawn_lights(mut commands: Commands) {
commands.spawn((
PointLight {
color: Color::from(tailwind::ROSE_300),
shadows_enabled: true,
..default()
},
Transform::from_xyz(-2.0, 4.0, -0.75),
// The light source illuminates both the world model and the view model.
RenderLayers::from_layers(&[DEFAULT_RENDER_LAYER, VIEW_MODEL_RENDER_LAYER]),
));
}
fn spawn_text(mut commands: Commands) {
commands
.spawn(NodeBundle {
style: Style {
position_type: PositionType::Absolute,
bottom: Val::Px(12.0),
left: Val::Px(12.0),
..default()
},
..default()
})
.with_children(|parent| {
parent.spawn(TextBundle::from_section(
concat!(
"Move the camera with your mouse.\n",
"Press arrow up to decrease the FOV of the world model.\n",
"Press arrow down to increase the FOV of the world model."
),
TextStyle::default(),
));
});
}
fn move_player(
accumulated_mouse_motion: Res<AccumulatedMouseMotion>,
mut player: Query<(&mut Transform, &CameraSensitivity), With<Player>>,
) {
let Ok((mut transform, camera_sensitivity)) = player.get_single_mut() else {
return;
};
let delta = accumulated_mouse_motion.delta;
if delta != Vec2::ZERO {
// Note that we are not multiplying by delta_time here.
// The reason is that for mouse movement, we already get the full movement that happened since the last frame.
// This means that if we multiply by delta_time, we will get a smaller rotation than intended by the user.
// This situation is reversed when reading e.g. analog input from a gamepad however, where the same rules
// as for keyboard input apply. Such an input should be multiplied by delta_time to get the intended rotation
// independent of the framerate.
let delta_yaw = -delta.x * camera_sensitivity.x;
let delta_pitch = -delta.y * camera_sensitivity.y;
let (yaw, pitch, roll) = transform.rotation.to_euler(EulerRot::YXZ);
let yaw = yaw + delta_yaw;
// If the pitch was ±¹⁄₂ π, the camera would look straight up or down.
// When the user wants to move the camera back to the horizon, which way should the camera face?
// The camera has no way of knowing what direction was "forward" before landing in that extreme position,
// so the direction picked will for all intents and purposes be arbitrary.
// Another issue is that for mathematical reasons, the yaw will effectively be flipped when the pitch is at the extremes.
// To not run into these issues, we clamp the pitch to a safe range.
const PITCH_LIMIT: f32 = FRAC_PI_2 - 0.01;
let pitch = (pitch + delta_pitch).clamp(-PITCH_LIMIT, PITCH_LIMIT);
transform.rotation = Quat::from_euler(EulerRot::YXZ, yaw, pitch, roll);
}
}
fn change_fov(
input: Res<ButtonInput<KeyCode>>,
mut world_model_projection: Query<&mut Projection, With<WorldModelCamera>>,
) {
let Ok(mut projection) = world_model_projection.get_single_mut() else {
return;
};
let Projection::Perspective(ref mut perspective) = projection.as_mut() else {
unreachable!(
"The `Projection` component was explicitly built with `Projection::Perspective`"
);
};
if input.pressed(KeyCode::ArrowUp) {
perspective.fov -= 1.0_f32.to_radians();
perspective.fov = perspective.fov.max(20.0_f32.to_radians());
}
if input.pressed(KeyCode::ArrowDown) {
perspective.fov += 1.0_f32.to_radians();
perspective.fov = perspective.fov.min(160.0_f32.to_radians());
}
}