# Compare two breps in list and if they intersect then put the next item in the list

I am randomizing 18 breps on a grid. I just need help with the intersection fixing. I can make the logic of it but am just not able to translate that into Grasshopper.
What I want is, if my “fins” (or breps) intersect with each other (list item i with i+41) then change the i+41st item/ randomize it & perform the check again until it doesn’t clash.

In this case, brep of 43rd grid is intersecting with 84th.

This is the last part before baking this bad boy and fabricating it.

PS: I know it has to be done somewhere in the fin generation group. I thought of comparing it with BBX after baking it but couldn’t work that out.
PPS: I just noticed that somewhere it is not just the next column but also the next to next column which is intersecting. So, I gotta work the checking statement on i+41 and i+82.

Any help would be really appreciated

Test-201217.3dm (2.5 MB) Test-201218.gh (25.3 KB)

Since you simply want to map a predefined set of geometries - your fins - to a quad grid, you could change your entire strategy to a more abstracted and fast one!

Each fin has 8 neighbouring fins, except for the boundary grid cells, where there are less. The neighbours on the left and right, as well as the diagonal neighbours don’t really have a stake in this example, since fins only seem to be able to intersect in forward and backward direction. Consequently, you already don’t have to all other neighbours.

Now, for each geometry you construct a set of rules, meaning which type of other fin can be placed on the grid cell before and after the concerned fin. A simple list of indices to chose from would suffice here.

Having all the geometries and rules, you now start for instance at the first grid cell, place whatever fin, since all forward grid cells are empty and the backwards ones don’t exist (are out of bounds). This will be the case for the entire first row.
Starting from the second row of grid cells you now need to take into account the neighbour in the row before and only choose from compatible cells to this one, and so fourth.
You might see a pattern emerging here. Note that if you traverse your grid row by row starting from the first one, you only ever need to check the neighbour in the row before the current grid cell. This means that you really only need to define rules for which fins can be placed in front of another fin.
However, if you want to populate the grid at random locations, you need to construct rules for the front and back.

With this strategy there is no need for checking brep intersections - which is a costly operation and prone to be unstable -, and since you have quite big grid, it should also be much faster than your current definition.

1 Like

Hi, Thanks a lot for such a detailed response.
Yes, I was thinking about this yesterday and thought about changing the entire approach to cell based logic but it’s really late to change it now. Your approach is definitely faster and makes a lot more sense than the gibberish which I’ve made.

However, I did some work and am able to replace the element at the i+41 point too. I am able to check also if it’s intersecting. I am just missing the grasshopper component logic to attach both of these things to work together and try it on the entire list.

I just want to know if I can make a logic which says if BBX has an output, ONLY then run the replace component. https://i.imgur.com/PO4UlbL.png
and some way to make it run for the entire list rather than changing the number slider one by one.

Hi again,

Since nobody else chimed in so far and I couldn’t get your version working, I quickly implemented what I described earlier today, and as far as I can judge, it seems to work fine!
It uses a custom GHPython script. I hope you don’t mind!
Since you’re on Rhino 5, you need to install GHPython, if you don’t have it already. You can find it on food4rhino.net.

It’s rule based. You define a set of rules for each brep/fin that you want to place. The rules have to be in the same order than the breps. Breps that can be preceded by every other fin simply have a single rule -1, which means anything goes. The numbers represent indices of fins that can’t be in the row and column before the current fin.

You might have to adjust or finetune the rules to your liking!

Hope this helps.

populate_fins.gh (21.1 KB)

2 Likes

Woah! I cannot thank you enough for taking the time to do that! Your script is far more sorted.

I already had Ghpython but somehow it is still throwing an error:
Solution exception: cannot import treehelpers from ghpythonlob.
I searched around and I think it’s a Rhino 5 issue which doesn’t have this library. I am trying to search for the library. Maybe I can find it and download it.

Nevermind, found it and rewrote it to call from the function written by Giulio Piacentino. If anybody runs into a similar problem, here’s it: https://gist.github.com/piac/ef91ac83cb5ee92a1294

1 Like

You’re welcome.

Ah, I forgot about that, but you seem to have found a workaround yourself, which is great!

Hey, thought you’d like an update.
I extended the script to do the following:
For fabrication, I needed the fin names as well. So, all the 18 types of fins now have their names as 1L,2L,3L and 1R,2R, 3R etc. written in the grid itself to easily recognize them at the construction site.
Also, now, 1 type of fin has same the same colour on each occurrence.
I also wanted to have different colours on the front of the fin and the back of the fin. I am thinking of doing this easily in 3ds max. Let’s see how it goes. Will show you the final renders too.

Could you also help me with your name and possibly contact/email/social/ or whatever you’d want me to put? I’d love to credit you ^.^

Sounds impressive!

I believe this can also be quite easily done with Rhino/Grasshopper, since version 6 at least! You simply assign a double-sided material (cf. source).
I’m looking forward to the images!!

That’s very nice of you! I’ve send you a PM.

I guess you found a solution, since you deleted your post?

Haha…yes. Didn’t want to bother you so much. I just edited the length of largest fin using some basic trigonometry so that it never intersects at 2 cell distance.

1 Like