Skip to content
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

Merged
merged 8 commits into from
Apr 18, 2024

Conversation

andristarr
Copy link
Contributor

Objective

Fixes #12388

Solution

  • Removing the plane3d and adding rect3d primitive mesh

@andristarr andristarr force-pushed the adding-rect3d-primitive branch 5 times, most recently from 8777395 to a2db276 Compare March 13, 2024 14:13
@TrialDragon TrialDragon added C-Feature A new feature, making something new possible A-Rendering Drawing game state to the screen A-Math Fundamental domain-agnostic mathematical operations labels Mar 15, 2024
@NthTensor
Copy link
Contributor

NthTensor commented Mar 17, 2024

Nice work! Need to rename the existing Rectangle primitive to Rect2d I think. Thoughts on adding Rotation2d to Rect3d to rotate the plane around it's normal? With transforms it's in for a penny in for a pound.

@andristarr andristarr force-pushed the adding-rect3d-primitive branch 8 times, most recently from c74af27 to 4bba2a5 Compare March 17, 2024 20:34
@andristarr
Copy link
Contributor Author

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 :)

@andristarr andristarr marked this pull request as ready for review March 17, 2024 20:45
@andristarr andristarr changed the title adding the rect3d primitive separating finite and infinite 3d planes Mar 17, 2024
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",
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@andristarr
Copy link
Contributor Author

This should be ready for final review

@andristarr
Copy link
Contributor Author

I suspect this is the base of the upcoming work to have infinite plane meshes?

@NthTensor
Copy link
Contributor

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 {
Copy link
Contributor

@NthTensor NthTensor Apr 7, 2024

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?

Copy link
Contributor

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

Copy link
Contributor

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.

Comment on lines +70 to 73
/// 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 {
Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor Author

@andristarr andristarr Apr 8, 2024

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

Comment on lines 156 to 160
pub fn new(normal: Vec3) -> Self {
Self {
normal: Dir3::new(normal).expect("normal must be nonzero and finite"),
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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"),
}
}

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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"),
}
}

Copy link
Contributor Author

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!

Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

Copy link
Contributor

@NthTensor NthTensor left a 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!

@andristarr
Copy link
Contributor Author

Thanks for reviewing! I have resolved the merge conflict as well, just awaiting your thoughts on my replies! :)

@andristarr andristarr force-pushed the adding-rect3d-primitive branch 2 times, most recently from ece914c to e8e3c67 Compare April 8, 2024 17:13
Copy link
Contributor

@NthTensor NthTensor left a 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.

@andristarr
Copy link
Contributor Author

This should be ready for merge @alice-i-cecile

@NthTensor
Copy link
Contributor

I think we need another approval first. Maybe @Jondolf can give it a look?

Copy link
Member

@alice-i-cecile alice-i-cecile left a 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 :)

@alice-i-cecile alice-i-cecile added this to the 0.14 milestone Apr 15, 2024
@NthTensor
Copy link
Contributor

I'm going to go ahead and mark this as ready for final review, given Alice's conditional approval has been addressed.

@NthTensor NthTensor added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Apr 18, 2024
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Apr 18, 2024
Merged via the queue into bevyengine:main with commit 2b3e334 Apr 18, 2024
28 checks passed
@BD103 BD103 added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Jul 6, 2024
Copy link
Contributor

github-actions bot commented Jul 6, 2024

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?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

zhaop added a commit to zhaop/bevy_editor_pls that referenced this pull request Jul 7, 2024
jakobhellermann pushed a commit to jakobhellermann/bevy_editor_pls that referenced this pull request Aug 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Math Fundamental domain-agnostic mathematical operations A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adding a FlatSurface or Rect3d
6 participants