Skip to content

Fix CameraProjectionPlugin not implementing Plugin in some cases#11766

Merged
alice-i-cecile merged 1 commit intobevyengine:mainfrom
doonv:fix-cameraprojectionplugin-bounds
Feb 26, 2024
Merged

Fix CameraProjectionPlugin not implementing Plugin in some cases#11766
alice-i-cecile merged 1 commit intobevyengine:mainfrom
doonv:fix-cameraprojectionplugin-bounds

Conversation

@doonv
Copy link
Copy Markdown
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
Copy Markdown
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
@hymm hymm added the M-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-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