Grasshopper

algorithmic modeling for Rhino

Well friends,

This is my very first attempt in Grasshopper.

In fact I'm doing the very same thing in Generative Components ... because Microstation is a far better AEC platform (VS Rhino) when the parametric exploitation is over. On the other hand Rhino is far superior with regard NURBS capabilities/tools and Grasshopper is 10 times faster (due to a mysterious reason Generative Components becomes ...er... slower from build to build to the extend to be rather "stationary", so to speak - he he).

Back in this naif example: Code is rather garrulous and/or stupid (to say the least) and worst : lass than 2% of the work is finished (smart stuff is like 3rd marriage: triumph of hope VS experience).

See some observations of mine as well (use Saved Views).

I'll be back with a far more realistic approach on the tower theme (and a far better looking solution).

All the best, Peter

 

 

Views: 5770

Attachments:

Replies to This Discussion

Great.

I'm switching to MB-ST mode (Merciless Beta-Smoke Tester).

Comments/Questions/Whatever ASAP.

Had plans to fire up my Ducati in the death road (Athens to Epidaurus) this weekend, but this thing appears more dangerous, so forget the ride.

Best, The Merciless

Hi Jon,

1. Thanks for allowing me to take part on that adventure - I own you a big one.

2. Er ..hmm..here's the MSQOTA (Most Stupid Question etc etc) : how I can get a proper floating IFC Tree instead of that docked colossal thing? (I hate windows > I'm a unix man in disguise).

PS: I'll try to do some IFC def on that ugly thing attached (think a desert, add hole, add truss, add "symbol", add stupid things, rename to Tech Museum, get the cash, go to Monte Carlo, shed the cash, repeat). And why may you ask? Hmm...until that IFC thing use Model Tree in Reader and see a totally different classification "schema" from what is "ordinary" in AEC...meaning that a Visual Tree "Re mapper" is the most important thing in GH (OK, OK a "multi Canvas" capability comes first).

Cheers, Peter  

Attachments:

Omens are against me > what this message means? (good old XP pro - I hate progress in O/S)

This error message is easy to fix (but not so easy as to why it occurs on some computers).

If you run rhino command GrasshopperDeveloperSettings and untick COFF loading.  Then restart Rhino Grasshopper and this error message should be a thing of the past.  With the docking of the tree viewer, hold down the shift key while dragging it around the workspace, and it should prevent it from docking.  Picking in the striped bar below the cross (in your viewport) should allow you to relocate it.

See this as well

The 3d pdfs are really impressive.

If you've ideas and suggestions (or questions) about how the IFC hierarchy and relationships might relate your own own ideas, preferences and work flows, I'm happy to give some opinions and insights.

I'm not sure how how you are getting the models in Rhino (when I last looked at MS a few years ago it had 3dm file reading and writing but we had problems at the time).  But if it does come in with equivalent of nested blocks etc, I was looking at means and ways of expressing this hierarchy in IFC.  If you wish to send any representative samples of a model such as this, then I'm also happy to look at and advise.

The tree viewer was my first effort at enabling access to the model in this fashion.  Lots of scope for improvements, and as I said in my email, my priorities for improvements comes from user requests and suggestions.

Hope you're up and running better with the suggestions above.  

Well Jon,

I have good news, bad news and ugly news:

1. The good ones are the obvious.

But the whole "decomposer" thing must brake free from IFC slavery - I can Imagine 1Z (Zillion) things related with AEC stuff that are quite difficult (and meaningless) being classified the IFC way (so to speak) not to mention that their "classes" are on-a-per-case (in most of cases). We need a Canvas inside the Canvas for visually re-arranging trees (i.e mixing bananas with banana splits). I'll be back on that critical  matter soon - with examples

2. The bad news:

This is MicroSomething pushed to the limits (for MicroSomething standards, he he):

PS: In fact you need SLI/CrossFire stuff (and NVidia FX Quadros 4/5xxx to effectively design similar things up to a decent level of detail, that is- a task perfectly OK for NX, forget BIM > in order to finish the race you must finish it first).

3. The ugly news (no 3dm export around only STEP, but as I said earlier...well, can I have the next question please? he he):

Yes...no structures/nesting/nothing > meaning a useless collection of scrambled eggs...er..I mean things > a rabbit hole of colossal proportions > zero > adios amigos.

Moral: the path to glory is long (and hilly)

Best, Peter

More ugly news:

I'm sure that you know the notorious HARNESS thing (based on the work of the GREAT Christoffer Alexander - http://www.patternlanguage.com/leveltwo/ca.htm).

Well, I did my stuff on that matter (get a set of spatial relations > adjacency matrices > cluster analysis > ... > double espressos (a lot) > spatial arrangements of things > ... > triple espressos > ...). Code is in my beloved Unix O/S (on a H/P internal product: the good old ME30).

This is one result with regard a WIP hospital "grid" (no fancy non-rectilinear geometry, mind, he he) where the nodes are vertical prefab units, the connecting trusses are the floor support system, the prefab patient rooms may (or may not) being present etc etc etc. Other than the obvious HVAC/people vertical "weaving" ... this is an endlessly expanding thing - because especially hospitals are already obsolete the day that they start operating (tech advances etc etc). 

In a good day (so to speak) you can solve this mess by addressing questions of type: make an arrangement where the sum of all human movements is the minimum possible (but what about the cats? that's the 1M question).

This thing could be interesting for you for testing IFC classification matters - what belongs to what (and why) - but only if that MicroNothing could STEP export an iota to Rhino. Doing this with GH (and not get lost in a sea of {0;0;0;0;0;0;0....;1} er...hmm...what about a visual tree manager on a multiple Canvas (and sub Canvas) thing? i.e. Pick a populated "dot" > get the list of stuff in a sub-canvas (and a way better preview of points) > pick another dot > get the list in another sub-canvas  > ah! these are the things that I'm after > combine them > connect them > weave them > whatever >  ... > possibilities are endless

Notice that the tree on that thing should adapt according the discipline in question: for instance and with regard the Structural perspective what could be the ideal hierarchy of things? Based on what schema? And if there is such a thing ... is it compatible with the Architectural (i.e. space utilization) perspective? What if I need to further expand the tree on selected branches? How deep this expansion should go before calling Samuel Cray?

Best, Peter

 

Sure, testing and exploring scenarios such as this is certainly a task that I could see Grasshopper being a useful resource.  I haven't personally been involved in design aspects such as this, certainly if there are other software tools that can analyze the performance using IFC as an input/specification it would be fantastic.

With regards to your sub-canvas, have you seen Clusters in Grasshopper?  These were a little more robust in earlier version of Grasshopper in terms of subsequent edits, but they behave as I'm understanding your explanation.  You can "collapse" a grouping of components down to a "representative" single component.  I think David is working on the editing aspect of it, at the moment you can "expand" back out as a new canvas to view the internal workings.

I'm sure there are plenty of improvements and ideas for improvements to my tree viewer and decomposing components.  I welcome user input for these and as I mentioned in the email, my priority list for improvements is defined by these requests and suggestions.  IFC does include attributes and relationships of more advanced nature than the "decomposing" hierarchy I've demonstrated, but I haven't had many requests for interacting with these yet.  I'm happy to help explain these further if there are needs to apply them.

Cheers,  Jon

OK, whilst I'm testing some IFC schema (a meaningful one, hopefully) get a layout of that eternally expanding hospital thing - as a foot for thought (either for GH code or for IFC classes puzzles):

1. Amuse yourself by trying to figure what kind of series logic could deploy (or not) these room unit combos across the blue space grid shown.

2. Let's assume that surgery etc etc departments are sited in some ground floor and their requirement for rooms is variable  ... meaning that some kind of heuristic GH approach must be applied here (for instance : fill the first level with rooms required by all departments  with min distance from a given core and if more are required go to next floor etc etc).

The real room unit cluster looks like that (all units are prefab)

3. Voids in the whole cluster deployment (avoid Soviet type of bloc aesthetics) mean that culling could be challenge here (we need ...er..."visual" culling , so to speak)

4. After finishing some solution create custom preview(s) in order to visualize what dept owns what rooms.

5. If in trouble with Architectural things > relax > be cool > open 3d PDF > be a great Architect in just 10 easy steps.

PS: of course I know GH clusters...but as they are they violate my rule N1: never walk the walk if no return is possible, he he. But assuming that David could resolve the return issue (sure he can) this is NOT the answer for my "proposal" for multiple Canvas - again like multiple Views in any CAD stuff these days. Just imagine clusters with some serious hierarchy depth > where am I ? what input comes from what output?

I'll be back with a chaotic case (Series in complete anarchy) in order to demonstrate the critical necessity for a visual Tree Manager/Viewer (a visual thing within the GH visual thing). For manager read : decomposer, composer, visual identifier (per data item/branch) tree re-mapper, anything actually.

more soon (and a in depth analysis about what a Tree Manager/Viewer should do - in an ideal world, that is)

Cheers, Peter

Attachments:

I personally think to get the best result, the planning/layout should be done utilizing human intelligence (computers are just fast number crunchers, they have near zero intelligence).

So my approach would be to use Grasshopper as a tool to calculate/report performance on aspects such as surgery theatres from central core, with ability to explore options/scenarios embedded into the generative grasshopper model definition.

I'm happy to help as I can, I look forward to hearing the suggestions about the tree viewer, I would like to make many improvements to it.  I've only demonstrated physical relationships, note that IFC can also convey process, occupation, resource, cost, sequence and spatial relationships amongst others.

Indeed, computers are stupid (and if you add some Quadro FX 4/5xxx combos quite expensive).

OK, let's stick to the core of the matter > can you save the word in just 10 easy steps? (maybe a few more, he he) > that is creating some plug in into the GH plug in > managing that GH Tree thing (not simply decomposing it).

I'll post the mother of all threads here soon (a deliberately fuzzy stupid mix of grafts/flatten/and such) in order to give you some food of thought (and ignite the mother of all debates) about what is needed (and why).

That said the word is divided into Lab fellas and the rest. Lab fellas believe that Earth is round, has therefor no end and everyone can have a Big Mac. But truth is that Earth is flat (anyone can tell that), has a definitive end (see Maya calendar: 12 Dec 2012) and Big Macs are only for the chosen few.

I mean that in theory GH has all the tools to do anything...problem is that you do smart stuff at 11pm, tired, dizzy and worst of all : out of espresso, red Russian vodka and cigars.

Get another truss delirium - detail greatly reduced in order to avoid posting a 89Mb PDF (usual recipe: add desert, don't dig this time, add this, add that etc etc).

Notice the need for clarifying (should I say visualize?) what point talks to what point(s) and why. I'm outlining the need for a visual re-mapper as part of the future Tree Manager repertoire of capabilities. Doing {a;b;c;d}(i) > {c;d}(i) is a no no thing at 11pm. 

Best, Peter

 

Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service