Hi I couldn’t get the Member Index to work because of data type issues so I cheated and converted inputs to vectors, there must be a better way?
Test.gh (34.6 KB)
I usually just convert to text.
Your result here (1733 lines) is identical to what I posted five days ago, with MUCH LESS CODE:
Surely there are decimal differences in the coordinates of the vectors, try to limit their precision or use another method such as ClosestPoint if you can.
Depends on tolerance settings (CullPt ‘T’), which are debatable. I find my simpler code to be more verifiable than all the pieces you have assembled.
P.S. Try increasing the ‘Cube edge length’ which also affects tolerance.
P.P.S. Your two Data Dam components get in the way of comparison unless both are triggered.
Compare it to Kanagroo’s dupLn (removeDuplicateLines, yellow group) using the same tolerance and/or ‘Cube edge length’. I’m satisfied.
cull_lines_2021Apr28a.gh (15.2 KB)
Way faster too.
True, bur unfortunately doesn’t pick up intersections when they occur far enough away from midpoints. Increasing the tolerance on cull pt to that extent will probably bring in start and end points.Plot.pdf (249.5 KB)
I need to be able to vary cube edge length and consider various sizes. I know about the data dam components they are there so that GH doesn’t freeze when handling large number of points.
I know why they are there.
Your code doesn’t match Kangaroo’s dupLn (removeDuplicateLines) at all, so there’s the rub, eh? dupLn also happens to be much faster than your code.
dupLn doesn’t pick up the intersecting lines like the code Jakinta shared with me and is incorporated in my script as is a bit of code by David. I don’t understand why you are so confrontational, this is meant to be a help forum not some sort of competition.