Grasshopper

algorithmic modeling for Rhino

Hi all,

I'm having a bit of trouble with organising a data tree such that within each of the 6 paths, each list of lines (there are 24 lists of 30) is intersecting with the other surfaces in the corresponding path, except for the surfaces (24 lists of 2) in the corresponding list.

E.g.

{0;0;0} would be intersected with {0;0;1-5}

{0;0;1} intersected with {0;0;0 and 2-5}

Usually I've just replicated the data and culled/indexed each one using the series component, but since I'm dealing with multiple items per list it's been a bit more complicated.

Sorry for the slightly confusing wording

Views: 1560

Attachments:

Replies to This Discussion

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

Attachments:

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:

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

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:

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:

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...

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 

Did you try out the attached script?

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:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service