Brep|Curve intersection data tree issue

Replies to This Discussion

Permalink Reply by Laurens on May 1, 2017 at 2:11pm

For reference, here is a simpler one I did with the same principle

Attachments:

• 170501_curve_brep_x00.gh, 1.5 MB

Permalink Reply by Vongsawat Wongkijjalerd on May 2, 2017 at 4:08am

super confused looking at your definition.. but I'm going to assume what you want is that for each branch, you want 30 lines to intersect with 2 surfaces to give you 60 points per branch.

in which case this is just Cross-Reference, BCX, and Trim? (or PShift if you prefer)

Attachments:

• curve_brep_x01.gh, 438 KB

Permalink Reply by Laurens on May 2, 2017 at 7:24am

Thanks for the reply, I'm looking to intersect each list of 30 lines with the remaining lists of 2 surfaces. I think the coincident version of cross reference does this but instead of each item index I want to do it for each whole list

Processing speed is also an issue as I hope to run it as part of a Galapogos script

Permalink Reply by David Stasiuk on May 2, 2017 at 8:40am

Especially if you hope to iterate through this rapidly with Galapagos, this is an example where you're going to get much, much better performance by using a script. See the attached...basically, you specify the length of the path indices you want to use to constrain the intersection tests (so here, it's three: a = a, b = b, but c != c). Then the script iterates through each curve path, checks that a given brep path is appropriate to test for intersections, and then calculates intersections. One way to really massively speed up these types of intersection calculations is to pre-check the geometries you want to intersect by testing if their bounding boxes overlap...this is really very lightweight, and eliminates the computational expense of trying to intersect every curve with every brep. You could further improve this script by introducing multithreading, or being more disciplined by casting to GH geometries, which speed up list outputs...but even so, it's still pretty quick.

For sure you can do this all with native components, but it ends up being a lot of them, and will slow everything down quite a bit.

Attachments:

• 170501_curve_brep_x.gh, 446 KB

Permalink Reply by Vongsawat Wongkijjalerd on May 2, 2017 at 9:47am

if you can code it, that's probably the way to go.
In other news, I'm still super confused by what you actually want..

6 paths of 24 lists.
I basically did: For each path, each list is to intersect with the other 23 lists.

Basically just Group up data before CrossRef(coincident)

sadly, if this is what you want, it took 1.5 seconds to solve on my rig :/
unless I misunderstood again, in which case its probably not too hard to shuffle things around and hope the solve time goes down.

(or just use the coding solution if you can manage w code)

Attachments:

• curve_brep_x02.gh, 442 KB

Permalink Reply by David Stasiuk on May 2, 2017 at 12:22pm

I think the key is that the first two indices of the data tree path structure should be used to match the curves to the breps, but the cross referencing should only happen where the third index is different. So: {0;0;0} should match {0;0;1} and {0;0;2} but not {0;0;0}; and {0;0;1} should match {0;0;0} and {0;0;2} but not {0;0;1}, etc.

There's also the added wrinkle that each curve/brep combo within these matched paths needs to be cross-referenced with each other...

Permalink Reply by Laurens on May 3, 2017 at 2:35am

Yeah it's this which has frustrated me so far. @Vongsawat sorry I haven't been very clear, but I think David has identified the crux of the problem - it's almost like I need to cross reference the last parts of the branches themselves 

Permalink Reply by David Stasiuk on May 3, 2017 at 4:56am

Did you try out the attached script?

Permalink Reply by Vongsawat Wongkijjalerd on May 3, 2017 at 5:30am

so 6 paths of 24 lists. Each list interacts with its 5 corresponding partners in the other paths but skips its own?

At some point I had thought this was what you wanted.. but then kept rereading and getting more and more lost..

added something just to help visualize/check how the combinations are working.

On the upside, if this is actually what you wanted, solve time is down.
so third times the charm? *fingers crossed*

Attachments:

• curve_brep_x03.gh, 450 KB