UI camera flexibility regression #5242
Comments
nicopap
added
C-Bug
|
What exactly is impossible ? I'll suppose you're referring to: fn cam_system(
mut cam: Query<(&mut Transform, &mut OrthographicProjection), With<CameraUi>>,
input: Res<Input<KeyCode>>,
) {By "manipulating camera", you mean changing the |
Since #4745 "CameraUi" is not a thing independent from other cameras, it's just a component to toggle ui visibility on a specific camera. You can see in extract_default_ui_camera_view that now, the UI camera perspective is a set value, and it's not accessible from the main app world. This PR adds a way to manipulate that camera perspective, through |
Nilirad
added
A-UI
Add fields to UiCameraConfig to control the UI camera scale and position. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
Add fields to UiCameraConfig to control the UI camera scale and position. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
Add fields to UiCameraConfig to control the UI camera scale and position. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
Add fields to UiCameraConfig to control the UI camera scale and position. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
Add fields to UiCameraConfig to control the UI camera scale and position. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
Add fields to UiCameraConfig to control the UI camera scale and position. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
Add fields to UiCameraConfig to control the UI camera scale and window_origin. Fixes bevyengine#5242. It is again possible to manipulate the ui camera. An alternative design was considered, where instead of having a component that controls all of the UI camera settings, the component would only hold an Entity referencing another camera. That design was abandoned in favor of the current one because the viewport is tightly bound to the "actual" camera the UI camera is attached to. So it would be awkward to maintain independently two different cameras.
|
We discussed having an optional UICameraBundle that points to a ui-only render graph. I think im open to it and thats largely a superficial / high level change. Notably, you can still do UI-only cameras by spawning a 2d or 3d camera and using RenderLayers. But a more explicit UI-only camera seems reasonable / one that doesn't run empty 2d or 3d passes. |
|
I think the UiPassNode will already work as expected for some UiCameraBundle with a customized projection. I built the "default ui view" part of that as opt-in (with this scenario in mind). You might be able to create your own UiCameraBundle right now, point it to a render graph with only UiPassNode wired up, and it might just work. No promises as I havent proven this scenario out yet, but I think theres a good chance. |
Bevy version
bf1ca81
What you did
In bevy 0.7, it was possible to manipulate individually ui cameras such as in this example.
What went wrong
With changes made to the way ui is handled in #4745, such design is impossible to execute. Manipulating UI cameras can be useful for fancy game effects, and it would be a shame to lose this flexibility.
The text was updated successfully, but these errors were encountered: