-
-
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
separating finite and infinite 3d planes #12426
separating finite and infinite 3d planes #12426
Conversation
8777395
to
a2db276
Compare
Nice work! Need to rename the existing |
c74af27
to
4bba2a5
Compare
So in the end the decision was to use Plane3d for a finite and InfinitePlane3d for an infinite plane, so all the confusing naming convention with the rectagnle is gone now :) |
let normal = Dir3::new((b - a).cross(c - a)) | ||
.expect("plane must be defined by three finite points that don't lie on the same line"); | ||
let normal = Dir3::new((b - a).cross(c - a)).expect( | ||
"infinite plane must be defined by three finite points that don't lie on the same line", |
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.
Use of "infinite" in error for finite plane.
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.
Good catch, this is fixed now.
4bba2a5
to
58727bb
Compare
This should be ready for final review |
I suspect this is the base of the upcoming work to have infinite plane meshes? |
Yes, I'll try to review this soon. I've had less time for reviews lately. |
@@ -21,7 +21,7 @@ impl Bounded3d for Sphere { | |||
} | |||
} | |||
|
|||
impl Bounded3d for Plane3d { | |||
impl Bounded3d for InfinitePlane3d { |
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.
This seems wrong. Why would an infinite plane have bounds?
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.
Semantically I agree, but it can still be useful to be able to compute the AABB for collision detection purposes. You would still want planes (and half-spaces) to be included in BVHs for example. Or you could have a Shape3d
trait that requires Bounded3d
.
For reference, Parry's HalfSpace
has AABB methods
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'll grant that, and it makes more sense looking at the actual impl. I consider this resolved.
/// A bounded plane in 3D space. It forms a surface starting from the origin with a defined height and width. | ||
#[derive(Clone, Copy, Debug, PartialEq)] | ||
#[cfg_attr(feature = "serialize", derive(serde::Serialize, serde::Deserialize))] | ||
pub struct Plane3d { |
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 would be concerned about changing the semantics of a public type like this, but this just changes it back to what it was before right?
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.
The original Plane
in bevy_render
was bounded (but had no configurable normal and was always facing +Y), but the Plane3d
primitive was always unbounded.
If we want to split it into a finite plane and and an infinite plane though, then I think this semantic change is kinda unavoidable, unless we instead name this something like FinitePlane3d
or BoundedPlane3d
, but that might be less user-friendly
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.
Agreed. We just need to highlight it really clearly in the migration notes.
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 there is no code change required by this one then, correct?
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.
Correct
pub fn new(normal: Vec3) -> Self { | ||
Self { | ||
normal: Dir3::new(normal).expect("normal must be nonzero and finite"), | ||
} | ||
} |
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.
pub fn new(normal: Vec3) -> Self { | |
Self { | |
normal: Dir3::new(normal).expect("normal must be nonzero and finite"), | |
} | |
} | |
pub fn new(normal: TryInto<Dir3>) -> Self { | |
Self { | |
normal: normal.try_into().expect("normal must be nonzero and finite"), | |
} | |
} |
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.
Sorry, the suggested change here produces an error, I am curious what is the driver behind this suggestion?
I think other methods also expect a Vec3 so I wouldn't change just one's signature.
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.
If you have a Dir3
this will do a redundant conversion to and from a Vec
. It looks to me like this is the only place a vector is taken as a parameter and immediately converted into a Dir3
.
It's fine either way. What's the error?
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.
Ah, it should be impl TryInto<Dir3>
. Well anyway it's not super important.
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.
pub fn new(normal: Vec3) -> Self { | |
Self { | |
normal: Dir3::new(normal).expect("normal must be nonzero and finite"), | |
} | |
} | |
pub fn new(normal: impl TryInto<Dir3>) -> Self { | |
Self { | |
normal: Dir3::new(normal).expect("normal must be nonzero and finite"), | |
} | |
} |
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.
@NthTensor Sorry, I missed your comments here. Thank you for the explanation!
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.
@alice-i-cecile This is now addressed!
@@ -7,39 +7,32 @@ use crate::{ | |||
}; | |||
|
|||
/// A builder used for creating a [`Mesh`] with a [`Plane3d`] shape. | |||
#[derive(Clone, Copy, Debug)] | |||
#[derive(Clone, Copy, Debug, Default)] | |||
pub struct PlaneMeshBuilder { |
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.
If this just wraps Plane3d
, can't we remove it?
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.
Right now, we could, but we should probably add subdivisions back in a follow-up, so it'll be needed for that
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.
Sounds good.
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 your patience, I know this took me a while to get to. There's a few things I think we need to fix and double check before this is ready for merge, but it's a big improvement already, and it's in very good shape generally.
Great job!
Thanks for reviewing! I have resolved the merge conflict as well, just awaiting your thoughts on my replies! :) |
ece914c
to
e8e3c67
Compare
e8e3c67
to
1c0d228
Compare
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.
Looks like my feedback last week wasn't super helpful. Sorry about that, and thanks for the clarifications.
Happy to approve this now, looks good.
This should be ready for merge @alice-i-cecile |
I think we need another approval first. Maybe @Jondolf can give it a look? |
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 the TryInto API is meaningfully nicer: I've left a corrected suggestion on how to do this. Once that's done though I'm happy to merge :)
I'm going to go ahead and mark this as ready for final review, given Alice's conditional approval has been addressed. |
It looks like your PR is a breaking change, but you didn't provide a migration guide. Could you add some context on what users should update when this change get released in a new version of Bevy? |
Addresses Bevy #12426 (bevyengine/bevy#12426)
Addresses Bevy #12426 (bevyengine/bevy#12426)
Objective
Fixes #12388
Solution