Grasshopper

algorithmic modeling for Rhino

I'm trying to produce a grasshopper definition that yields something similar to the attached "Example" image.  I have it working rather nicely on a 2d surface, but when I move to 3d I start running into problems.   If anyone wants to take a look at the attached file "605b-3" and try to help me, that would be awesome. 

The way I'm thinking about creating the louvers:

1. Contour the shape (could be any shape, but I attached the one I'm trying to do it to)

2. Divide those contour curves

3. Find the 4 points on those curves that are furthest away from the center of each curve

4. Move those points slightly away from the center of each curve

5. Replace the unmoved points with the moved points

6. Interpolate/NURBS curve through the new list of points

7. Loft the new curves with the original contour curves

I think I'm close, but I'm getting stuck at the end- I thought shifting lists would be the best way to solve my problem, but I'm a little confused as to how grasshopper is organizing the list of new curves and how to match that organization to the original curves.

Attached is an image of where I am stuck.  I can only create a surface in the gap that I'm trying to create by the louvers.  Either that, or one or two of the curves tends to create a "tornado" looking thing and i can't figure out how to fix it without individually breaking up the list.  Is there a way to set all the curve seams to be at the same location in a list?

Views: 1247

Attachments:

Replies to This Discussion

Figured it out:

The "Shift Paths" component was the one I was missing, and then "cull index" so the first and last curve in the lists didn't loft to each other and make a giant tube.
 

To fix the "tornado" effect I made a plane that intersected the curves so I could use "Surface | Curve" intersection.  This returned the parameter so that I could then adjust the seams for all of the curves to that parameter so they were all in alignment. 

I thought this definition would be able to be used for any shape, but it won't work for anything that results in multiple curves on the same plane when contoured (kind of like how its impossible to loft a metaball).

Here's the updated and fixed definition for reference as I'm sure somebody is going to have this issue eventually:

Can anyone explain to me a bit about the "Shift Paths" component?  It worked and fixed my problem but I'm still not entirely sure why.  I imagine Shift Paths is like the grafted version of Shift List?

Attachments:

Shift paths means modifying the path indices (called dimensions) according some rule: for instance get {x;y;...} and return {x+shift; y; ...}.

Other than that the Dalian Conference Center example that you are after is not made that way:

1. Create a collection of "panels" that in "normal" position are acting as a classic curtain wall system. (If panels are not planar > triangulate). Layout the panels "horizontally" for some proper all overall contemporary aesthetics. The production sizes (usually "long" sheets) of the material chosen should dictate the panel dimensions.

2. Mastermind some rule (via some attractors or other) that gradually rotates a given panel edge (pay attention to the orientation of planes that define the rotation) yielding a collection of panels from the "normal" position (// to the envelope) to some "fully" open (i.e. rotated) : that way you'll get areas in the facade that act as "openings"/"windows". Hire flying dwarfs for cleaning the whole system (or replacing some faulty panel).

3. Always have in mind the Bilbao effect (Frank Owen Goldberg = Frank Gehry) meaning that a proper panel triangulation should be your top priority.  

PS: Notify if you want a small demo on the above (but the bad news are that is done solely via code since it's part of a quite complex facade panel system ... and NO I'm not mimicking  CoopHimmelb[l]au, he he)

I'd love a demo!  Does it include a parametrically controlled flying dwarf cleaning system?

Also, I heard from a friend who interned at Coop last year that the entire facade of that building was hand modeled. 

Well ... get this that MAY qualify as the most stupid demo ever (and if you don't speak C#: the most useless as well). The only usage is to roughly indicate the approach ... but too many real-life things (and checks) are removed for a variety of reasons. Unfortunately the dwarf method is also removed (it's classified as internal - but maybe I can provide a smurf variant).

Notes:

1. In general and if you want to apply this "approach" with some "intelligence" (kinda) you'll need to mastermind rules: what happens if 2 surfaces share a common edge? By what means can you manage clash issues? What means rotation angle actually? (in relating to what?) . What are the required policies for some "auto" curve placement (for moving the attractors, that is): find the suitable edges? Or using something else?.

2. I would strongly suggest to do this type of "facade" system in "straight as possible" surfaces: besides every one is after liquid stuff these days > so be the next Mies VDR and do the other thing.

3. Hand modeled? Hmm + hmm ... and what about the interior paneling system?  (that poses critical packing issues: minimize the waste material and the likes).

Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service