Grasshopper

algorithmic modeling for Rhino

All,

I am still working through the creation of a diagrid for a wood gridshell, and could use some of the collective wisdom of the discussion to answer some questions.

I have been able to create tiered / cascading selection sets from the point list of the diagrid manually, but have been unable to create the pattern to simplify the list. Right now I have separate components for each of the lath centerlines. I have been able to copy and rotate half of the lines. Is there a simpler way of performing this set of actions?

The second part of the problem has been in using the resulting polylines to sweep a closed curve along for the laths. Thus far I have used the [1] offset on a surface component, [2] flipping the copied curves, and then [3] creating a surface only to [4]extract the resulting Brep edges to make a set of [5] ruled surfaces... Again, here there must be a simpler way of doing this.

I would be grateful for any feedback on this dilemma.

Thanks!

Views: 3314

Attachments:

Replies to This Discussion

Hmm ...

1. NEVER (ever) use offset curve on surface > exceptionally slow. There's other ways to do what you want. In fact and since we are actually talking about extruding a given profile along a collection of curves (to be more precise: sweep properly oriented profiles along a given rail) ... you need a totally different approach (and 100 times faster).

2. Thus ... your def needs a major reconstruction: in fact a total remake ... especially if you intend to create a similar thing for real life AEC purposes (meaning: modular "struts",  "strut" connectivity data, node design [usually done via metal plates], panel roofing design [ potentially using a secondary grid and/or stand-alone monocoque panels] ... etc etc).

3. I could provide to you a workaround on this using only one "component" ... but it's C# code only (no components of any kind) thus it could be potentially useless (unless you speak C#).

best, Peter

Peter,

Thanks for the response - and for the good and bad news. I am not a C# fluent speaker, so the component work around may just go over my head. I would prefer to sweep the profiles along the primary curves, and have been working on that part of the definition as well.

The aspect of this approach that I was having difficulty working through is getting the segments of the polyline to have their frames all aligned to the surface normal of the underlying shape. Perhaps if you had some pointers in this area I could work through that part and save myself some of the weight of all of the messy components that are currently in the definition.

I don't have any problem remaking the definition from the beginning either. It's all part of the learning process as far as I'm concerned, so don't hesitate to point in a different direction in order to simplify things.

Thanks again for the feedback and I look forward to getting more.

best,

greg 

Well ... Greg (think "beams" as individual straight segments node-to-node instead of a big thing made via an extrusion of some sort along a polyline. For a given edge (acting as rail) the dihedral plane of the neighbor "faces" defines the profile [transverse] plane [all profiles via Orient: ONE profile placed in many places]

Some info first:

1. Is this academic?

2. On what level of study you intend to go? Concept, Preliminary, Definitive or Final (= do it).

3. What is the usage? I mean is it some envelope for an AEC thing of a certain size? Because size (and therefor the size of the "beams") DOES dictate everything: the whole concept of the beams in relation with the node design (plates? cast? forged? some hidden MERO join systeme?), the molds for the synthetic wood, transportation limitations, on site expertize, the secondary grid for the roofing, maintenance, cost, cost , cost and cost  etc etc.

4. What type of envelope you imagine? (if for instance is made via quad alu-glass panels [or some kind of big tiles] > quad planarity IS an issue).

Peter,

Thanks again for responding. I follow the node-to-node idea, with straight line segments between intersections of the diagrid. I have worked on a couple of versions of that type of assembly, and have been able to successfully extrude a profile along the segments. (More on that later.)

A bit of background on the project.

1.] It is academic and final - a design/build project with students at my university.

2.] We have worked on a variety of physical model types (hanging chains and fabric models for catenary curves, lamella / reciprocal structures, geodesic typologies, and thin lath gridshells. I will be using the definition in the future to work with students on similar projects - though not all of them will be design / build.

3.] We have settled on the thin lath gridshell for a variety of reasons - including the availability of materials. It will be a simple pavilion, with simple connections between the laths - a combination of custom fabricated plates and bolts. Not worries about transport, as it will be built in a space near the final location.

4.] There will be a simple envelope on the final version, though the materials have not yet been selected - it depends a bit on what we can get donated. Planarity of the envelope elements is something I happen to like the look of, in contrast to the curvilinear character of the gridshell.

As for the difference between the node-to-node gridshell and the continuous lath gridshell, I am hoping to be able to use the continuous lath version. The final size of the pavilion will be about 400 square feet (40 square meters), so the continuous elements lend quite a bit to the stability of the structure - even though the structure may act like a series of pin connected segments. The other part of the interest in the continuous lath is the ability to accurately locate any necessary holes for bolts. Prefabrication and offsite assembly will be the primary method of construction - with a minimal amount of onsite assembly. Hopefully this makes some sense.

Thanks in advance for your input.

best,

greg

OK I have all what I need:

1. We can do that together and provide your students with the ultimate thingy (fully working BUT ... complex, chaotic AND cryptic > what's not to like? he he). That way your students could taste first hand the Apocalypse (and/or the brave new world and/or the animal farm - depending on your point of view, he he).

2. First ... make a break and spend some time to play with the def attached. Of course comes straight from the Dark Side (no components of any kind). But you know what? ... sooner or later your students they must obey to the Dark Side ... or they'll extinct (future galloping you know ... I mean in a few years from now anyone not speaking some programming language > Homo heidelbergensis ).

3. This thingy attached works in 2 modes: (a) design a(ny) pattern (in a "flat" Plane.WorldXY) or (b) apply a(ny) pattern (in any given surface List).

Start from here (diamond pattern, like the one used by you):

Apply random Z noise (other pattern used):

Or use surfaces (to make frames or their content among other things):

Note: Although this def attached MAY appear off-topic ... there's a reason (other than using any pattern you like) that I provide this to you : because that way we can totally control nodes, edges and "facets" and therefor extract any plane imaginable and therefor place/manage any imaginable profile.

Note: Of course using the make frames capability (and extruding these BrepFaces AT ONCE both sides) we could obtain "autonomous" [monocoque, so to speak] modular load bearing "panels" ready for assembly (instead of beams + nodes + plates + cats + dogs + why??) ... but this is not exactly what you've asked ... he he.

more soon

Attachments:

Peter,

Wow! Thanks for sharing your work. I'll start using the definition this weekend, and see what kind of trouble I can get myself into. I agree with your assessment of students needing to understand coding and programming languages. I am doing a bit of catch up myself - as my background is in literature, construction, and ecological systems design.

best,

greg

This was the prelude. For the real menu (a variety of Dark Side stuff straight from the Hell) > this weekend:

One possibility (out of many): From a given pattern (out of 10) to something that you don't expect (instance definitions acting as connecting nodes - we'll see later why the one beam "across" a given diagonal is not a good solution unless you are a Zaha fan).

is it posibble to have gh and 3ds files Peter? I would like to stalk what happent there.

Sure, but keep in mind:

This is only a simple test to indicate the only way to deal with assemblies in designs. The actual instance definition (nested) is not supplied (for internal use only). The levels of freedom in the actual node are different as well - totally different "linkage" design.

Dealing with the actual node combo requires far more complex plane arrangements since (a) the connecting ring lays in the planes already calculated BUT (b) the adapter primary axis must align with the dihedral for a given edge: the angle of the neighbor faces. Meaning in other words: connectivity [edge-to-face, point-to-point, etc etc] trees  (for internal use only).

So the only thing that this test node (2 layers used) does correctly is to lay (with regard the ring primary axis) at the right place (plane, that is): linkages are NOT moving at all.

But in general is a rather useful indication upon how to deal with component based designs (where a void instance has the ring as child that has N adapter instances as childs etc etc). Place the test node  [NOT bake anything] and export [STEP 214] a test R file to some CAD/MCAD app that works that way (CATIA, NX, Microstation etc etc).

best, Peter 

Attachments:

Here's a hybrid layout: diagonal main beams + secondary "sub-beams" allowing placement of envelope related planar panels (avoiding the nonsense of "twisted" roofing modules and the obvious hideous cost).

The C# prepares vector centroids (sum of unitized normals per neighbor face per node NOT the same as Surface.NormalAt(u,v)), samples grid points into diagonal collections (trees),   lofts accordingly profiles ... and demonstrates the obvious: a "continuous" diagonal beam is impossible unless it's made from liquid soap.

And since your have plans for the Dark Side > get this as an appetizer (includes a challenge for you, see inside C#, he he).

more (with the real thing) soon

Attachments:

And at that point another break is required:

Top-to-bottom:

This archaic AEC design approach dictates that the "brain" makes sketches of some idea using some vellum paper ... and his slav... pardon me partners attempt to translate that into real-life/real-world. As I said: archaic and dangerous for the Eco-system to the max.

Bottom-to-top:

This (obviously) means - metaphorically speaking - that the "brain" first thinks the rings/pistons and then designs the mighty V12. Absurd for most old Architects (who believe that they are some kind of Michelangelo fused with HAL9000).

Both-ways: 

This - although "standard" in MCAD matters - gradually starts to make sense  ... even to Architects/AEC Engineers (was about time, but never(?) is too late(?)). It's the only way to design some contemporary thing (especially an Eco-friendly one) and not basing hopes solely on Karma.

What all the above mean? Well ... you should have a rather "fixed" solution (or a range) for the nuts and bits of that thing of yours BEFORE outlining the whole (the topology, that is): For instance the roofing policy (planar stuff and the likes).

Open the Rhino file and see a (rather expensive) multi join node system for a rather bigger thingy (100*100 m). Node shown has valence 8 meaning 4 main beams + 4 secondary per node (like the last Image attached). Star Nodes related with the secondary beams have valence 4.

BTW: structurally capable components are reality these days via 3d printing (at least for small stuff like yours) ... meaning ...the obvious, he he.

more soon   

Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service