-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Implement Arc3D for Gizmos #11540
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
Implement Arc3D for Gizmos #11540
Conversation
The API of this implementation mimics unity's API for the same feature, c.f. https://docs.unity3d.com/ScriptReference/Handles.DrawWireArc.html This was done since it seems to be the most flexible design so far allowing for arcs with arc angles in the range of [-360.0, 360.0] degrees. Authored-by: RobWalt <[email protected]>
I noticed some flaws with the original implementation of the API while creating some examples: - The orientation via `from` and `rotation_axis` fields felt really wonky - The rotation seemed not to rotate around the center set by the user This is why I reimplemented the API. It now draws some kind of default arc in 3D which has properties which are documented in the doc strings. You can modify this default arc via builder methods which seems to be the most flexible approach in my eyes. Authored-by: RobWalt <[email protected]>
Authored-by: RobWalt <[email protected]>
- reuse new factored out function to calculate the default amount of segments for arc2d - add the gizmos active check to arc3d - also implement optional segments logic for arc3d - cleanup debug gizmo center drawing
Authored-by: RobWalt <[email protected]>
crates/bevy_gizmos/src/arcs.rs
Outdated
/// ``` | ||
/// | ||
/// # Notes | ||
/// - This method assumes that the points `from` and `to` are distinct from the `center`. If |
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.
I'm a bit nervous about using "behavior is undefined" here (and above): it's not UB in the compiler sense and we may confuse readers. Maybe "graphical glitches may occur"?
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.
Thanks for spotting this!
I just tested these cases (after all we're also part scientists, right? :D). It seems like nothing happens at all. We should probably communicate this to the user.
Do you think an early return might make sense? I'm not really sure. On the one hand we could save some compute in the case that we wouldn't draw anything anyways. On the other hand this is an edge case and adding two checks for every non-edge case might be needless overhead.
I think I'm just going for changing the comment for now, but please let me know what you think.
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.
I think let's just change the comment and leave the behavior for now. I'm really not concerned about the performance in pathological cases and if it doesn't crash I'm quite happy with it as is.
Authored-by: RobWalt <[email protected]>
Thanks for spotting this Alice! Authored-by: RobWalt <[email protected]>
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.
Similar thoughts as #11072 (review), the position, rotation, and color should be given as arguments to the arc methods. All gizmo methods have some kind of position and a color as an argument, and assuming a default color isn't ideal imo.
arc_2d
also has the circle center, rotation (direction_angle
) and color as arguments, so it's not good to make arc_3d
different. The APIs should be consistent both in terms of arguments and naming (if possible).
and also adjust: - docs - tests - examples Authored-by: RobWalt <[email protected]>
# Objective - Implement an arc3d API for gizmos - Solves bevyengine#11536 ## Solution ### `arc_3d` - The current `arc3d` method on gizmos only takes an angle - It draws an "standard arc" by default, this is an arc starting at `Vec3::X`, in the XZ plane, in counter clockwise direction with a normal that is facing up - The "standard arc" can be customized with the usual gizmo builder pattern. This way you'll be able to draw arbitrary arcs ### `short/long_arc_3d_between` - Given `center`, `from`, `to` draws an arc between `from` and `to` --- ## Changelog > This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section. - Added: `Gizmos::arc3d(&mut self, angle)` method - Added: `Gizmos::long_arc_3d_between(&mut self, center, from, to)` method - Added: `Gizmos::short_arc_3d_between(&mut self, center, from, to)` method --- This PR factors out an orthogonal part of another PR as mentioned in [this comment](bevyengine#11072 (comment))
Objective
Solution
arc_3d
arc3d
method on gizmos only takes an angleVec3::X
, in the XZ plane, in counter clockwise direction with a normal that is facing upshort/long_arc_3d_between
center
,from
,to
draws an arc betweenfrom
andto
Changelog
Gizmos::arc3d(&mut self, angle)
methodGizmos::long_arc_3d_between(&mut self, center, from, to)
methodGizmos::short_arc_3d_between(&mut self, center, from, to)
methodThis PR factors out an orthogonal part of another PR as mentioned in this comment