mirror of
https://github.com/bevyengine/bevy
synced 2024-11-26 06:30:19 +00:00
54006b107b
# 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>
280 lines
11 KiB
Rust
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());
|
|
}
|
|
}
|