algorithmic modeling for Rhino

I am trying to make a grasshopper script that takes a shape and creates a waffle structure. Now the problem comes when I try to make the final slits.

I do this by finding the intersections and then I create cylinders which I subtract from the flat "section cuts". For this I use Trim Solid

The thing is that half of the time, Grasshopper simply does not trim the surfaces.

As shown on the image below I go from 7 surfaces to 2 with slits.

The weird thing is, that if I move the cylinders to the top of the surfaces, it works perfectly... As shown on the bottom of the picture.

The only difference between the two cases is the Z position of the cylinders.

Any ideas of what's wrong

Views: 1314


Replies to This Discussion

This could just be to do with the flaky-ness of boolean operations in GH and Rhino.

Perhaps you would have more luck with the TrimWithRegions component in the Intersect tab and trim the outline of the waffle surfaces with rectangles instead?

There is always the Bowerbird plugin too which has some great waffling tools!

What are the 'Data Dams' for?  I by-passed them and it seems to work fine?

I have never used a 'Data Dam'.


OK, I have to apologize on two counts (sorry!):

  1. I was in a hurry to get out the door and didn't notice that one of the sections was missing.
  2. When I returned and discovered the error, I ended up ripping the code apart and making MANY changes that I can't really spell out in perfect detail.

Some things I did:

  1. Sort the sections planes by 'X' or 'Y' as appropriate.
  2. Use 'PPX' (Plane | Plane intersection) to get the location of the columns instead of 'BBX' (the intersection of the Boundary Surfaces).
  3. Use 'Extr (Extrude circles)' to make the cylinders, with their lengths all the same as the radius of the sphere.
  4. A bunch of changes to 'Flatten/Graph' to get the data lists I wanted.



Thanks for the replies!

I have tried with TrimWithRegions and it seems to work fine. Although it is suuuuper slow for some reason... But I guess that's a luxury problem :-P

The data dams are just to prevent lag when I am tweaking the program. I don't want to disable and enable all the time ;-)

Thanks Joseph for the detailed answer. I will have a look at your code :-)

Thanks for the explanation of data dams - I can see now how they could be useful and will try using them in future work.

Unfortunately, I'm not quite sure which tactic I used that made the difference - probably a combination of all of them.  I can give you some reasons I made the changes I did.

First, I saw no reason that each set of sections used its own 'BBX' and 'Eval' components to get the grid of points that are the basis of the cylinders.  Logically, they should be identical.  But trying to use the points returned by one 'Eval' in the other path failed miserably.

Second, I wondered if using a negative length to get the cylinders to go the opposite direction (down instead of up) might be causing a negative volume condition - something I've seen in other circumstance but never been able to explain.  So I switched to extruding circles to make the cylinders.

Eventually, I noticed that the way you created the section planes (three to the left, three to the right, one in the middle) resulted in a jumbled sequence.

After sorting the section planes by 'X' or 'Y', I decided that it might be "cleaner" to get their intersections for the grid points instead of doing that several steps later using the boundary surfaces.

For good measure, I decided that there was no point in having different length cylinders based on the boundary surface intersections.  They could all be the same.  If they weren't, combined with the jumbled sequence of sections, it seemed like a possible cause for failure - a mismatch could be trying to intersect short cylinders with taller sections.

In retrospect, it's hard to say which changes were crucial - and I don't want to go back and play with it anymore.  Hope these notes provide some clues about how to create a better model.

The reason behind using BBX, is for more complex shapes. Your definition creates all slits based of the CPlane, which might not work for more complex shapes. :)

I understand why you would want to sort the sections, but as long as you keep the same data-tree structure, it does not matter :)

I think Martyn is right in the fact that it's just Grasshopper being a bit random around boolean functions...

But thanks for the help!

Well...  Your approach failed and mine succeeded so it's more than just random.  It's the precision of the method.  There is no logical reason to use two sets of intersection points for the grid, for example.  And a jumbled sequence of sections makes it harder to keep the data-tree structures congruent.  Even the order of connecting multiple wires to an input can cause problems.  Good luck.

You might want to look at some work I did in this thread:





© 2022   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service