Add component to control UI camera position #5243
Conversation
nicopap
force-pushed
the
cameraui-movement
branch
from
118d82d
to
c09da4e
Compare
examples/ui/ui.rs
Outdated
| if keyboard.pressed(KeyCode::A) { | ||
| config.position.x -= 1.0; | ||
| } | ||
| if keyboard.pressed(KeyCode::D) { | ||
| config.position.x += 1.0; | ||
| } | ||
| if keyboard.pressed(KeyCode::W) { | ||
| config.scale *= 0.99; | ||
| } | ||
| if keyboard.pressed(KeyCode::S) { | ||
| config.scale *= 1.01; | ||
| } |
There was a problem hiding this comment.
as an azerty user, I'm not so fan of WASD keys, maybe arrows would work ?
That would be more coherent with another example too : https://github.com/bevyengine/bevy/blob/main/examples/games/alien_cake_addict.rs#L202
There was a problem hiding this comment.
Living a mere 10 minutes drive from the French boundary, I'm a happy QWERTZ user :D my poor French colleagues always complaining about AZERTY support. Point taken though, I'll use arrow keys.
| @@ -136,22 +134,50 @@ impl Default for ButtonBundle { | |||
| } | |||
| } | |||
| } | |||
| #[derive(Component, Clone)] | |||
| pub struct CameraUi { | |||
| pub is_enabled: bool, | |||
There was a problem hiding this comment.
So this wasn't used anymore? good spot
There was a problem hiding this comment.
The meaning of CameraUi changed in #4745:
- before: A marker component used to specify which camera was the one for rendering UI
- after: A component to specify whether the camera it is attached to displays the UI (when not present, shows UI)
So technically still used, but for something almost opposite of what it used to.
I renamed it CameraUiConfig in #5234, because if you were previously relying on CameraUi, your game would still compile, but really do the opposite of what it was doing before.
I built on CameraUiConfig in this PR, because I thought it made sense as an API for manipulating the UI camera associated with actual 2d or 3d camera.
crates/bevy_ui/src/update.rs
Outdated
| ) { | ||
| for (entity, camera, config, render_info, config_changed) in query.iter_mut() { | ||
| if matches!(config, Some(&CameraUiConfig { show_ui: false, .. })) { | ||
| commands.entity(entity).remove::<UiCameraRenderInfo>(); |
There was a problem hiding this comment.
Not so fan of this removal ?
if a user:
- changes something within
UiCameraRenderInfo - then disable UI
- then re-enables it
-> the changes will be lost due to https://github.com/bevyengine/bevy/pull/5243/files#diff-5215fb8ee76dd4e8c35bf7ef10e986e57f73be9652d33200891b6a5a6f9d30d9R177-R183
There was a problem hiding this comment.
The component is read-only outside of bevy_ui, I expose it so that it's possible to access the camera projection (for example to compute proper offset for mouse interactions)
But yeah, you are right. Between the moment the user modify CameraUiConfig and the next CoreStage::PostUpdate this component will be out of date (both in term of value and existence). Which I agree is a footgun.
I don't like this either. How would this better be expressed? It needs both access to CameraUiConfig and Camera to work, so it's not as simple as replacing the content of CameraUiConfig.
Edit: Would a WorldQuery derive help? It could bundle a Camera and CameraUiConfig component access.
Nilirad
added
C-Bug
In bevy 0.7, `CameraUi` was a component specifically added to cameras that display the UI. Since camera-driven rendering was merged, it actually does the opposite! This will make it difficult for current users to adapt to 0.8. To avoid unnecessary confusion, we rename `CameraUi` into `CameraUiConfig`.
Extend `CameraUiConfig` to include info about the UI camera position in the "ui world". This allows fancy effects like moving UI, which was possible before the migration to camera-driven rendering. This reverts the regression caused by bevyengine#4765 preventing users from moving the UI camera.
nicopap
force-pushed
the
cameraui-movement
branch
from
c09da4e
to
5f297a4
Compare
Having them separate caused update delay, so we remove them.
|
I've looked into implementing multiple ui camera handling. After considering the design for it, I'm not so sure this PR is the best way forward, there are alternative API design possible, and I need to explore them. This design creates a new component to attach to existing camera entities. That component would contain all information pertaining to the UI camera. Another option is for that component to just contain an Both have positives and negatives. But I'll have to explore how to implement both before reaching any conclusion. |
|
Closed in favor of #5252 |
Objective
Enable user manipulation of UI camera.
Solution
Extend
CameraUiConfigto include info about the UI camera position inthe "ui world". This allows fancy effects like moving UI, which was
possible before the migration to camera-driven rendering.
Note that the first commit of this PR (aa9593d) is part of PR #5234, only the second one is relevant.
Changelog
positionandscalefields toCameraUiConfigto enable manipulating the position of the attached UI camera.Migration Guide
UiCameraBundleand manipulating itsOrthographicProjectionandGlobalTransform, add aCameraUiConfigcomponent to your viewport camera, and use its field to change the ui camera position.