2024-09-10 23:40:48 +00:00
|
|
|
//! Shows how to orbit camera around a static scene using pitch, yaw, and roll.
|
2024-09-13 15:47:04 +00:00
|
|
|
//!
|
|
|
|
//! See also: `first_person_view_model` example, which does something similar but as a first-person
|
|
|
|
//! camera view.
|
2024-09-10 23:40:48 +00:00
|
|
|
|
|
|
|
use std::{f32::consts::FRAC_PI_2, ops::Range};
|
|
|
|
|
2024-09-13 15:47:04 +00:00
|
|
|
use bevy::{input::mouse::AccumulatedMouseMotion, prelude::*};
|
2024-09-10 23:40:48 +00:00
|
|
|
|
2024-09-13 15:47:04 +00:00
|
|
|
#[derive(Debug, Resource)]
|
2024-09-10 23:40:48 +00:00
|
|
|
struct CameraSettings {
|
|
|
|
pub orbit_distance: f32,
|
2024-09-13 15:47:04 +00:00
|
|
|
pub pitch_speed: f32,
|
2024-09-10 23:40:48 +00:00
|
|
|
// Clamp pitch to this range
|
|
|
|
pub pitch_range: Range<f32>,
|
2024-09-13 15:47:04 +00:00
|
|
|
pub roll_speed: f32,
|
|
|
|
pub yaw_speed: f32,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Default for CameraSettings {
|
|
|
|
fn default() -> Self {
|
|
|
|
// Limiting pitch stops some unexpected rotation past 90° up or down.
|
|
|
|
let pitch_limit = FRAC_PI_2 - 0.01;
|
|
|
|
Self {
|
|
|
|
// These values are completely arbitrary, chosen because they seem to produce
|
|
|
|
// "sensible" results for this example. Adjust as required.
|
|
|
|
orbit_distance: 20.0,
|
|
|
|
pitch_speed: 0.003,
|
|
|
|
pitch_range: -pitch_limit..pitch_limit,
|
|
|
|
roll_speed: 1.0,
|
|
|
|
yaw_speed: 0.004,
|
|
|
|
}
|
|
|
|
}
|
2024-09-10 23:40:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
App::new()
|
|
|
|
.add_plugins(DefaultPlugins)
|
|
|
|
.init_resource::<CameraSettings>()
|
|
|
|
.add_systems(Startup, (setup, instructions))
|
|
|
|
.add_systems(Update, orbit)
|
|
|
|
.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Set up a simple 3D scene
|
|
|
|
fn setup(
|
|
|
|
mut commands: Commands,
|
|
|
|
mut meshes: ResMut<Assets<Mesh>>,
|
|
|
|
mut materials: ResMut<Assets<StandardMaterial>>,
|
|
|
|
) {
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Camera"),
|
2024-10-05 01:59:52 +00:00
|
|
|
Camera3d::default(),
|
|
|
|
Transform::from_xyz(5.0, 5.0, 5.0).looking_at(Vec3::ZERO, Vec3::Y),
|
2024-09-10 23:40:48 +00:00
|
|
|
));
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Plane"),
|
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(meshes.add(Plane3d::default().mesh().size(5.0, 5.0))),
|
|
|
|
MeshMaterial3d(materials.add(StandardMaterial {
|
|
|
|
base_color: Color::srgb(0.3, 0.5, 0.3),
|
|
|
|
// Turning off culling keeps the plane visible when viewed from beneath.
|
|
|
|
cull_mode: None,
|
2024-09-10 23:40:48 +00:00
|
|
|
..default()
|
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
|
|
|
})),
|
2024-09-10 23:40:48 +00:00
|
|
|
));
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Cube"),
|
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(meshes.add(Cuboid::default())),
|
|
|
|
MeshMaterial3d(materials.add(Color::srgb(0.8, 0.7, 0.6))),
|
|
|
|
Transform::from_xyz(1.5, 0.51, 1.5),
|
2024-09-10 23:40:48 +00:00
|
|
|
));
|
|
|
|
|
|
|
|
commands.spawn((
|
|
|
|
Name::new("Light"),
|
2024-10-01 03:20:43 +00:00
|
|
|
PointLight::default(),
|
|
|
|
Transform::from_xyz(3.0, 8.0, 5.0),
|
2024-09-10 23:40:48 +00:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
fn instructions(mut commands: Commands) {
|
2024-10-17 01:01:32 +00:00
|
|
|
commands.spawn((
|
|
|
|
Name::new("Instructions"),
|
|
|
|
Text::new(
|
|
|
|
"Mouse up or down: pitch\n\
|
|
|
|
Mouse left or right: yaw\n\
|
|
|
|
Mouse buttons: roll",
|
|
|
|
),
|
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-10 23:40:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn orbit(
|
2024-10-13 20:32:06 +00:00
|
|
|
mut camera: Single<&mut Transform, With<Camera>>,
|
2024-09-10 23:40:48 +00:00
|
|
|
camera_settings: Res<CameraSettings>,
|
2024-09-13 15:47:04 +00:00
|
|
|
mouse_buttons: Res<ButtonInput<MouseButton>>,
|
|
|
|
mouse_motion: Res<AccumulatedMouseMotion>,
|
2024-09-10 23:40:48 +00:00
|
|
|
time: Res<Time>,
|
|
|
|
) {
|
2024-09-13 15:47:04 +00:00
|
|
|
let delta = mouse_motion.delta;
|
2024-09-10 23:40:48 +00:00
|
|
|
let mut delta_roll = 0.0;
|
|
|
|
|
2024-09-13 15:47:04 +00:00
|
|
|
if mouse_buttons.pressed(MouseButton::Left) {
|
|
|
|
delta_roll -= 1.0;
|
2024-09-10 23:40:48 +00:00
|
|
|
}
|
2024-09-13 15:47:04 +00:00
|
|
|
if mouse_buttons.pressed(MouseButton::Right) {
|
|
|
|
delta_roll += 1.0;
|
2024-09-10 23:40:48 +00:00
|
|
|
}
|
|
|
|
|
2024-09-13 15:47:04 +00:00
|
|
|
// Mouse motion is one of the few inputs that should not be multiplied by delta time,
|
|
|
|
// as we are already receiving the full movement since the last frame was rendered. Multiplying
|
|
|
|
// by delta time here would make the movement slower that it should be.
|
|
|
|
let delta_pitch = delta.y * camera_settings.pitch_speed;
|
|
|
|
let delta_yaw = delta.x * camera_settings.yaw_speed;
|
2024-09-10 23:40:48 +00:00
|
|
|
|
2024-09-13 15:47:04 +00:00
|
|
|
// Conversely, we DO need to factor in delta time for mouse button inputs.
|
2024-10-16 21:09:32 +00:00
|
|
|
delta_roll *= camera_settings.roll_speed * time.delta_secs();
|
2024-09-10 23:40:48 +00:00
|
|
|
|
|
|
|
// Obtain the existing pitch, yaw, and roll values from the transform.
|
2024-10-13 20:32:06 +00:00
|
|
|
let (yaw, pitch, roll) = camera.rotation.to_euler(EulerRot::YXZ);
|
2024-09-10 23:40:48 +00:00
|
|
|
|
|
|
|
// Establish the new yaw and pitch, preventing the pitch value from exceeding our limits.
|
|
|
|
let pitch = (pitch + delta_pitch).clamp(
|
|
|
|
camera_settings.pitch_range.start,
|
|
|
|
camera_settings.pitch_range.end,
|
|
|
|
);
|
|
|
|
let roll = roll + delta_roll;
|
|
|
|
let yaw = yaw + delta_yaw;
|
2024-10-13 20:32:06 +00:00
|
|
|
camera.rotation = Quat::from_euler(EulerRot::YXZ, yaw, pitch, roll);
|
2024-09-10 23:40:48 +00:00
|
|
|
|
|
|
|
// Adjust the translation to maintain the correct orientation toward the orbit target.
|
2024-10-20 18:55:17 +00:00
|
|
|
// In our example it's a static target, but this could easily be customized.
|
2024-09-13 15:47:04 +00:00
|
|
|
let target = Vec3::ZERO;
|
2024-10-13 20:32:06 +00:00
|
|
|
camera.translation = target - camera.forward() * camera_settings.orbit_distance;
|
2024-09-10 23:40:48 +00:00
|
|
|
}
|