Do solids' edge vectors get slightly altered after booleans? (Orthogonal line sorting problem.)

Grasshopper
1

I made a cluster that sorts orthogonal and diagonal lines into X, Y, Z orthogonals and XY, XZ, YZ and XYZ diagonals.

It seems to work perfectly on lines I draw manually using ortho snap.
It also works fine on lines that I derive from the edges of boxes (X lines in white):

Cubes
Cubes1014×986 164 KB

When I do a boolean union of the boxes, either in Rhino or in Grasshopper, some of the edge lines of the resulting solid don’t sort properly (note a couple white X lines are missing).

Post%20Boolean%20X
Post%20Boolean%20X1014×985 146 KB

The missing lines above that should be sorted as X orthogonal lines get recognized as diagonal lines (the white lines here are from my XZ diagonals output.)

Post%20Boolean%20XZ
Post%20Boolean%20XZ1036×964 139 KB

Here’s the definition, with some stream filters added to make it easy to compare the problem condition to a condition where it all works.

Sort Lines XYZ Troubleshoot.gh (42.0 KB)

And here’s the Rhino file all the geometry comes from:
xyz intersections.3dm (190.4 KB)

Is this a tolerance issue in my sorting definition?
I tried playing with different tolerances but it didn’t help.
Or is it a document tolerance problem?
I tried changing document tolerance and redoing the booleans. Didn’t help.
Or have I overlooked something in the structure of the definition?

What am I missing here? Any suggestions much appreciated.

-Max

2

Update, I’ve baked the lines that aren’t behaving correctly, used the What command on them in Rhino, and they sure look like they’re truly orthogonal.

Have I found a bug?

3

Could it be a rounding issue?
Is your mesh in GH the same as in Rhino?

4

I can set mesh in GH? BRB, gonna go look that up.

5

did you come across the “Edges from directions” component for your breps? It’s easy to sort with breps that are orthogonal.

Is this similar to what you’re after?
Sort Lines XYZ Troubleshoot.gh (45.1 KB)

image
image1469×680 77.9 KB

6

Thanks! This is perfect! You actually went beyond what I needed here.

The “edges from directions” component is all I needed. It just works.

I’m still curious why my homemade sorter fails here. It works in all other situations, but since there’s another solution in this situation, my issue is solved.

The lines in the background are there because I’m working out a definition that sorts all the different ways orthogonal lines can intersect. I don’t actually need to isolate them from the Brep edges. I’ll post that in another thread. Hopefully that sorter is not also something that exists as a single component. I mean, it would be super convenient, but also I would have spend a bunch of time on something that already exists.

7

My initial suspicion was that positive vs negative directions were the root, but then I remembered the component and did not even look again haha :sweat_smile:

Best

8

Hmm. I have a second little cluster that merges and consolidates overlapping lines and then flips them to all the same direction. I’ll try putting that in front and see if it changes anything.

9

It gets weirder:
Baked lines from the “edges from directions” component work.
The edges from “duplicate edges” in rhino don’t work.

10

Update:

The glitch was due to using many instances of the similarity component. I replaced it with the “equality with tolerance” component, set to document tolerance, and everything now works.

1 Like