2023-12-26 17:15:50 +00:00
|
|
|
//! Shows how to create graphics that snap to the pixel grid by rendering to a texture in 2D
|
|
|
|
|
|
|
|
use bevy::{
|
|
|
|
prelude::*,
|
|
|
|
render::{
|
Improve API for scaling orthographic cameras (#15969)
# Objective
Fixes #15791.
As raised in #11022, scaling orthographic cameras is confusing! In Bevy
0.14, there were multiple completely redundant ways to do this, and no
clear guidance on which to use.
As a result, #15075 removed the `scale` field from
`OrthographicProjection` completely, solving the redundancy issue.
However, this resulted in an unintuitive API and a painful migration, as
discussed in #15791. Users simply want to change a single parameter to
zoom, rather than deal with the irrelevant details of how the camera is
being scaled.
## Solution
This PR reverts #15075, and takes an alternate, more nuanced approach to
the redundancy problem. `ScalingMode::WindowSize` was by far the biggest
offender. This was the default variant, and stored a float that was
*fully* redundant to setting `scale`.
All of the other variants contained meaningful semantic information and
had an intuitive scale. I could have made these unitless, storing an
aspect ratio, but this would have been a worse API and resulted in a
pointlessly painful migration.
In the course of this work I've also:
- improved the documentation to explain that you should just set `scale`
to zoom cameras
- swapped to named fields for all of the variants in `ScalingMode` for
more clarity about the parameter meanings
- substantially improved the `projection_zoom` example
- removed the footgunny `Mul` and `Div` impls for `ScalingMode`,
especially since these no longer have the intended effect on
`ScalingMode::WindowSize`.
- removed a rounding step because this is now redundant 🎉
## Testing
I've tested these changes as part of my work in the `projection_zoom`
example, and things seem to work fine.
## Migration Guide
`ScalingMode` has been refactored for clarity, especially on how to zoom
orthographic cameras and their projections:
- `ScalingMode::WindowSize` no longer stores a float, and acts as if its
value was 1. Divide your camera's scale by any previous value to achieve
identical results.
- `ScalingMode::FixedVertical` and `FixedHorizontal` now use named
fields.
---------
Co-authored-by: MiniaczQ <xnetroidpl@gmail.com>
2024-10-17 17:50:06 +00:00
|
|
|
camera::RenderTarget,
|
2023-12-26 17:15:50 +00:00
|
|
|
render_resource::{
|
|
|
|
Extent3d, TextureDescriptor, TextureDimension, TextureFormat, TextureUsages,
|
|
|
|
},
|
|
|
|
view::RenderLayers,
|
|
|
|
},
|
|
|
|
window::WindowResized,
|
|
|
|
};
|
|
|
|
|
|
|
|
/// In-game resolution width.
|
|
|
|
const RES_WIDTH: u32 = 160;
|
|
|
|
|
|
|
|
/// In-game resolution height.
|
|
|
|
const RES_HEIGHT: u32 = 90;
|
|
|
|
|
|
|
|
/// Default render layers for pixel-perfect rendering.
|
|
|
|
/// You can skip adding this component, as this is the default.
|
|
|
|
const PIXEL_PERFECT_LAYERS: RenderLayers = RenderLayers::layer(0);
|
|
|
|
|
|
|
|
/// Render layers for high-resolution rendering.
|
|
|
|
const HIGH_RES_LAYERS: RenderLayers = RenderLayers::layer(1);
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
App::new()
|
|
|
|
.add_plugins(DefaultPlugins.set(ImagePlugin::default_nearest()))
|
|
|
|
.add_systems(Startup, (setup_camera, setup_sprite, setup_mesh))
|
|
|
|
.add_systems(Update, (rotate, fit_canvas))
|
|
|
|
.run();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Low-resolution texture that contains the pixel-perfect world.
|
|
|
|
/// Canvas itself is rendered to the high-resolution world.
|
|
|
|
#[derive(Component)]
|
|
|
|
struct Canvas;
|
|
|
|
|
|
|
|
/// Camera that renders the pixel-perfect world to the [`Canvas`].
|
|
|
|
#[derive(Component)]
|
|
|
|
struct InGameCamera;
|
|
|
|
|
|
|
|
/// Camera that renders the [`Canvas`] (and other graphics on [`HIGH_RES_LAYERS`]) to the screen.
|
|
|
|
#[derive(Component)]
|
|
|
|
struct OuterCamera;
|
|
|
|
|
|
|
|
#[derive(Component)]
|
|
|
|
struct Rotate;
|
|
|
|
|
|
|
|
fn setup_sprite(mut commands: Commands, asset_server: Res<AssetServer>) {
|
|
|
|
// the sample sprite that will be rendered to the pixel-perfect canvas
|
|
|
|
commands.spawn((
|
2024-10-09 16:17:26 +00:00
|
|
|
Sprite::from_image(asset_server.load("pixel/bevy_pixel_dark.png")),
|
|
|
|
Transform::from_xyz(-40., 20., 2.),
|
2023-12-26 17:15:50 +00:00
|
|
|
Rotate,
|
|
|
|
PIXEL_PERFECT_LAYERS,
|
|
|
|
));
|
|
|
|
|
|
|
|
// the sample sprite that will be rendered to the high-res "outer world"
|
|
|
|
commands.spawn((
|
2024-10-09 16:17:26 +00:00
|
|
|
Sprite::from_image(asset_server.load("pixel/bevy_pixel_light.png")),
|
|
|
|
Transform::from_xyz(-40., -20., 2.),
|
2023-12-26 17:15:50 +00:00
|
|
|
Rotate,
|
|
|
|
HIGH_RES_LAYERS,
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Spawns a capsule mesh on the pixel-perfect layer.
|
|
|
|
fn setup_mesh(
|
|
|
|
mut commands: Commands,
|
|
|
|
mut meshes: ResMut<Assets<Mesh>>,
|
|
|
|
mut materials: ResMut<Assets<ColorMaterial>>,
|
|
|
|
) {
|
|
|
|
commands.spawn((
|
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
|
|
|
Mesh2d(meshes.add(Capsule2d::default())),
|
|
|
|
MeshMaterial2d(materials.add(Color::BLACK)),
|
|
|
|
Transform::from_xyz(40., 0., 2.).with_scale(Vec3::splat(32.)),
|
2023-12-26 17:15:50 +00:00
|
|
|
Rotate,
|
|
|
|
PIXEL_PERFECT_LAYERS,
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
fn setup_camera(mut commands: Commands, mut images: ResMut<Assets<Image>>) {
|
|
|
|
let canvas_size = Extent3d {
|
|
|
|
width: RES_WIDTH,
|
|
|
|
height: RES_HEIGHT,
|
|
|
|
..default()
|
|
|
|
};
|
|
|
|
|
|
|
|
// this Image serves as a canvas representing the low-resolution game screen
|
|
|
|
let mut canvas = Image {
|
|
|
|
texture_descriptor: TextureDescriptor {
|
|
|
|
label: None,
|
|
|
|
size: canvas_size,
|
|
|
|
dimension: TextureDimension::D2,
|
|
|
|
format: TextureFormat::Bgra8UnormSrgb,
|
|
|
|
mip_level_count: 1,
|
|
|
|
sample_count: 1,
|
|
|
|
usage: TextureUsages::TEXTURE_BINDING
|
|
|
|
| TextureUsages::COPY_DST
|
|
|
|
| TextureUsages::RENDER_ATTACHMENT,
|
|
|
|
view_formats: &[],
|
|
|
|
},
|
|
|
|
..default()
|
|
|
|
};
|
|
|
|
|
|
|
|
// fill image.data with zeroes
|
|
|
|
canvas.resize(canvas_size);
|
|
|
|
|
|
|
|
let image_handle = images.add(canvas);
|
|
|
|
|
|
|
|
// this camera renders whatever is on `PIXEL_PERFECT_LAYERS` to the canvas
|
|
|
|
commands.spawn((
|
2024-10-05 01:59:52 +00:00
|
|
|
Camera2d,
|
|
|
|
Camera {
|
|
|
|
// render before the "main pass" camera
|
|
|
|
order: -1,
|
|
|
|
target: RenderTarget::Image(image_handle.clone()),
|
2023-12-26 17:15:50 +00:00
|
|
|
..default()
|
|
|
|
},
|
2024-10-05 01:59:52 +00:00
|
|
|
Msaa::Off,
|
2023-12-26 17:15:50 +00:00
|
|
|
InGameCamera,
|
|
|
|
PIXEL_PERFECT_LAYERS,
|
|
|
|
));
|
|
|
|
|
|
|
|
// spawn the canvas
|
2024-10-09 16:17:26 +00:00
|
|
|
commands.spawn((Sprite::from_image(image_handle), Canvas, HIGH_RES_LAYERS));
|
2023-12-26 17:15:50 +00:00
|
|
|
|
|
|
|
// the "outer" camera renders whatever is on `HIGH_RES_LAYERS` to the screen.
|
|
|
|
// here, the canvas and one of the sample sprites will be rendered by this camera
|
2024-10-05 01:59:52 +00:00
|
|
|
commands.spawn((Camera2d, Msaa::Off, OuterCamera, HIGH_RES_LAYERS));
|
2023-12-26 17:15:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Rotates entities to demonstrate grid snapping.
|
|
|
|
fn rotate(time: Res<Time>, mut transforms: Query<&mut Transform, With<Rotate>>) {
|
|
|
|
for mut transform in &mut transforms {
|
2024-10-16 21:09:32 +00:00
|
|
|
let dt = time.delta_secs();
|
2023-12-26 17:15:50 +00:00
|
|
|
transform.rotate_z(dt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Scales camera projection to fit the window (integer multiples only).
|
|
|
|
fn fit_canvas(
|
|
|
|
mut resize_events: EventReader<WindowResized>,
|
2024-10-13 20:32:06 +00:00
|
|
|
mut projection: Single<&mut OrthographicProjection, With<OuterCamera>>,
|
2023-12-26 17:15:50 +00:00
|
|
|
) {
|
|
|
|
for event in resize_events.read() {
|
|
|
|
let h_scale = event.width / RES_WIDTH as f32;
|
|
|
|
let v_scale = event.height / RES_HEIGHT as f32;
|
Improve API for scaling orthographic cameras (#15969)
# Objective
Fixes #15791.
As raised in #11022, scaling orthographic cameras is confusing! In Bevy
0.14, there were multiple completely redundant ways to do this, and no
clear guidance on which to use.
As a result, #15075 removed the `scale` field from
`OrthographicProjection` completely, solving the redundancy issue.
However, this resulted in an unintuitive API and a painful migration, as
discussed in #15791. Users simply want to change a single parameter to
zoom, rather than deal with the irrelevant details of how the camera is
being scaled.
## Solution
This PR reverts #15075, and takes an alternate, more nuanced approach to
the redundancy problem. `ScalingMode::WindowSize` was by far the biggest
offender. This was the default variant, and stored a float that was
*fully* redundant to setting `scale`.
All of the other variants contained meaningful semantic information and
had an intuitive scale. I could have made these unitless, storing an
aspect ratio, but this would have been a worse API and resulted in a
pointlessly painful migration.
In the course of this work I've also:
- improved the documentation to explain that you should just set `scale`
to zoom cameras
- swapped to named fields for all of the variants in `ScalingMode` for
more clarity about the parameter meanings
- substantially improved the `projection_zoom` example
- removed the footgunny `Mul` and `Div` impls for `ScalingMode`,
especially since these no longer have the intended effect on
`ScalingMode::WindowSize`.
- removed a rounding step because this is now redundant 🎉
## Testing
I've tested these changes as part of my work in the `projection_zoom`
example, and things seem to work fine.
## Migration Guide
`ScalingMode` has been refactored for clarity, especially on how to zoom
orthographic cameras and their projections:
- `ScalingMode::WindowSize` no longer stores a float, and acts as if its
value was 1. Divide your camera's scale by any previous value to achieve
identical results.
- `ScalingMode::FixedVertical` and `FixedHorizontal` now use named
fields.
---------
Co-authored-by: MiniaczQ <xnetroidpl@gmail.com>
2024-10-17 17:50:06 +00:00
|
|
|
projection.scale = 1. / h_scale.min(v_scale).round();
|
2023-12-26 17:15:50 +00:00
|
|
|
}
|
|
|
|
}
|