Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix CameraProjectionPlugin not implementing Plugin in some cases #11766

Merged

Conversation

doonv
Copy link
Contributor

@doonv doonv commented Feb 7, 2024

Objective

CameraProjectionPlugin<T>'s bounds are T: CameraProjection. But the bounds for CameraProjectionPlugin implementing Plugin are T: CameraProjection + Component + GetTypeRegistration. This means that if T is valid for CameraProjectionPlugin's bounds, but not the plugin implementation's bounds, then CameraProjectionPlugin would not implement Plugin. Which is weird because you'd expect a struct with Plugin in the name to implement Plugin.

Solution

Make CameraProjectionPlugin<T>'s bounds T: CameraProjection + Component + GetTypeRegistration. I also rearranged some of the code.


Changelog

  • Changed CameraProjectionPlugin<T>'s bounds to T: CameraProjection + Component + GetTypeRegistration

Migration Guide

CameraProjectionPlugin<T>'s trait bounds now require T to implement CameraProjection, Component, and GetTypeRegistration. This shouldn't affect most existing code as CameraProjectionPlugin<T> never implemented Plugin unless those bounds were met.

@alice-i-cecile alice-i-cecile added C-Bug An unexpected or incorrect behavior A-Rendering Drawing game state to the screen labels Feb 7, 2024
Copy link
Contributor

@pablo-lua pablo-lua left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the Plugin has thoses bounds, and I cannot use a CameraProjectionPlugin as a Plugin unless thoses bounds are fulfilled, then we must require thoses bounds in the struct as well.

@nicopap nicopap added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Feb 21, 2024
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Feb 26, 2024
Merged via the queue into bevyengine:main with commit 1b1934f Feb 26, 2024
27 checks passed
@hymm hymm added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Feb 26, 2024
msvbg pushed a commit to msvbg/bevy that referenced this pull request Feb 26, 2024
…evyengine#11766)

# Objective

`CameraProjectionPlugin<T>`'s bounds are `T: CameraProjection`. But the
bounds for `CameraProjectionPlugin` implementing `Plugin` are `T:
CameraProjection + Component + GetTypeRegistration`. This means that if
`T` is valid for `CameraProjectionPlugin`'s bounds, but not the plugin
implementation's bounds, then `CameraProjectionPlugin` would not
implement `Plugin`. Which is weird because you'd expect a struct with
`Plugin` in the name to implement `Plugin`.

## Solution

Make `CameraProjectionPlugin<T>`'s bounds `T: CameraProjection +
Component + GetTypeRegistration`. I also rearranged some of the code.

---

## Changelog

- Changed `CameraProjectionPlugin<T>`'s bounds to `T: CameraProjection +
Component + GetTypeRegistration`

## Migration Guide

`CameraProjectionPlugin<T>`'s trait bounds now require `T` to implement
`CameraProjection`, `Component`, and `GetTypeRegistration`. This
shouldn't affect most existing code as `CameraProjectionPlugin<T>` never
implemented `Plugin` unless those bounds were met.
msvbg pushed a commit to msvbg/bevy that referenced this pull request Feb 26, 2024
…evyengine#11766)

# Objective

`CameraProjectionPlugin<T>`'s bounds are `T: CameraProjection`. But the
bounds for `CameraProjectionPlugin` implementing `Plugin` are `T:
CameraProjection + Component + GetTypeRegistration`. This means that if
`T` is valid for `CameraProjectionPlugin`'s bounds, but not the plugin
implementation's bounds, then `CameraProjectionPlugin` would not
implement `Plugin`. Which is weird because you'd expect a struct with
`Plugin` in the name to implement `Plugin`.

## Solution

Make `CameraProjectionPlugin<T>`'s bounds `T: CameraProjection +
Component + GetTypeRegistration`. I also rearranged some of the code.

---

## Changelog

- Changed `CameraProjectionPlugin<T>`'s bounds to `T: CameraProjection +
Component + GetTypeRegistration`

## Migration Guide

`CameraProjectionPlugin<T>`'s trait bounds now require `T` to implement
`CameraProjection`, `Component`, and `GetTypeRegistration`. This
shouldn't affect most existing code as `CameraProjectionPlugin<T>` never
implemented `Plugin` unless those bounds were met.
github-merge-queue bot pushed a commit that referenced this pull request Apr 27, 2024
…1808)

# Objective

Fix #11799 and improve
`CameraProjectionPlugin`

## Solution

`CameraProjectionPlugin` is now an all-in-one plugin for adding a custom
`CameraProjection`. I also added `PbrProjectionPlugin` which is like
`CameraProjectionPlugin` but for PBR.

P.S. I'd like to get this merged after
#11766.

---

## Changelog

- Changed `CameraProjectionPlugin` to be an all-in-one plugin for adding
a `CameraProjection`
- Removed `VisibilitySystems::{UpdateOrthographicFrusta,
UpdatePerspectiveFrusta, UpdateProjectionFrusta}`, now replaced with
`VisibilitySystems::UpdateFrusta`
- Added `PbrProjectionPlugin` for projection-specific PBR functionality.

## Migration Guide

`VisibilitySystems`'s `UpdateOrthographicFrusta`,
`UpdatePerspectiveFrusta`, and `UpdateProjectionFrusta` variants were
removed, they were replaced with `VisibilitySystems::UpdateFrusta`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants