@RIL (Rolf) posted a new topic, subject "[GH Bug]: Find the "edge" of a point cloud with _CrvThroughPts". It read:

   **Edit:** The last post in this thread describes a bug in the GH component `PointInBrep`. Since I wrote these posts I have come across the same bug several times. It ruins my every attempt to “auto-fit” simplified geometry on irregular mesh surfaces. Showstopper. (ping, @DavidRutten).  
      
      
      
    
    
    * * *
    
    As said in the header, I have a slightly curved surface with an area of points (start points of a mesh triangle normals) with very irregular outer boundaries (see picture) and I want to draw a curve through the “outmost” points on this “surface-point-cloud” (to be used as a “cutting wire” to cut out a similar area out of the sphere).
    
    What approach to take to collect the outmost points, in draw order, so I can connect those points into a closed curve?
    
    image.png712×651 87.2 KB
    
    // Rolf

Then @Helvetosaur said

    Dunno…
    
    Pick a view plane  
    Project the point collection to the plane  
    ConvexHull the projected points  
    Extrude the convex hull in the plane perpendicular direction to trim the sphere…  
    ?
    
    –Mitch

To which @RIL (Rolf) replied

    Helvetosaur:
    
    > ConvexHull the projected points
    
    I tried ConvexHull, but the points are in such a “disorder” that the surface is like a towel thrown on the floor (double folded). But I managed to reconstruct the mesh, by “back tracking” the mesh normals that these points came from in the first place, like so:
    
    … ending up with this geometry:
    
    image.png581×534 58.3 KB
    
    (where the two specks come from I have no idea). From here I can probably extract the mesh boundary using Kangaroo's “Naked Vertices” component :
    
    Then I will (hopefully) end up with the boundaries of the two areas. But then what?   
    (The two areas should be only one area, again, via closest points).
    
    I would also need to smooth out the spiky edges, which is due to the points the surface was made out of in the first place, so that precision is not very tight.
    
    // Rolf

So @Helvetosaur replied

    RIL:
    
    > I tried ConvexHull, but the points are in such a “disorder” that the surface is like a towel thrown on the floor (double folded)
    
    ConvexHull shouldn't care about order… It should just make a closed polyline. You use that to trim your sphere. --Mitch

To which @RIL (Rolf) replied

    Helvetosaur:
    
    > ConvexHull shouldn't care about order… It should just make a closed polyline.
    
    Ah yes, I conflated it with some of the other components. For some reason the ConvexHull (red line) ends up far off the actual edges. This is what I get, compared to the reconstructed mesh:
    
    image.png832×775 84.7 KB
    
    It seems that the ConvexHull logic gets trapped by a peripheral speck, and so the boundary gets totally distorted.
    
    // Rolf

Then @RIL (Rolf) said

    RIL:
    
    > It seems that the ConvexHull logic gets trapped by a peripheral speck
    
    I guess I need to get rid of the two disturbing specks first of all. But the strange thing is that I collect the points by performing an intersect of lines directed towards a sphere, and then filter away a zillion lines that does not intersect.
    
    But still there are two lines kept _which are not intersecting with the sphere_ , and these two lines causes problems.
    
    But where do they come from? How did they slip through the filtering? See the two “stray” lines marked with red rings:
    
    image.png484×658 61.8 KB
    
    The filtering of the lines (or their end points) was done using with a script component with the code shown below this picture, and that's all.
    
    So now, how could these two “specks” have survives since they clearly do not intersect with the sphere, and their end points should have been marked as “false” (by the “ _inside Brep/Sphere_ ” component) and thus filtered away in my script component (“KeepFilter”) with the following code:
    [code] 
        i = 0
        Pts = []
        if pt_list:
            for k in keep:
                if k:
                    Pts.append(pt_list[i])
                i += 1
        
    [/code]
    
    I mean, either the error comes from the “point inside Brep” (the sphere) or there's a flaw in the code above.
    
    // Rolf

After which, @Helvetosaur added

    The keep code looks OK, but it's not necessary to write a python script for that, the PointInBrep component will generate a True/False list and you can use the dispatch component and the True/Talse mask created by PointInBrep to filter the original point list into “inside” and outside".
    
    So possibly PointInBrep is generating a false positive, otherwise there's an error somewhere else.
    
    –Mitch

After which, @RIL (Rolf) added

    Helvetosaur:
    
    > d you can use the dispatch component
    
    Ah, thääänks for the Dispatch component, which is about 100 times faster than the Python code:
    
    However, the result is still det same, two “speck” lines remains, so it seems that the `PointInBrep` fails somehow. Hm.
    
    * * *
    
    **Edit** :  
    So all in all, it seems that there's a bug in the `PointInBrep` component. Something for @DavidRutten to look at? For David's convenience I repeat the relevant pictures demonstrating the two strange point results from the PointInBrep (clearly none of the line ends are inside the Sphere, but they are still reported as being inside):
    
    The filtering is simple, and deals with 59031 input points, keeping 751 start/end-points each, which is two points too many :
    
    Using a drawbar & ListItem I could spot the two erroneous lines to index 0 and 654 (out of 751), which probably says nothing about the cause, but anyway.
    
    // Rolf


{'source': 'discourse', 'url': 'https://discourse.mcneel.com/t/gh-bug-find-the-edge-of-a-point-cloud-with--crvthroughpts/45050', 'title': '[GH Bug]: Find the "edge" of a point cloud with _CrvThroughPts', 'views': 2219, 'has_accepted_answer': False, 'word_count': 1030, 'like_count': 0, 'reply_count': 6, 'participant_count': 2, 'posts': 8, 'tags': '', 'author': '@RIL (Rolf)', 'participants': '@RIL (Rolf), @Helvetosaur', 'image_url': ['//global.discourse-cdn.com/mcneel/original/3X/f/5/f50952292a41c27d348a57146ffab86a80f8c98f.png'], 'created_at': '2017-06-16T13:16:53.558Z', 'last_posted_at': '2017-06-16T17:00:20.631Z'}