Is there a "does intersect" node?

Hello all,
Intersection finder.gh (18.4 MB)

I’m trying to find the best way to determine whether a group of breps intersect a plane as shown. What I would like to get is a list of booleans per each plane so I can organize my brep list based on the plane intersections at every plane ( that represent floors). I’m not sure that subdividing the plane and then using Brep contains point will actually produce a clean list. I know this is probably very simple but got stuck. (Sorry for the large gh file)

Thanks

Assigned to Grasshopper category

The 18.4 MB GH file is a bit ridiculous. Makes GH run slowly. The uncolored (26 red) boxes are “Invalid Breps”. I tried but failed to fix them.


Intersection finder_2023Feb9a.gh (18.4 MB)

P.S. I won’t upload that 18.4 MB GH file again but this is how I isolated the invalid breps. (white group)

Working in the HUGE file not only made GH run very slowly but eventually GIMP crashed and there were other indications that my laptop was distressed. I rebooted and will soon delete that GH file.

2 Likes

Thanks Joseph. In my machine I am not internalizing the Breps, I just dont know of another way to share the gh file without simplifying or dumbing down too much what I’m trying to do. Sorry for the inconvenience…

Can you elaborate or point me to what exactly does shift indices do and how we go from performing an intersection operation to a list of booleans? This part I cant seem to wrap my head around. In Dynamo for example, this operation is much more straightforward.

Thanks again

How big is the Rhino file? Sometimes it’s better to not internalize geometry and this may be one. Post the Rhino file and the small GH file referencing it. That makes exchanging small GH files easier.

Well, there isn’t much code there… PShift (Shift Paths) is done to match data tree structures. When the list length of BBX intersections (per branch) is zero, it’s False, otherwise True.

P.S. I just posted a file here where the value was so close to zero that it was treated as False, so I had to insert a isEqual (zero) component to get the correct True/False Booleans I need for the Cull Pattern ‘P’ input:

Thanks. For visualizing the elements based on their relationship with the plane, this was good. The problem I’m having is in the list structure. Not only do I have to sort the list of breps (apartment units) vertically (which is fine and I can do it manually floor by floor), I also have to sort them to go in a certain order (left to right and up and down as shown in my sketch) so it matches a separate excel spreadsheet that I am planning to use Elefront to assign parameters to each geometry so I can visualize them.

So far I am thinking of separating both groups based on the order they should be in the list and then merging both lists. But am not sure how to sort based on a curve yet…

That should probably done before this intersection code, eh?

There is a lot to know about data trees. One of the most useful tools for me is temporary text panels.

Look at this image of Before and After PShift (Shift Paths) - see the pattern in path names? Often, that’s all you need to know to make sure they match.

As to sorting your apartment units by Z, the code I posted divides them into floors, one per branch, as you can tell by the colors - ColorB assigns one color per branch. Unfortunately, sorting each branch “left to right” is not so easy, in part because you have to account for Y where multiple apartments have overlapping X values. But it’s possible.

It will help if you can fix those “Invalid Breps” in the Rhino file and post it separately, referencing it from a small GH file instead of internalizing so much geometry.

Having apartment numbers as Rhino properties (like ‘Name’) would be very good! There is a standard GH component called Object Details (ObjDet) that allows read access to some of those attributes.