-
Notifications
You must be signed in to change notification settings - Fork 33
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
CG/CG_elem: rework point/plane intersection evaluation #427
Conversation
src/CG/CG_elem.cpp
Outdated
array3D xP; | ||
if ( intersectLinePlane(Q1, n, P2, n2, xP, distanceTolerance) && intersectPointSegment(xP, Q1, Q2, distanceTolerance) ) { | ||
P = xP; | ||
if ( intersectLinePlane(Q1, n, P2, n2, P, distanceTolerance) && intersectPointSegment(P, Q1, Q2, distanceTolerance) ) { |
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.
From documentation:
P intersection point if intersect, else unaltered
With this modification it will be altered even if there is no actual intersection between plane and segment, but only between line and plane, @ksamouchos isn't 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.
Correct! I have to change the documentation as well. This change has only to do with personal preferences. So, if you don't agree, I can retrieve the initial behavior of the function.
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 change doesn't seem related to the bug you are fixing. Please move it to another commit.
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 leave the function as it was. Let's not change the public API without a valid reason.
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 the change is not really needed for some reason, for compatibility issues on possible applications using this function, personally, I'd keep the original behavior.
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.
Done!
c862962
to
bfe60cb
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.
Before merging please change the commit message from "CG/CG_elem: ..." to just "CG: ...". You should be able to that directly from GitHub ("Squash and Merge").
if(distancePointSegment(P, P1, P2) > distanceTolerance){ | ||
return false; | ||
} | ||
array3D xP = projectPointSegment( P, P1, P2 ); |
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.
What's the difference w.r.t. the old implementation?
Does not distancePointSegment function the same computation?
double distancePointSegment( array3D const &P, array3D const &Q0, array3D const &Q1) { array3D xP = projectPointSegment( P, Q0, Q1); return norm2(P-xP); }
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.
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.
But you may be right, distancePointSegment seems the function that contains the bug.
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 @edoardolombardi is right, but I still see different (and more correct) results in immerflow with the new implementation. I have to investigate more to see what's going on.
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.
To have an exact match between the two implementations, the updated one should check for "<=" rather than for just "<". However, I don't think this will make any difference for your test case.
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 studying a case where a plane is almost intersecting a segment. The distance of the projection point P from the segment edge P2 (see above figure) is of order 10^-20. In that case, the order of operations plays a significant role. So, bitpit and an algorithm I've developed to compute intersections were giving me contradictive results. That's why I got this false alarm.
Since bitpit is not wrong, I suggest not to merge this branch and cancel the pull-request. I can continue my work by changing the tolerance used in bitpit to compare distances.
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 pull request is still worthwile:
- there is a new function (intersectPointLine);
- the tests are improved;
- the function intersectPointSegment is marginally faster (there is one less square root).
If you could split it in three commit, we can still merge it. Something like that:
- CG: introduce a function to evaluate line-point intersections
(This first commit will also introduce the tests for that function) - CG: improve the tests that check point intersections
- CG: micro optimize the function that evaluates line-segment intersections
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.
(Please also replace the < with a <= to make the results as close as possible to the previous implementation.)
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! I did what you asked.
bfe60cb
to
64b8a58
Compare
64b8a58
to
c050f42
Compare
This pull request:
This pull-request completes task IMM-728.