Tracking issue: Amazing Gizmos #9400
Labels
A-Gizmos
Visual editor and debug gizmos
C-Feature
A new feature, making something new possible
C-Tracking-Issue
An issue that collects information about a broad development initiative
Comments
nicopap
added
C-Feature
|
I'm now using gizmos extensively for debug visualizations. Here's a +1 for filled shapes. One of my gizmos is visualizing a quadtree, another is the nav mesh (using the quadtree) and filled gizmos would let me make an Unreal-style navigable area preview. It works now, just not as easy to look at as it could be. |
|
#9475 also seems relevant. |
|
Could you also add regular and irregular polygons to the list of shapes? |
I think it could be better expressed as "2D meshes". I'll reword the post to be more inclusive. |
Should have the choice between the text being billboarded or facing a specific direction |
|
Could write a polyhedron function with a similar interface to OpenSCAD's polyhedron() function. And by being less strict about the faces argument (since we only actually care about edges) it would work for polygons too. |
github-merge-queue bot
pushed a commit
that referenced
this issue
Nov 15, 2023
## Objective - Add an arrow gizmo as suggested by #9400 ## Solution (excuse my Protomen music) https://github.com/bevyengine/bevy/assets/14184826/192adf24-079f-4a4b-a17b-091e892974ec Wasn't horribly hard when i remembered i can change coordinate systems whenever I want. Gave them four tips (as suggested by @alice-i-cecile in discord) instead of trying to decide what direction the tips should point. Made the tip length default to 1/10 of the arrow's length, which looked good enough to me. Hard-coded the angle from the body to the tips to 45 degrees. ## Still TODO - [x] actual doc comments - [x] doctests - [x] `ArrowBuilder.with_tip_length()` --- ## Changelog - Added `gizmos.arrow()` and `gizmos.arrow_2d()` - Added arrows to `2d_gizmos` and `3d_gizmos` examples ## Migration Guide N/A --------- Co-authored-by: Nicola Papale <[email protected]>
|
Under arrows, could you add "double-ended"? thought of it just now but i'll forget by the time i can do it |
|
I think passing a
Added them! |
github-merge-queue bot
pushed a commit
that referenced
this issue
Nov 20, 2023
## Objective - Give all the intuitive groups of gizmos their own file - don't be a breaking change - don't change Gizmos interface - eventually do arcs too - future types of gizmos should be in their own files - see also #9400 ## Solution - Moved `gizmos.circle`, `gizmos.2d_circle`, and assorted helpers into `circles.rs` - Can also do arcs in this MR if y'all want; just figured I should do one thing at a time. ## Changelog - Changed - `gizmos::CircleBuilder` moved to `gizmos::circles::Circle2dBuilder` - `gizmos::Circle2dBuilder` moved to `gizmos::circles::Circle2dBuilder` ## Migration Guide - change `gizmos::CircleBuilder` to `gizmos::circles::Circle2dBuilder` - change `gizmos::Circle2dBuilder` to `gizmos::circles::Circle2dBuilder` --------- Co-authored-by: François <[email protected]>
|
Could you add "Compatibility with FixedUpdate"? |
rdrpenguin04
pushed a commit
to rdrpenguin04/bevy
that referenced
this issue
Jan 9, 2024
## Objective - Add an arrow gizmo as suggested by bevyengine#9400 ## Solution (excuse my Protomen music) https://github.com/bevyengine/bevy/assets/14184826/192adf24-079f-4a4b-a17b-091e892974ec Wasn't horribly hard when i remembered i can change coordinate systems whenever I want. Gave them four tips (as suggested by @alice-i-cecile in discord) instead of trying to decide what direction the tips should point. Made the tip length default to 1/10 of the arrow's length, which looked good enough to me. Hard-coded the angle from the body to the tips to 45 degrees. ## Still TODO - [x] actual doc comments - [x] doctests - [x] `ArrowBuilder.with_tip_length()` --- ## Changelog - Added `gizmos.arrow()` and `gizmos.arrow_2d()` - Added arrows to `2d_gizmos` and `3d_gizmos` examples ## Migration Guide N/A --------- Co-authored-by: Nicola Papale <[email protected]>
rdrpenguin04
pushed a commit
to rdrpenguin04/bevy
that referenced
this issue
Jan 9, 2024
## Objective - Give all the intuitive groups of gizmos their own file - don't be a breaking change - don't change Gizmos interface - eventually do arcs too - future types of gizmos should be in their own files - see also bevyengine#9400 ## Solution - Moved `gizmos.circle`, `gizmos.2d_circle`, and assorted helpers into `circles.rs` - Can also do arcs in this MR if y'all want; just figured I should do one thing at a time. ## Changelog - Changed - `gizmos::CircleBuilder` moved to `gizmos::circles::Circle2dBuilder` - `gizmos::Circle2dBuilder` moved to `gizmos::circles::Circle2dBuilder` ## Migration Guide - change `gizmos::CircleBuilder` to `gizmos::circles::Circle2dBuilder` - change `gizmos::Circle2dBuilder` to `gizmos::circles::Circle2dBuilder` --------- Co-authored-by: François <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 18, 2024
# 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]>
|
#11072 technically addressed support for tons of new shapes:
They don't have their own gizmo methods (except ellipses), but work through the |
|
Just asking, but does "Round joints" mean that you can have round corners for the gizmos? Would love to be able to draw rectangles, polygons, etc. with rounded corners. |
Not exactly. Try drawing a rectangle with the current gizmos and a large line width. You'll notice the corners are "cut". The joints would fill the corners. There are several ways to fill the corners, one of them is to fill it with a rounded shape, which we call "rounded joint".
|
|
Ah alright, thanks for the explanation. Should I make a new issue about this, or could this just be added to the list above? |
|
Well, there is "Rounded cuboid" but not "rounded arbitrary shapes" which seems to be a bit harder to implement. Though no reasons to add them to the wish list: added! |
|
I think we have to support a better way of using multiple windows with gizmos without having to create multiple configs for all windows |
Closed
github-merge-queue bot
pushed a commit
that referenced
this issue
Feb 28, 2024
# Objective - Implement grid gizmos, suggestion of #9400 ## Solution - Added `gizmos.grid(...) ` and `gizmos.grid_2d(...)` - The grids may be configured using `.outer_edges(...)` to specify whether to draw the outer border/edges of the grid and `.skew(...)`to specify the skew of the grid along the x or y directions. --- ## Changelog - Added a `grid` module to `bevy_gizmos` containing `gizmos.grid(...) ` and `gizmos.grid_2d(...)` as well as assorted items. - Updated the `2d_gizmos` and `3d_gizmos` examples to use grids. ## Additional The 2D and 3D examples now look like this: <img width="1440" alt="Screenshot 2024-02-20 at 15 09 40" src="https://github.com/bevyengine/bevy/assets/62256001/ce04191e-d839-4faf-a6e3-49b6bb4b922b"> <img width="1440" alt="Screenshot 2024-02-20 at 15 10 07" src="https://github.com/bevyengine/bevy/assets/62256001/317459ba-d452-42eb-ae95-7c84cdbd569b">
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 1, 2024
# Objective - We introduce a gizmo that displays coordinate axes relative to a Transform*, primarily for debugging purposes. - See #9400 ## Solution A new method, `Gizmos::axes`, takes a `Transform`* as input and displays the standard coordinate axes, transformed according to it; its signature looks like this: ````rust pub fn axes(&mut self, transform: into TransformPoint, base_length: f32) { //... } ```` If my carefully placed asterisks hadn't already tipped you off, the argument here is not actually a `Transform` but instead anything which implements `TransformPoint`, which allows it to work also with `GlobalTransform` (and also `Mat4` and `Affine3A`, if the user happens to be hand-rolling transformations in some way). The `base_length` parameter is a scaling factor applied to the coordinate vectors before the transformation takes place; in other words, the caller can use this to help size the coordinate axes appropriately for the entity that they are attached to. An example invocation of this method looks something like this: ````rust fn draw_axes_system( mut gizmos: Gizmos, query: Query<&Transform, With<MyMarkerComponent>>, ) { for &transform in &query { gizmos.axes(transform, 2.); } } ```` The result is the three coordinate axes, X, Y, Z (colored red, green, and blue, respectively), drawn onto the entity: <img width="206" alt="Screenshot 2024-02-29 at 2 41 45 PM" src="https://github.com/bevyengine/bevy/assets/2975848/789d1703-29ae-4295-80ab-b87459cf8037"> Note that, if scaling was applied as part of the given transformation, it shows up in scaling on the axes as well: <img width="377" alt="Screenshot 2024-02-29 at 2 43 53 PM" src="https://github.com/bevyengine/bevy/assets/2975848/6dc1caf4-8b3e-47f7-a86a-8906d870fa72"> --- ## Changelog - Added `Gizmos::axes` in bevy_gizmos/src/arrows.rs - Fixed a minor issue with `ArrowBuilder::with_tip_length` not correctly implementing builder style (no external impact) --- ## Discussion ### Design considerations I feel pretty strongly that having no default length scale is for the best, at least for the time being, since it's very easy for the length scale to be too small, leading to the axes being hidden inside the body of the object they are associated with. That is, if the API instead looked like this: ````rust gizmos.axes(transform); // or gizmos.axes(transform).with_length_scale(3.0); ```` then I think it's a reasonable expectation that the first thing would "just work" for most applications, and it wouldn't, which would be kind of a footgun. ### Future steps There are a few directions that this might expand in the future: 1. Introduce additional options via the standard builder pattern; i.e. introducing `AxesBuilder<T: TransformPoint>` so that people can configure the axis colors, normalize all axes to a fixed length independent of scale deformations, etc. 2. Fold this functionality into a plugin (like AabbGizmoPlugin) so that the functionality becomes more-or-less automatic based on certain fixed marker components. This wouldn't be very hard to implement, and it has the benefit of making the axes more frictionless to use. Furthermore, if we coupled this to the AABB functionality we already have, we could also ensure that the plugin automatically sizes the axes (by coupling their size to the dimensions of the AABB, for example). 3. Implement something similar for 2d. Honestly, I have no idea if this is desired/useful, but I could probably just implement it in this PR if that's the case.
|
Can you mark grid as resolved and add a sub-section "cubic grid"? |
Merged
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 3, 2024
# Objective - Part of #9400. - Add light gizmos for `SpotLight`, `PointLight` and `DirectionalLight`. ## Solution - Add a `ShowLightGizmo` and its related gizmo group and plugin, that shows a gizmo for all lights of an entities when inserted on it. Light display can also be toggled globally through the gizmo config in the same way it can already be done for `Aabb`s. - Add distinct segment setters for height and base one `Cone3dBuilder`. This allow having a properly rounded base without too much edges along the height. The doc comments explain how to ensure height and base connect when setting different values. Gizmo for the three light types without radius with the depth bias set to -1:  With Radius:  Possible future improvements: - Add a billboarded sprite with a distinct sprite for each light type. - Display the intensity of the light somehow (no idea how to represent that apart from some text). --- ## Changelog ### Added - The new `ShowLightGizmo`, part of the `LightGizmoPlugin` and configurable globally with `LightGizmoConfigGroup`, allows drawing gizmo for `PointLight`, `SpotLight` and `DirectionalLight`. The gizmos color behavior can be controlled with the `LightGizmoColor` member of `ShowLightGizmo` and `LightGizmoConfigGroup`. - The cone gizmo builder (`Cone3dBuilder`) now allows setting a differing number of segments for the base and height. --------- Co-authored-by: Gino Valente <[email protected]>
spectria-limina
pushed a commit
to spectria-limina/bevy
that referenced
this issue
Mar 9, 2024
# Objective - We introduce a gizmo that displays coordinate axes relative to a Transform*, primarily for debugging purposes. - See bevyengine#9400 ## Solution A new method, `Gizmos::axes`, takes a `Transform`* as input and displays the standard coordinate axes, transformed according to it; its signature looks like this: ````rust pub fn axes(&mut self, transform: into TransformPoint, base_length: f32) { //... } ```` If my carefully placed asterisks hadn't already tipped you off, the argument here is not actually a `Transform` but instead anything which implements `TransformPoint`, which allows it to work also with `GlobalTransform` (and also `Mat4` and `Affine3A`, if the user happens to be hand-rolling transformations in some way). The `base_length` parameter is a scaling factor applied to the coordinate vectors before the transformation takes place; in other words, the caller can use this to help size the coordinate axes appropriately for the entity that they are attached to. An example invocation of this method looks something like this: ````rust fn draw_axes_system( mut gizmos: Gizmos, query: Query<&Transform, With<MyMarkerComponent>>, ) { for &transform in &query { gizmos.axes(transform, 2.); } } ```` The result is the three coordinate axes, X, Y, Z (colored red, green, and blue, respectively), drawn onto the entity: <img width="206" alt="Screenshot 2024-02-29 at 2 41 45 PM" src="https://github.com/bevyengine/bevy/assets/2975848/789d1703-29ae-4295-80ab-b87459cf8037"> Note that, if scaling was applied as part of the given transformation, it shows up in scaling on the axes as well: <img width="377" alt="Screenshot 2024-02-29 at 2 43 53 PM" src="https://github.com/bevyengine/bevy/assets/2975848/6dc1caf4-8b3e-47f7-a86a-8906d870fa72"> --- ## Changelog - Added `Gizmos::axes` in bevy_gizmos/src/arrows.rs - Fixed a minor issue with `ArrowBuilder::with_tip_length` not correctly implementing builder style (no external impact) --- ## Discussion ### Design considerations I feel pretty strongly that having no default length scale is for the best, at least for the time being, since it's very easy for the length scale to be too small, leading to the axes being hidden inside the body of the object they are associated with. That is, if the API instead looked like this: ````rust gizmos.axes(transform); // or gizmos.axes(transform).with_length_scale(3.0); ```` then I think it's a reasonable expectation that the first thing would "just work" for most applications, and it wouldn't, which would be kind of a footgun. ### Future steps There are a few directions that this might expand in the future: 1. Introduce additional options via the standard builder pattern; i.e. introducing `AxesBuilder<T: TransformPoint>` so that people can configure the axis colors, normalize all axes to a fixed length independent of scale deformations, etc. 2. Fold this functionality into a plugin (like AabbGizmoPlugin) so that the functionality becomes more-or-less automatic based on certain fixed marker components. This wouldn't be very hard to implement, and it has the benefit of making the axes more frictionless to use. Furthermore, if we coupled this to the AABB functionality we already have, we could also ensure that the plugin automatically sizes the axes (by coupling their size to the dimensions of the AABB, for example). 3. Implement something similar for 2d. Honestly, I have no idea if this is desired/useful, but I could probably just implement it in this PR if that's the case.
spectria-limina
pushed a commit
to spectria-limina/bevy
that referenced
this issue
Mar 9, 2024
# Objective - Part of bevyengine#9400. - Add light gizmos for `SpotLight`, `PointLight` and `DirectionalLight`. ## Solution - Add a `ShowLightGizmo` and its related gizmo group and plugin, that shows a gizmo for all lights of an entities when inserted on it. Light display can also be toggled globally through the gizmo config in the same way it can already be done for `Aabb`s. - Add distinct segment setters for height and base one `Cone3dBuilder`. This allow having a properly rounded base without too much edges along the height. The doc comments explain how to ensure height and base connect when setting different values. Gizmo for the three light types without radius with the depth bias set to -1:  With Radius:  Possible future improvements: - Add a billboarded sprite with a distinct sprite for each light type. - Display the intensity of the light somehow (no idea how to represent that apart from some text). --- ## Changelog ### Added - The new `ShowLightGizmo`, part of the `LightGizmoPlugin` and configurable globally with `LightGizmoConfigGroup`, allows drawing gizmo for `PointLight`, `SpotLight` and `DirectionalLight`. The gizmos color behavior can be controlled with the `LightGizmoColor` member of `ShowLightGizmo` and `LightGizmoConfigGroup`. - The cone gizmo builder (`Cone3dBuilder`) now allows setting a differing number of segments for the base and height. --------- Co-authored-by: Gino Valente <[email protected]>
Merged
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 11, 2024
# Objective - Adds gizmo line joints, suggestion of #9400 ## Solution - Adds `line_joints: GizmoLineJoint` to `GizmoConfig`. Currently the following values are supported: - `GizmoLineJoint::None`: does not draw line joints, same behaviour as previously - `GizmoLineJoint::Bevel`: draws a single triangle between the lines - `GizmoLineJoint::Miter` / 'spiky joints': draws two triangles between the lines extending them until they meet at a (miter) point. - NOTE: for very small angles between the lines, which happens frequently in 3d, the miter point will be very far away from the point at which the lines meet. - `GizmoLineJoint::Round(resolution)`: Draw a circle arc between the lines. The circle is a triangle fan of `resolution` triangles. --- ## Changelog - Added `GizmoLineJoint`, use that in `GizmoConfig` and added necessary pipelines and draw commands. - Added a new `line_joints.wgsl` shader containing three vertex shaders `vertex_bevel`, `vertex_miter` and `vertex_round` as well as a basic `fragment` shader. ## Migration Guide Any manually created `GizmoConfig`s must now set the `.line_joints` field. ## Known issues - The way we currently create basic closed shapes like rectangles, circles, triangles or really any closed 2d shape means that one of the corners will not be drawn with joints, although that would probably be expected. (see the triangle in the 2d image) - This could be somewhat mitigated by introducing line caps or fixed by adding another segment overlapping the first of the strip. (Maybe in a followup PR?) - 3d shapes can look 'off' with line joints (especially bevel) because wherever 3 or more lines meet one of them may stick out beyond the joint drawn between the other 2. - Adding additional lines so that there is a joint between every line at a corner would fix this but would probably be too computationally expensive. - Miter joints are 'unreasonably long' for very small angles between the lines (the angle is the angle between the lines in screen space). This is technically correct but distracting and does not feel right, especially in 3d contexts. I think limiting the length of the miter to the point at which the lines meet might be a good idea. - The joints may be drawn with a different gizmo in-between them and their corresponding lines in 2d. Some sort of z-ordering would probably be good here, but I believe this may be out of scope for this PR. ## Additional information Some pretty images :) <img width="1175" alt="Screenshot 2024-03-02 at 04 53 50" src="https://github.com/bevyengine/bevy/assets/62256001/58df7e63-9376-4430-8871-32adba0cb53b"> - Note that the top vertex does not have a joint drawn. <img width="1440" alt="Screenshot 2024-03-02 at 05 03 55" src="https://github.com/bevyengine/bevy/assets/62256001/137a00cf-cbd4-48c2-a46f-4b47492d4fd9"> Now for a weird video: https://github.com/bevyengine/bevy/assets/62256001/93026f48-f1d6-46fe-9163-5ab548a3fce4 - The black lines shooting out from the cube are miter joints that get very long because the lines between which they are drawn are (almost) collinear in screen space. --------- Co-authored-by: Pablo Reinhardt <[email protected]>
Merged
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 13, 2024
# Objective - Adds 3d grids, suggestion of #9400 ## Solution - Added 3d grids (grids spanning all three dimensions, not flat grids) to bevy_gizmos --- ## Changelog - `gizmos.grid(...)` and `gizmos.grid_2d(...)` now return a `GridBuilder2d`. - Added `gizmos.grid_3d(...)` which returns a `GridBuilder3d`. - The difference between them is basically only that `GridBuilder3d` exposes some methods for configuring the z axis while the 2d version doesn't. - Allowed for drawing the outer edges along a specific axis by calling `.outer_edges_x()`, etc. on the builder. ## Additional information Please note that I have not added the 3d grid to any example as not to clutter them. Here is an image of what the 3d grid looks like: <img width="1440" alt="Screenshot 2024-03-12 at 02 19 55" src="https://github.com/bevyengine/bevy/assets/62256001/4cd3b7de-cf2c-4f05-8a79-920a4dd804b8"> --------- Co-authored-by: Alice Cecile <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 25, 2024
# Objective - Adds line styles to bevy gizmos, suggestion of #9400 - Currently solid and dotted lines are implemented but this can easily be extended to support dashed lines as well if that is wanted. ## Solution - Adds the enum `GizmoLineStyle` and uses it in each `GizmoConfig` to configure the style of the line. - Each "dot" in a dotted line has the same width and height as the `line_width` of the corresponding line. --- ## Changelog - Added `GizmoLineStyle` to `bevy_gizmos` - Added a `line_style: GizmoLineStyle ` attribute to `GizmoConfig` - Updated the `lines.wgsl` shader and the pipelines accordingly. ## Migration Guide - Any manually created `GizmoConfig` must now include the `line_style` attribute ## Additional information Some pretty pictures :) This is the 3d_gizmos example with/without `line_perspective`: <img width="1440" alt="Screenshot 2024-03-09 at 23 25 53" src="https://github.com/bevyengine/bevy/assets/62256001/b1b97311-e78d-4de3-8dfe-9e48a35bb27d"> <img width="1440" alt="Screenshot 2024-03-09 at 23 25 39" src="https://github.com/bevyengine/bevy/assets/62256001/50ee8ecb-5290-484d-ba36-7fd028374f7f"> And the 2d example: <img width="1440" alt="Screenshot 2024-03-09 at 23 25 06" src="https://github.com/bevyengine/bevy/assets/62256001/4452168f-d605-4333-bfa5-5461d268b132"> --------- Co-authored-by: BD103 <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 10, 2024
# Objective - Adds tetrahedron gizmos, suggestion of #9400 ## Solution - Implement tetrahedron gizmos as a `gizmos.primitive_3d` ## Additional info Here is a short video of the default tetrahedron :) https://github.com/bevyengine/bevy/assets/62256001/a6f31b6f-78bc-4dc2-8f46-2ebd04ed8a0e --------- Co-authored-by: François Mockers <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 16, 2024
# Objective - Implement double ended arrows, suggestion of #9400 ## Solution - Creation of new field and method to the `ArrowBuilder` --- ## Changelog ### Added - New field `ArrowBuilder::double_ended` - New method `ArrowBuilder::with_double_end` to redefine the double_ended field ## Additional I added this in the 3d_gizmos example, that's the result:  I added this arrow in the 2d_gizmos example too:  --------- Co-authored-by: Afonso Lage <[email protected]> Co-authored-by: Pablo Reinhardt <[email protected]>
|
Text gizmos... please |
github-merge-queue bot
pushed a commit
that referenced
this issue
May 16, 2024
# Objective - Implement rounded cuboids and rectangles, suggestion of #9400 ## Solution - Added `Gizmos::rounded_cuboid`, `Gizmos::rounded_rect` and `Gizmos::rounded_rect_2d`. - All of these return builders that allow configuring of the corner/edge radius using `.corner_radius(...)` or `.edge_radius(...)` as well as the line segments of each arc using `.arc_segments(...)`. --- ## Changelog - Added a new `rounded_box` module to `bevy_gizmos` containing all of the above methods and builders. - Updated the examples `2d_gizmos` and `3d_gizmos` ## Additional information The 3d example now looks like this: <img width="1440" alt="Screenshot 2024-02-28 at 01 47 28" src="https://github.com/bevyengine/bevy/assets/62256001/654e30ca-c091-4f14-a402-90138e95c71b"> And this is the updated 2d example showcasing negative corner radius: <img width="1440" alt="Screenshot 2024-02-28 at 01 59 37" src="https://github.com/bevyengine/bevy/assets/62256001/3904697a-5462-4ee7-abd9-3e893ca07082"> <img width="1440" alt="Screenshot 2024-02-28 at 01 59 47" src="https://github.com/bevyengine/bevy/assets/62256001/a8892cfd-3aad-4c0c-87eb-559c17c8864c"> --------- Co-authored-by: JMS55 <[email protected]> Co-authored-by: James Gayfer <[email protected]>
|
@nicopap double-ended can be ticked off. actually a good few can be ticked off. (unless i'm stupid and you're waiting for the features to actually ship) |
|
For my project, I need text gizmos combined with line gizmos, for example:
Is there any progress on text gizmos? Or some other way I can achieve this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue tracks the progress on Gizmo features
Contributing
Want to check off one of those checkboxes? Nothing easier!
All related issues will be listed in this tracking issue.
The (IMO) easy ones
All features
Not sorted in any specific order:
FixedUpdategizmos: Currently gizmos do not work if used in theFixedUpdateschedule. (Contextually clearing gizmos #10973, Make Gizmos compatible with FixedUpdate #9153)SystemParamrequired, just a macro/function call to draw gizmos, nothing more. No more need to modify the system signature to add gizmos, or even pass around the gizmo struct, in the style of https://github.com/nicopap/bevy-debug-text-overlay/)bevy_textsanctimonious rituals. Just agizmo_print!("foobar")and it would show on screen.The text was updated successfully, but these errors were encountered: