Grasshopper

algorithmic modeling for Rhino

Hi all,

I am trying to apply brick over a lofted closed surface. The bricks collide and this is a problem since it will be constructed by a robot.

Can someone help me to avoid the collision without losing the rotational/textured/gradient effects.

Bricks should not intersect.

I attached both the Rhino and GH files.

Thank you!

Views: 10120

Attachments:

Replies to This Discussion

Using a "Center Box" means two things:

  1. dimensions are twice the XYZ inputs
  2. aligned at the center, they are tangent (which is what you want in this case!)

Attachments:

Thank you Joseph Oster,

I am still unable to get the same rotational effect.

Also the stretcher bond pattern.

Thank you for your kind assistance.

Attachments:

I'm not sure what you mean by "rotational effect"?  "stretcher bond pattern"?  "rotational/textured/gradient effects"?

Here is another version that does two things:

  1. adds a "gap" slider that multiplies the length of the brick to reduce the number of bricks on each row, leaving a greater gap between them.
  2. adds the ability to rotate alternate rows, giving more of an overlap effect, less aligned vertically.  Would be better if this rotation was done individually for each row...

Note also that I flattened the 'Contour' output (not sure why there are dashed lines if you don't?) and that for the rotation of alternate rows to work, the vessel has to be round(!) and centered at X=0, Y=0.

Attachments:

P.S.  Depending on the "gap" (1.2) and rotation (13.5 degrees), I see slightly "better"(?) results by replacing the 'Integer Division' component that feeds 'HFrames' with a normal 'Division' component instead.  Due to round-off...

Making the bricks wider (22) makes them easier to stack but also requires increasing the gap, due to the 'Center Box' nature of the bricks.

I remember working on this problem when I started playing with GH.  In that case, the surface wasn't round so staggering alternate rows by rotation wouldn't work...  I don't seem to have that code around anymore but a solution that doesn't depend on a round object would be better.

OK, I have a generalized solution that I'm pretty happy with.  It doesn't depend on the object being round.

It has sliders to set "H gap (min)" - the minimum gap between adjacent bricks - and "V gap" - the gap between bricks above and below each other.  These gaps are expressed as multipliers with values between zero and one; for example, a 1/2" 'V gap' on an 8" high brick would be 1.0625.

The way it works is by dividing each contour curve by twice the number of bricks that will fit on it.  The resulting points are then culled twice to get one list of even numbered points and one list of odd numbered points.  Finally, these two lists are culled and merged so that even and odd numbered points are used on alternate rows of bricks (contour curves).

The results are pretty good for a wide range of input surfaces tested so far.  Code attached with test shapes included in the GH file.

Attachments:

Besides using static shapes as the basis for the contours and rows of bricks, I thought it would be cool to try an interactive dome shape - and it is cool!

It's also cool to modify the dimensions of the bricks so that they are effectively placed showing their ends instead of their sides.  There are some creative choices to make in the shape and dimensions to make it look great - and be feasible to build, of course.

Attachments:

Hi, with this definition I think it can be interesting to orient each brick to create a real dome. Because for this moment, each brick is in xy plane. I tried to modify the definition but I can't, any idea? 

Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service