In theory the only big problem with my approach that I'm aware of is the lack of precision in creating accurate numerical serial codes from each piece of geometry. Because it sorts the geometry by the serial number, theoretically you shouldn't need any sort of loop - this should catch multiple duplicates just as well as single ones.
I was thinking about your particular situation - that of edges generated by neighboring polygons. I think in this case the definition can be simpler - rather than working with two endpoints, I think analyzing midpoints should suffice. I posted an example definition - "select unique lines neighboring polygon edges.ghx." I did a test on the exploded wires of a bunch of subsurfaces, and it caught all the lines the "select duplicate" command did. Hope this helps... Andrew On Apr 23, 5:32 pm, oompa_l <[email protected]> wrote: > thanks for that. I am having trouble understanding it...It worked when > I drew thre lines over top of one another....I got a boolean pattern I > could use. But in a file with 300+ curves with many duplicates it's > not fairing as well. It looks like you are just shifting the list and > comparing each line to the one adjacent to it in the list - is that > right? that doesn't work in my scenario. I was trying to write a > script to do this which would have an outer and inner for loop cycling > through each line and comparing its start and end vertices but I > didn't get very far....I imagine that implementing your idea of an > identifiable key and the two loops - comparing each piece to every > other piece - would work....now how to do it, is another things I > guess.... > > thanks for the help
