GH for President

OK, friends,

See the actual start of the thread here: http://www.grasshopper3d.com/forum/topics/a-very-strange-pline-actu...

This thread may interest you (read) or… may not at all (recycle). It deals with the potential possibility to port GH into AEC fields (real-life AEC fields, nothing to do with academic thinking). The bad news are that the smart AEC sector is occupied solely by Bentley/GenComp – expect soon Revit/Dynamo as well (not to mention CATIA). The good news are that there’s millions of designers/engineers/industrial designers out there who could be interested for a 3rd alternative.

Intro:

Well, in the old days (when men had mustache and muttonchops) AEC design performed in a nice top-to-bottom sequence (kinda like a vector) : the Big Man (aka The Brain) did some sketches (with crayons) and the rest (known as the “others”) struggled to make The Idea a reality. Today things are different, mind. Or they should be different. Or may be different. Or whatever.

The big easy:

For a zillion o reasons (AEC matures, PLM, cost, outsourcing, sustainable engineering…add several more) this vector like process of the past is like a Brown motion these days: Right down the moment that you (or your team) “sketch” The Big Idea … another team design simultaneously (i.e. in parallel) the components (parts) that compose the whole. This is the so called bottom-to-top design mentality. So the whole and the parts meet in some "middle point" instead the later being dictated by the former. In quite a few occasions parts dictate the whole (cost, cost and cost being the main reasons). The more a design is contemporary the more this bottom-to-top thing plays a critical role. Ignore it and have a very big time (sooner or later).

The bad news:

If you accept the above…well GH – at present phase - is not ready for contemporary AEC work. At.All.

3 Main reasons for that:

1.You can’t use parametric parts (i.e. nested blocks to speak Rhino language) into a given definition (in this case attached : truss nodes, connection flanges, mount plates, cable tensioners, planar glazing components, roof skin components…etc etc). This is obviously a Rhino domain.

2.You can’t bake a given solution in such a way that the Rhino file is structured (i.e. assemblies of nested blocks). Or you can do it theoretically writing some VB/C code – but the core of the matter is that corresponding components are MIA. That means that you can’t export anything useful actually into established AEC oriented apps and/or established MCAD apps (for doing/calculating the parts for real-life production).

3.The GH process can’t being interrupted. Imagine defining, say, a building “envelope” in GH and then …er…use Evolute tools in order to optimize things (say quad planarization and the likes). Then …continue in GH for more detailed work. Then design the parts as in 1 above. Then back to Evolute. Then back to GH.

So…if anyone is interested I would be glad to start the mother of all debates and/or some kind of crusade (GH for President, that is).

PS: This definition is a WIP thing – more refined stuff to follow (in particular a complex canopy tubes pre-stress system).

PS: Tree8 components are used sporadically.

PS: Use Saved Views

May the Dark Force be with us.

Best, Peter

Attachments:

TRUSS-TRIANGLE-SURF8.gh, 539 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on February 13, 2012 at 1:59am

Added some visual control more (and corrected that "pensil" thing ...with pencil).

Attachments:

TRUSS-TRIANGLE-SURF8a.gh, 541 KB

Permalink Reply by Jon Mirtschin on February 13, 2012 at 5:06am

I really don't agree with most of your post (based on my experiences and research). Of course I'm biased, but I'm also perhaps prone to a wider scope of the AEC industry in a global sense and I see great examples of GH being used to explore and communicate real projects. I would also note that Grasshopper has matured at the heights of the credit crunch, meaning a lot of projects that could be developed using Grasshopper just aren't being pursued. I also have also maintained that there is not (and is never likely to be) one utopia software that does everything. So I don't expect Grasshopper to resolve all of the aspects you mention, the same as I know generative components performs better or not at all in common areas. Also the AEC industry tends to be very protective internally of the process and workflows used so it might not be public knowledge that Grasshopper (of GC or whatever) was actually used.

I'm not going to argue most of the claims, not much point to it. I will take a look at your model and try to implement it using a combination of Grasshopper and my own developments to achieve your objectives .

1. You can use IFC (neutral bim) to generate relationships and hierarchy of assemblies and parts etc. and have this (potentially) exchanged into other BIM software.

2. You can (refer above), but it's still WIP and subject to more improvements. Not many public examples, but this is one http://www.grasshopper3d.com/profiles/blogs/louisiana-state-museum-...

3. I don't think this is practical in the general sense. Grasshopper is a generator, not really an importer (just utilizes inputs). If you have phases of processes, you can have independent models processing the inputs of other processes and exporting to others. Partly possible using hoopsnake or similar techniques in certain circumstances.

I'll try to find some time to demonstrate (to at least certain extents) this on your model as I have the time to do so. I'm very interested in other opinions and observations that might be added to this.

Cheers,

Jon

Permalink Reply by peter fotiadis on February 13, 2012 at 6:50am

Jon,

Of course people can do real-life things with GH (more accurately use a collection of apps between them GH as well) ... the question is how easy can they do it or put it differently: can they do it within the same smart umbrella? Or put it differently: is it worthy to exploit/consider/evaluate GH methods and development orientations that could "approximate" Utopia?

Let's split the case into segments:

The parametric part thing (although critical) is complex and rather beyond the scope of GH. Affects Rhino far more than GH. That said Microstation has 3 levels for doing this (but forget Microstation and/or Gen Comp).

So for a start we can focus in GH acting as a "composer" in 3D place of all the required (hopefully real) parts for the job. Parts must be nested AND readable as such by an external AEC app.

I'll post here (soon I do hope) all the parts that are required for assembling this. I mean individual static "blocks" that we assume (wrongly) that remain static: I mean we presuppose that the whole GH geometry is fixed (thus this is really a smart sketch of some sort) and no further changes are on schedule (that MAY affect parts).

That said I prefer an incomplete Utopia (one thing that "does" it all, or it thinks that does it) than a myriad of individual apps that take input one from the other and promise the Holly Grail (and/or delivering it). The core reason that I use Microstation as my basic platform is exactly that (obviously with a certain price to pay: bugs, shortcomings, wrong concepts in places etc etc etc).

Best, Peter

Permalink Reply by Thibault Schwartz on February 13, 2012 at 8:04am

Hi Peter,

This is only my opinion but:

I never used Microstation but I had the oportunity to use CATIA/DP extensively a few months ago, and was also tempted by some comparisons, and tried to do the same work I was doing on DP on GH. Here are my conclusions:

- As Rhino is not a constraint-based modeller, assembly design without plugins(RhinoWorks or else) is just not possible. So as long as constraints will not be present in rhino... no constraints, no AEC.

- The list management that GH offers is 10 000 time more efficient and user friendly. So a good point would be to link all the list management tools with GH-like interface. In fact, for all operations that are not concerning assembly (wireframe generation for example), GH is way ahead in terms of speed IF you're not dealing with geodesic curves or parallels on surface, eventually boolean operations, that are really a weakness of Rhino in terms of precision and stability. You can also do amazing synchronised attributes datatrees quite easily in GH, that you can then synchronise via Excel with a massive product based on Catia without problem. It can easily save you a few days of work.

- Rhino does not handle pre-computation of the geometry without loading effectively that geometry, so you will not be able today to work on a product bigger than 2Gb (maybe 3) in rhino in any way, even on rhino v5 64 with 16Gb of Ram. With the constraint stuff, I really think it is the second bad point about rhino.

- As Jon said, I think Rhino has to be understood as a sketch-oriented application for the construction (this is not pejorative, that's what I personnaly prefere) in a sense that its usefulness is to allow research of design possibilities, that you can of course link afterwards with what you want, but too much basic options are missing to rhino to be really viable for AEC. I personnaly don't want to see geometrical sets to appear in rhino, it is absolutely useless considering grasshopper evolution towards clusters for exemple.

After that, in purely technical terms I would say that:

1) Possible, partially already working --> Clusters (waiting for updates)/nested definitions + SQL for attributes management on several working definitions.

2) --> I think there are two ideas here: a) exporting some dead geometry in an arborescence of files (can be done quite easily with LocalCode but it will remain dead. You can also create a definition based on dead geometry and update this geometry using the geometry cache. Of course if this geometry is automatically exported via LocalCode from a precedent definition, when you update the upper definitions then the modification is repercuted on all your model. Personnaly I think it is best not to do it in rhino. b) otherwise, it is just synchronisation of public attributes attached to existing parts/products, as I described previously.

3) Geometry Cache. You can also auto-loop you file using loading/unloading input geometry of your desifnition with LocalCode and some VB.

But maybe I am wrong on some points of course.

Best,

Thibault.

Permalink Reply by peter fotiadis on February 13, 2012 at 12:03pm

Thibault

Interesting thinking - although ultimately why to do it? I mean since there's AEC/MCAD apps around that can accomplish similar tasks why someone (i.e me/my team) should "customize" GH that way? Anyway...GH is really interesting (but could be far more intriguing if could provide access to R SDK the way that Generative Components does).

Other than that I confess that this design mentality of mine (that both way "Brown" motion thing) is not very common (if at all)...at present time. Meaning that "sketches" are still a good/valid thing, he he. On the other hand the explosion of possibilities due to dependent modeling ... puts the term "sketch" into a certain perspective (especially if sustainable constrains are key design factors ...i.e. break-even-points...i.e cost...i.e. parts/components available even at conceptual design stages). It's interesting as well the way that cost estimation changes (gradually) these days - stuff is estimated on a "per-task/offer" basis instead of the classic unit price*quantity thing.

Jon

Here's some stuff with regard the planar glazing facade. Note that several parts are feeble (meaning a parametric task of some sort is required - anyway in theory). There's a slight offset with regard the axial forces as well...but nothing very serious in that scale. Note that the facades are not planar nor the quads of points that define the glass modules are (a challenge for you that one? put your stuff on fire, he he). Anyway, in order to avoid Zaha Hadid type of glass panels (unreasonable for this particular Project due to hideous cost) one can use appropriate inserts and/or design a far more complex tolerance adjustment approach.

I'll post various other truss related components soon.

Best, peter

Attachments:

202-UAE-PLANAR-34R.zip, 1.2 MB

Permalink Reply by Jon Mirtschin on February 13, 2012 at 12:50pm

It's an impressive part. I do admit to date most of the work done with my tools, Assemblies has still primarily been fairly static objects primarily steel beams/mullions and plates that are bolted welded.

I think CIS/2 is probably the best neutral format to describe this type of connection. I'd be interested if you could try exporting there from Bentley (and posting or sending it to me). I'd be also even more interested to hear that you could round trip the CIS/2 model data (ie import it back to the application and get a quality part back). If you get a "meshed" version of the parts, then this tack isn't worth pursuing, we'll soon see.

Cheers,

Jon

Permalink Reply by peter fotiadis on February 13, 2012 at 1:10pm

I'll try to do some meaningful (??) CIS/2 assembly out of this (but for ethical reasons, he he, I'll fix ASAP some extra stupid things in these weird "hinges" - the axial offset (vertical zig-zag cables) could be addressed with a far better way). But why we still do this business? What about windsurfing (wave)? Dog training? Gardening? Bird watching? Space traveling?

In the mean time: whilst MicroSomething can't talk to Masters of all things (CATIA/NX) poor humble Rhino performs faultlessly (at least with regard geometry).

Permalink Reply by peter fotiadis on February 13, 2012 at 3:02pm

Here's a far more reasonable approach to that offset issue

Attachments:

202-UAE-PLANAR-35.zip, 1.4 MB

Permalink Reply by peter fotiadis on February 14, 2012 at 2:10pm

Some updated parts (Microstation + NX). These are all we need for creating the real truss (except the base bits) and the planar glazing facade system.

By resolving the opaque paneling puzzle and other topics of interest...the whole approach in the definition is already obsolete. This is the influence of the "bottom" to the "top".

Complete base details soon.

Attachments:

202-UAE-PLANAR-36TOP-B.zip, 2.4 MB
202-UAE-PLANAR-36-B.zip, 1.4 MB

Permalink Reply by peter fotiadis on February 15, 2012 at 6:01am

And something that influence "local" parts (the local assembly of them actually) and therefor influence the whole. Only 50mm (more) that can change everything...

This bracket takes care of that non planar glass panel situation (adjustment is 6 degrees around sym axis and 5mm plus/minus across sym axis).

Of course the cost of the planar system goes sky high...meaning that we arrive where we have started (i.e into the rabbit hole, door sealed).

PS: CATIA reports that this "hangar" has ~37000 "parts" (on the level of detail shown so far - no bolts/washers and other trivia are counted).

What a life!

Attachments:

202-UAE-PLANAR-36-B-Var-Bracket3.3dm, 1.2 MB

Permalink Reply by peter fotiadis on February 18, 2012 at 2:33am

He: What’s this?
me: Er…it’s the building, I do hope
He: Are you kidding? That’s a f*** sketch
me: Er…it’s the trad approach Sir: first comes the promise then the despair follows.
He: Is this SketchUp?
me: No…it’s a revolutionary thing called Grasshopper
He: Are you kidding? Why not Cockroach?
me: Brilliant idea Sir, can we talk now about fee matters Sir?
He: Are you kidding? Where’s the building?
me: Er…it would be, I do hope with a few mouse clicks more.
He: How many clicks?
me: Er…about 34567,54 I guess.
He: Money…could be, then
me: Yes Sir, much obliged Sir.
He: I want it bigger (like Godzilla: bigger is better).
me: But Sir…we’ve talked about that already.
He: Say it again?
me: Sir, this means a major redesign in too many “parts”
He: Is this my problem?
me: No Sir, It’s my f*** problem Sir

Thus facade goes enormous, parts are beefier, the whole system is redesigned, tolerance policy becomes critical, the definition is rather wrong, life couldn’t be uglier.

Worst: I’m out of cigars, espresso and vodka.

Moral: Path to revolution is long (and hilly)

Attachments:

202-UAE-PLANAR-40.zip, 2.3 MB

Permalink Reply by peter fotiadis on February 22, 2012 at 9:31am

UPDATE:

Bad news: Switched to CATIA in order to do the real thing (I'll post some pics when things are "under control").

Good news: Continue to play with GH - it's fun in some aspects (and nerve braking in quite a few others).

To do in next update(s):

(a) put some dynamism in these planar glazing facades (struts are vertical = pathetic, should be "radial" = good, same applies to the secondary truss members).

(b) resolve the canopy tubes (they are modular) and make the roof modules.

(d) provide real (fixed) parametric parts to put them in place (assuming that definition is fixed).

(e) replace cables and components with VB stuff (but debugging is a non existed thing, or I've missed something?)

Kudos to Jon "GeoGym" Mirtschin for his kind assistance in some dead-ends.

Be the Force with us.

Attachments: