The parallel version seems pretty fast, you could maybe test end points and mid point. Of course there could be a false positive for that as well but will be much less likely.
1 Like
In the example by @RadovanG, one end point (the one to the left) would return a false positive. Perhaps mid-point and a random parameter between 0.1…0.9 along the edge… 
And an input “DeepScan” for this more extensive test to make this optional (when having huge numbers of surfaces).
// Rolf
1 Like
In the example by @RadovanG, one end point (the one to the left) would return a false positive.
True, or maybe to test against verts instead of edges.
Maybe approach like this:
- first step - try to join surfaces into polysurface/s (set up Rhino-tolerance to desired value)
- after that identify naked edges in those polysurface/s and process only them by an algorithm that should mark potential “Orphan-edge”
- such algorithm is probably specific for particular production process, but that is true in every real-life application - it should be coded, tested, fine-tuned, …
Good idea!
I had actually already tried (almost) this approach, but I wasn’t smart enough to only “collect” those naked edges and then quickly explode the surfaces again. (therefore silly me tested the edge point against the joined (poly)surface, in which case the ClosestPoint() test will only hit “self” (the surface owning the edge) within tolerance, which is a false positive. Sigh.
Saving this idea for “next major version”, anyone?
I just finished a simpler “DeepScan” option testing at t = 0.2493 (an “unlikely number”) in a second “deeper” test if the first one thinks it’s not an orphan (and if DeepScan option is ticked). Good enough for now.
Fig 1 This code was added to take care of the “RadovanG Special Case” ( ) pictured in Fig 2. below:
Fig 2. Pictured is your special case in which the mid point failed with a false positive, which now is tested “deeper” and found to be an orphan:
The GH definition:
Find_Orphan_Edges_V3_Parallel DeepScan.gh (32.6 KB)
// Rolf
1 Like
I tried to join the breps in order to collect only naked edges to test for OrphanedEdges, but, I ran into new problems: I find too many “split-edges”, which I assume is caused by the Join operation, and also partly connected edges are now considered not connected at all (for example edge b pictured below).
Fig 1. The edge-segments which I don’t want, which were not a problem before joining the breps (see earlier posts), are edge a, b and c (a and b-c should not have been “split”) and also e should not have been a “naked edge” candidate at all. In short; No “part-naked” or part-connected edges are wanted, but here they are.
I failed to find a way to identify “part-naked” or “part-connected” edges (segments split along a full length surface edge), so if anyone can give a hint about how to identify such segments I’d be happy.
Things I have tried which failed to indicate split edge-segments are commented away in this code snippet:
// Rolf
Can the surfaces in your models be joined into closed polysurfaces? In general a closed polysurface can be created from any set of surfaces with all edges adjacent to one and only one other edge.
He has a problem with just that:
However, I have tried to join the surfaces internally in the component, just to find (only) the naked edges (as per @RadovanG’s suggestion) in order to reduce computation time, but that gives other problems. So far separate surfaces works best, although it’s not the fastest.
Working with joined breps reduces computation time to ~1/4, but the result is not as accurate as with the separate surfaces.
// Rolf
V4 using Joined Breps to speed things up.
This version is 4 times faster than “V3 Parallel” due to collecting only naked edges as per RadovanG’s suggestion.
When I know how to Merge the edge segments into full length edges, this algorithm can be enhanced to produce a lesser number of redundant and irrelevant edges, but I post it here anyway in the hope that it’s useful and/or can be enhanced by some smarter brains out there.
I include also the test cases I have used, which is 1095 surfaces which computes in ~450 ms (instead of ~4sec for the previous V3 version:
* Find Orphaned Edges.3dm.zip (1.7 MB)
* Find_Orphaned_Edges_V4_Parallel_DeepScan_Quicker.gh (37.9 KB)
// Rolf
Another reason we can’t join the models to make them closed polysurfaces is because we need the different coloured surfaces to be present in the CAM software. We use colours to indicate important features so that the CNC programmer knows which areas of the model need to be within tolerance, and which areas he can hustle on to reduce machining time.
Thanks,
Dan
So maybe like this:
0. List surfacesA = … original SEPARATE SURFACES
- Join surfaces(breps) into brep/s (with given tolerance, toleranceB), Brep brepsB = … resulting breps
- Find naked edges of breps, Curve nakedEdgeCurvesB = … breps’ naked edges
- Find mid-points of nakedEdgeCurves, Point3D midPointsB = … mid-points
- FIND all edges of SEPARATE SURFACES surfacesA whose minimum distance to “pointcloud” midPointsB is LE (less.or.equal) to toleranceB.
Such edges are potential naked/orphan edges, so you will process only them,
List potentialOrphanEdges = … edges to process
Step 4 is simple algorithm for finding “full length edge” that segment edge can belong to (more “full length edges” can be found but it is important that the right one will be among them).
Algorithm in 4. can be expanded with additional checks, but I would at the beginning start with surfacesA.Edges vs mid-point distance check…
Yes, having different colors in a brep would be useful …
But if you only have to check the edges, you could make a copy, or also joining, checking the edges and then undoing …
But it sounds like the CAM software doesn’t support the Rhino sub-object materials (?)
-wim
FYI: Perhaps you already noticed it but just in case; Although the V4 version joins the surfaces, it does so only on internal copies (while finding naked edges), therefore it doesn’t touch the original surfaces at all. As for me I totally get that joining the Breps would mess up the coloring and layers and… everything.
Hm, not sure I follow your description. Does it differ from the idea I had to simply test if the midpoint of any (joined brep) edge-segments lays on any of the free separate surface’s full edges (mid point distance = 0 to the full length edge) and then simply pick that full edge up? (Dupes may occur but can be filtered away from the candidate edge list list before the final test).
// Rolf
Hi Emilio,
I think I will have time to start working on this project this week. I’ll keep this suggestion in mind. There are often other naked edges so that might be a factor, but I’ll see. There’s been a very interesting discussion on this topic, so I have a lot to study here.
Thanks,
Dan
1 Like