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

[filters] CropHull unexpected number of intersections #3912

Open
cdel2 opened this issue Apr 13, 2020 · 5 comments
Open

[filters] CropHull unexpected number of intersections #3912

cdel2 opened this issue Apr 13, 2020 · 5 comments
Labels
kind: bug Type of issue module: filters needs: testing Specify why not closed/merged yet

Comments

@cdel2
Copy link

cdel2 commented Apr 13, 2020

Context
I am using CropHull to test if a single point is inside the hull of a sphere. In applyFilter3D(PointCloud &output) function of crop_hull.hpp, I get unexpectedly high number of intersections for the given point.

Here is what I added to the function (using this fix) :

    bool isPointInsideHull = (crossings[0]&1) + (crossings[1]&1) + (crossings[2]&1) > 1;
    if ((crop_outside_ && isPointInsideHull) || (!crop_outside_ && !isPointInsideHull)) {
      cout << "crossing ray 0 : " << crossings[0] << endl;
      cout << "crossing ray 1 : " << crossings[1] << endl;
      cout << "crossing ray 2 : " << crossings[2] << endl;

      cout << "point is inside hull !-------------------------------------------------------------- " << endl;
      this_thread::sleep_for(10000ms);
      output.push_back (input_->points[(*indices_)[index]]);
    }

Current Behavior
This is the resulting number of intersections I got for each ray :

crossing ray 0 : 1405                                                                                                   
crossing ray 1 : 1407                                                                                                   
crossing ray 2 : 1397 

Expected behavior
I expected crossings array to contain either 0 (no intersection, possibility that the point is outside), 1 (1 intersection, possibility that the point is inside) or 2 values (2 intersections, possibility that the point is outside of the sphere).

To Reproduce
I use PCL 1.8.0 on Windows 10. Here is the link to the files used :

  • polygon.ply contains the hull information
  • unit_test.ply is the input point cloud we want to test

@taketwo @kunaltyagi

@cdel2 cdel2 added kind: bug Type of issue status: triage Labels incomplete labels Apr 13, 2020
@kunaltyagi
Copy link
Member

There's no need to tag the maintainers on the issues.

@SergioRAgostinho SergioRAgostinho added module: filters and removed status: triage Labels incomplete labels Apr 14, 2020
@kunaltyagi
Copy link
Member

As per the code, crossings[ray] is the number of polygons a particular ray from the point in question intersects.

If a ray intersects with an even number of polygons, it is outside the hull, else it is inside. I don't see where this number would be limited to 0, 1 and 2 for a concave hull. If the hull was convex, then it's a bug to have such a high number of crossings.

Could you replicate this issue using 1 point and a simple hull?

@kunaltyagi kunaltyagi added the needs: author reply Specify why not closed/merged yet label Apr 14, 2020
@cdel2
Copy link
Author

cdel2 commented Apr 15, 2020

The hull I made is from the point cloud of a sphere so wether it is convexe or concave has no importance here. Turned out however that I had a few self intersecting faces, which explained why I could have more than 2 intersections per point. I did the same test with a hull having no self-intersection (checking with blender that geometry is manifold). I uploaded a file convex_hull.ply which contains this hull.

I still get the following result for the same point :

crossing ray 0 : 37
crossing ray 1 : 23
crossing ray 2 : 121

@kunaltyagi kunaltyagi removed the needs: author reply Specify why not closed/merged yet label Apr 15, 2020
@stale
Copy link

stale bot commented May 19, 2020

Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.

@stale stale bot added the status: stale label May 19, 2020
@kunaltyagi
Copy link
Member

I tried to debug the issue and came with with no sane reason why this is happening

@stale stale bot removed the status: stale label May 21, 2020
@kunaltyagi kunaltyagi added the needs: testing Specify why not closed/merged yet label May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug Type of issue module: filters needs: testing Specify why not closed/merged yet
Projects
None yet
Development

No branches or pull requests

3 participants