-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Viewport Specific UI #5570
Comments
Weibye
added
C-Feature
A new feature, making something new possible
A-UI
Graphical user interfaces, styles, layouts, and widgets
labels
Aug 3, 2022
Closed
Agreed on all counts.
For pointers, I have been using rendertargets to map inputs to cameras' targets, then checking if the pointer is within the viewport of the target. With the use case outlined here, it might make more sense to map pointers to windows instead, then check all rendertargets in that window. |
This was referenced Aug 8, 2022
3 tasks
Merged
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 16, 2024
# Objective Add support for presenting each UI tree on a specific window and viewport, while making as few breaking changes as possible. This PR is meant to resolve the following issues at once, since they're all related. - Fixes #5622 - Fixes #5570 - Fixes #5621 Adopted #5892 , but started over since the current codebase diverged significantly from the original PR branch. Also, I made a decision to propagate component to children instead of recursively iterating over nodes in search for the root. ## Solution Add a new optional component that can be inserted to UI root nodes and propagate to children to specify which camera it should render onto. This is then used to get the render target and the viewport for that UI tree. Since this component is optional, the default behavior should be to render onto the single camera (if only one exist) and warn of ambiguity if multiple cameras exist. This reduces the complexity for users with just one camera, while giving control in contexts where it matters. ## Changelog - Adds `TargetCamera(Entity)` component to specify which camera should a node tree be rendered into. If only one camera exists, this component is optional. - Adds an example of rendering UI to a texture and using it as a material in a 3D world. - Fixes recalculation of physical viewport size when target scale factor changes. This can happen when the window is moved between displays with different DPI. - Changes examples to demonstrate assigning UI to different viewports and windows and make interactions in an offset viewport testable. - Removes `UiCameraConfig`. UI visibility now can be controlled via combination of explicit `TargetCamera` and `Visibility` on the root nodes. --------- Co-authored-by: davier <bricedavier@gmail.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Alice Cecile <alice.i.cecil@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
We should be able to specify which viewport UI should be rendered to in order to facilitate use cases such as split-screen UI:
Source: Mario Kart 8 Deluxe
What solution would you like?
The root node should contain data defining which viewport it should relate to.
What alternative(s) have you considered?
Ideas are welcome!
Additional context
We should add the four-way split-screen to #1974
The text was updated successfully, but these errors were encountered: