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?
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…
?
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:
(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.
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:
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:
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:
i = 0
Pts = []
if pt_list:
for k in keep:
if k:
Pts.append(pt_list[i])
i += 1
I mean, either the error comes from the “point inside Brep” (the sphere) or there’s a flaw in the code above.
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.
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.
