-
Notifications
You must be signed in to change notification settings - Fork 1.5k
PMP: Polyline Snapping #2883
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
base: master
Are you sure you want to change the base?
PMP: Polyline Snapping #2883
Conversation
For which release do we want this PR? 4.12 or 4.13? |
It's honestly no rush at all, so unless @sloriot (or you) can do a review and that the testsuite looks good soon enough for 4.12, it can easily be postponed to 4.13. |
Warnings:
Maybe have a look at the other columns, because there might be other warnings: |
@lrineau I see you push it to the testsuite (there are warnings I'm going to take care of). Do you want this to be in 4.12? As I said, I don't mind waiting for 4.13 for this. |
d1261b2
to
ccec5d6
Compare
We said we would try to push it in CGAL-4.12. So I included it. |
Testsuite looks good. |
if (const Point_3* p = boost::get<Point_3>(&*intersection0)) | ||
p0 = *p; | ||
else | ||
return false; |
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 don't know what the function is supposed to do but I'm surprized you return false in case the segments are coplanar and collinear
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 don't see any specific treatment for:
- segments smaller that threshold
- consecutive segments (thus sharing a common endpoint)
Are those cases not an issue?
|
||
Point_3 to_exact(const Inexact_point_3& p) const | ||
{ | ||
return Point_3(p.x(), p.y(), p.z()); |
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 Cartesian_converter
} | ||
Inexact_point_3 to_inexact(const Point_3& p, const Exact_to_double& etd) const | ||
{ | ||
return Inexact_point_3(etd(p.x()), |
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 Cartesian_converter
|
||
public: | ||
|
||
Exact_snapping() |
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.
useless
if (exact_snapping<Exact_kernel> (exact_s0, exact_s1, result)) | ||
return std::make_pair (to_inexact (result, exact_to_double), true); | ||
|
||
return std::make_pair (Inexact_point_3(), false); |
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.
not sure it's worth is but it seems that exact_snapping
should return an optional<Point_3>
. I agree that you then have the conversion issue so maybe it is already the best choice.
polylines[b->info().first][b->info().second + 1]); | ||
Segment_3 s2 (polylines[c->info().first][c->info().second], | ||
polylines[c->info().first][c->info().second + 1]); | ||
if (CGAL::squared_distance (s1, s2) > squared_tolerance) |
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.
aren't you somehow doing twice the job with exact_snapping.intersection()
? I mean couldn't you use new_point
directly?
|
||
|
||
// Note this is not officially documented | ||
/*! |
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 this will show up in the documentation if ! is here. Anyway if not documented, the function should move in the experimental
namespace.
I have temporarily added the label "not yet approved", to avoid that I accidentally merge this PR, before the discussion between Sébastien and Simon is over. |
After a discussion with @sgiraudot, we have decided to postpone the test of this PR for CGAL-4.13. To be done:
Maybe Simon you want to add things. I think we should in the end modify the first message of the discussion, with a summary of the to-do list. |
@sgiraudot Have a look whether you want to refresh this PR and have it tested for CGAL-4.13. |
I don't think I'll have time to do the work that has to be done (summed up in your message of March 22nd) before the release, so we should probably postpone it. |
Ok, let's postpone it then |
Conflicts |
d08e032
to
2d893c4
Compare
I rebased the branch and did some more work on it:
Actually, it is really difficult to figure out a way to deal with all possible cases. The problem seems ill-posed, as the same polyline set will give very different results depending on how densely it's sampled: it seems we should consider polylines as a linear distribution and not a set of segments, otherwise we are dependent on vertex densities/positions. But on the other hand, I don't see an easy way to do it without the points. Handling collinear segments gives also a sort of instability: two segments almost collinear would snap at 1 point, but as soon as they become collinear, they should snap as a common segment? Depending on how the handle proximities, we can also get quite different outputs, see this coplanar example: There does not seem to be a right answer. If you start considering cases where N polylines might snap at the same location with a combination of degenerate cases, it quickly becomes a nightmare. In all cases, we also have the problem that applying the algorithm several times would sequentially collapse the polylines onto each other, which is not the case with non-degenerate cases (that would remain stable). I'm wondering if we should not just make it a precondition that no segments are collinear/coplanar (or use random perturbations to make sure of that), but that might be too restrictive. |
Problems in license :
|
Summary of Changes
This introduces an internal non-documented function to snap a set of polylines under a user-specified tolerance. I also put a test and a plug-in for the demo.
Release Management