-
-
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
Add frustum gizmo #10038
base: main
Are you sure you want to change the base?
Add frustum gizmo #10038
Conversation
@@ -160,6 +161,12 @@ fn queue_line_gizmos_2d( | |||
| Mesh2dPipelineKey::from_hdr(view.hdr); | |||
|
|||
for (entity, handle) in &line_gizmos { | |||
// The frustum gizmo adds a linegizmo to the same entity. | |||
// We can use that here to prevent views from rendering their own frustum. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some minor comments, and I think the frustum corner calculations could maybe be on the Frustum
impl.
Co-authored-by: Robert Swain <[email protected]>
…ion to public methods
Thanks for the comments :) I took a look at the frusta on the lights after reading the comments on discord and noticed that spotlights already have a |
I'd use this feature if it was in. @irate-devil any blockers on this? |
# Objective This PR aims to implement multiple configs for gizmos as discussed in #9187. ## Solution Configs for the new `GizmoConfigGroup`s are stored in a `GizmoConfigStore` resource and can be accesses using a type based key or iterated over. This type based key doubles as a standardized location where plugin authors can put their own configuration not covered by the standard `GizmoConfig` struct. For example the `AabbGizmoGroup` has a default color and toggle to show all AABBs. New configs can be registered using `app.init_gizmo_group::<T>()` during startup. When requesting the `Gizmos<T>` system parameter the generic type determines which config is used. The config structs are available through the `Gizmos` system parameter allowing for easy access while drawing your gizmos. Internally, resources and systems used for rendering (up to an including the extract system) are generic over the type based key and inserted on registering a new config. ## Alternatives The configs could be stored as components on entities with markers which would make better use of the ECS. I also implemented this approach ([here](https://github.com/jeliag/bevy/tree/gizmo-multiconf-comp)) and believe that the ergonomic benefits of a central config store outweigh the decreased use of the ECS. ## Unsafe Code Implementing system parameter by hand is unsafe but seems to be required to access the config store once and not on every gizmo draw function call. This is critical for performance. ~Is there a better way to do this?~ ## Future Work New gizmos (such as #10038, and ideas from #9400) will require custom configuration structs. Should there be a new custom config for every gizmo type, or should we group them together in a common configuration? (for example `EditorGizmoConfig`, or something more fine-grained) ## Changelog - Added `GizmoConfigStore` resource and `GizmoConfigGroup` trait - Added `init_gizmo_group` to `App` - Added early returns to gizmo drawing increasing performance when gizmos are disabled - Changed `GizmoConfig` and aabb gizmos to use new `GizmoConfigStore` - Changed `Gizmos` system parameter to use type based key to retrieve config - Changed resources and systems used for gizmo rendering to be generic over type based key - Changed examples (3d_gizmos, 2d_gizmos) to showcase new API ## Migration Guide - `GizmoConfig` is no longer a resource and has to be accessed through `GizmoConfigStore` resource. The default config group is `DefaultGizmoGroup`, but consider using your own custom config group if applicable. --------- Co-authored-by: Nicola Papale <[email protected]>
It would be great to have this functionality |
Adds the
FrustumGizmo
which works in a similar fashion to the previously addedAabbGizmo
.Closes #4082
Preventing cameras from drawing their own frustums made this a lot messier but as a result this is now technically the first retained gizmo q:
Here's a screenshot of a modified split_screen example showing the frustum of one view in the other.
Changelog
Added the
FrustumGizmo
component for drawing the frustums of cameras with the relevant settings added to theGizmoConfig
resource.