Delete overlapping curves of one collection of curves

Replies to This Discussion

Permalink Reply by Joseph Oster on September 9, 2015 at 9:12am

Permalink Reply by daniel assayag on September 9, 2015 at 11:20am

did i miss something?

can you please maybe join your def?

crv->boundary surfaces>Solid Union>Brep Edges> Custom Preview

Permalink Reply by daniel assayag on September 9, 2015 at 12:12pm

Well it does work by flattening the crv or the boundary.

But as i have thousands of curves, every change takes 5 minutes at least.. 

Is the another method, maybe without using boundary surface?

Permalink Reply by Joseph Oster on September 9, 2015 at 12:15pm

Did my attached code get lost?  Sorry.  Trying again...

"flattening the crv"?  I'd have to see your curves but maybe 'Join' curves to make boundaries instead of flattening a tree/list?

Attachments:

• overlap_edges_2015_Sep9a.gh, 10 KB

Permalink Reply by daniel assayag on September 9, 2015 at 12:40pm

It seems this method wont work for me :(

I join my definition in case you may know what i did wrong.

Thank you very much

Permalink Reply by daniel assayag on September 9, 2015 at 12:41pm

The definition

Attachments:

• 04-1.gh, 15 KB

Permalink Reply by Joseph Oster on September 9, 2015 at 1:33pm

Sorry, I don't have 'LunchBox' installed.

Permalink Reply by daniel assayag on September 9, 2015 at 1:43pm

here is one without lunchbox maybe if u have time to check

Attachments:

• 05-1.gh, 18 KB

Permalink Reply by Joseph Oster on September 9, 2015 at 4:00pm

First thing when working with "vast numbers" as you were is to reduce the dimensions to minimize re-compute time while you evaluate the data trees.  And disable the bit that seems to cause trouble - the code you added from my earlier reply.

Took awhile but I located the 'Extent X' input for 'SqGrid' and reduced it from 18 to four, which gave an adequate result for testing.

I began tracking the contributors in the data stream to the large numbers and, in the process, noticed the source of double lines.  'SqGrid' output could be flattened for our purposes.

And the 'ArrPolar' output needed to be flattened for the intersections to work.  Even so, the earlier code seemed to freeze my machine with only 4,788 squares (note that number!).  I replaced it with 'RUnion (Region Union)' which seemed to give the same result much faster.

Then as I was about to post my results, I wanted to compare the number of squares before and after and noticed a very strange thing: my code was generating 4,788 squares when 'Extent X' was either 4 or 8...  Digging further, I could find no good reason for the 'Series' and 'List Item' components, other than creating duplicates squares - so I bypassed them, taking 'Rotate' output directly to 'Area' and 'Scale'.

The net result is that, for 'Extent X' = 8, 'ArrPolar' generates only 1,216 squares to intersect instead of 38,304 in your code!  Thirty-one times fewer!!  I'll let you run benchmarks for 'Extent X' = 18, if you want.  But keep the numbers small when shaking down the data tree.

P.S.  6,156 from 'ArrPolar' when 'Extent X' = 18 - 7.7 minutes on 'RUnion'.

Attachments:

• 051_2015_Sep9b.gh, 19 KB

Permalink Reply by daniel assayag on September 14, 2015 at 12:11pm

wow!

Thank you for spending that much of energy on my things..

i got the lesson, ill be careful in numbers.. !

thanks for your help!

Permalink Reply by Pieter Segeren on September 9, 2015 at 4:33pm

Hi Dan, in case you don't need the interior curves...  I'd suggest going for mesh based approach:

Permalink Reply by daniel assayag on September 22, 2015 at 9:26am

Hey

thank you for synthesizing those 3 ways

although mesh approach doesnt work perfectly, as it propagate the mesh and sometimes creates or delete curves.