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

Hi Peter,

Nice work, congratulations.  

Rhino is seen as a tool in a software toolbox, rather than being the "toolbox", especially in AEC.

I've been working on a number of plugins to exchange information to other AEC software with smarter attributes and relationships than geometry only options (dwg, dxf, igs, stl etc).

I don't know how advanced the microstation importer for IFC is, but feel free to test it if you have the chance.  Note with nurbs shapes, you'll have to resort to the meshed version (unless they have implemented IFC2x4 aspects which does include NURBS).

I'm happy to help and advise if you need.

Cheers,

Jon

Hi Jon

Thanks for your kind words (but the code is so naif that make me cry, he he)

Ray Bentley (that one) he's a friend of mine (and several other Bentley top gurus) and thus I know pretty much everything that MicroStation does (or doesn't). The eternal debate between us is that they focus to the so called BIM aspect of things (and obviously on interoperability matters - that said IFC2*4 is" implemented" in certain Bentley verticals like BA and others) whilst I'm after assembly/component puzzles (and on that matter ... MS ...hmm... to put it politely is not exactly CATIA and/or NX, he he).

On the other hand this paranoid obsession with Level/Layer driven CAD (I hate it) defines a red thick line between CAD and MCAD - because the most intelligent importer can't emulate the way that Siemens NX/CATIA classifies objects - and without control power means nothing.

On the other hand Microstation V9 (...soon) has interesting scripting capabilities (think Modo rather Generative Components) ... meaning that Grasshopper could work there in a rather nice way. I think that I must talk for that to Ray (he recently ditched the ancient legacy MS render engine in favor for the Luxology/Nexus engine). Ray still is negative to buy Act3D mind (hope that you know the mother of visual scripting - the Quest3D VR thing).   

On the other hand - within the broad AEC aspect - things these days are different (especially in fast developing countries the likes of UAE, Saudi Arabia, certain ex USSR "democracies" etc etc). Studies are outsourced even at Preliminary Design stage to various sub-contractors (they undertake the Study completion per discipline as well). This means that N separate groups doing M aspects of the whole ... meaning entropy^(N*M) - that's chaos in plain English.

With this in mind I'm quite (a lot) skeptical about the practical meaning of the whole exchange thing in AEC - at least with regard the countries mentioned (not to mention that several portions of a modern AEC thing are made via MCAD apps - chaos^chaos.

I'll back with more focused issues on that matter.

But the big question is: Grasshopper of Generative Components? Well...let's talk serious SS bikes instead: think a Ducati 1198 and a BMW S1000RR (I have them both): which is "best"? The thing is that not always the best bunny is the fasted bunny and not always the fasted bunny is the best bunny.

Cheers,

Peter

 

Sounds like you have friends in high places, good for you.

I guess the conversation has quickly gone quite deep into the software.  I was responding to this quote, because it's something I feel strongly about.

... because Microstation is a far better AEC platform (VS Rhino) when the parametric exploitation is over.

I don't believe in one utopia of software.  I do think it's a waste of effort and potential to take a model to detailed stages of development in Grasshopper, and then start from scratch in the next piece of software for documentation and detailing.  It will obviously take some time to get to the stage where all our BIM models are efficiently capable of interop, but I do think one day we will get there.  I do think we are capable of advancing quickly into a superior state of affairs than present offerings.

If you do have the attention of Bentley decision makers, and they are interested in importing nurbs aspects of IFC2x4 (refer my sample below), then I would love to discuss this with them as I think it opens the door for nearly unlimited model exchange from Grasshopper direct to Microstation.  

Hmm... sounds interesting enough to say the least (for a zillion of reasons, not to mention that delicate non elastic tensile membrane thing - Bentley does nothing on that critical matter whilst even Nemetschek AG (the Allplan maker) is ready to boogie). 

PS: Of course there's no one and only one software Utopia (kinda like there's no best bike around - but what about a MV F4-1000 Tamburini?, he he)

PS: get this WIP thing (another testimony to human vanity, a kind of stupid tower of mine for some place far and away from Greece, he he):

Exploit the (rather) primitive assembly/component approach used (but Microstation can't think on a NX/CATIA level) using the Model Tree in poor old Adobe Reader.

Now... the really interesting bit: Assume that via some wonder "exchanger" all BIM related data are OK > what could be the benefit...if the x CAD app in question can't handle effectively nested assembly/component stuff? (don't tell to anyone ... but Microstation can't : Nested Cells are disaster and Nested Refs are ... disaster as well).

That's why I'm not a big BIM aficionado (but I do love ultra fast bikes, he he).

But back to smart stuff: the big question is: is Grasshopper capable to handle such nested structures? Of course it is...it's only that the whole "tree" thing needs "some" more visual clarification about what stuff belongs to what branch. If this is achieved in some future build ...expect a colossal Grasshopper expansion in a far broader audience (because truth to be said: understanding what belongs where ... it's a bit black art at present time). 

Some visual re-arranging of branched stuff (and a detailed visual exploitation of branches) could worth gold as well.

Best, Peter

Attachments:

I agree, and already it is possible to a certain degree.  IFC is based on step, and can convey the hierarchy and relationships as per your model.  I've progressed a tree viewer for this in Rhino (I want to add some icons for visibility and other editing / review).  You can also decompose (or break down this hierachy in Grasshopper, although it's not quite "generic" in that you might have to wire slightly different for different models (which can have different depths and paths for branches).  I think it's feasible provide components to automatically drill down to a particular "set" of items if that was useful.  I do need to find some time to expand and more accurately allocate some new icons.  See if you can make some sense of the diagram below, I'll do a more specific and self explanatory version if it helps.

I'm very interested on that Tree Viewer of yours.

I'll try to make a nested-nested-nested (and nested) thing for tests - what about a banana tree that has oak trees instead of bananas (and banana splits instead of acorn).

Er...a quick wish : doing GH stuff (without any geometry present in Rhino ) tells nothing to Rhino Zoom extends command (Fit View in plain Chinese). This is irritating to the max - can you do some wonder stuff about it?

PS: forgot to mention some bad news (for me) : MS can't export a thing in STEP...I mean a thing readable by the big fellas (NX/CATIA). Completing this Project (in Final level) in MS it's heroism beyond my imagination - thus what serve the whole smart stuff? You tell me.

Moral: CAD Interoperability is like the paperless office (it works in theory).

He He. 

If I understand Chinese, I think your best option is to change from Grasshopper canvas (double clicking in the top bar hides it neatly) and then typing in rhino command prompt Zoom E (extents).  David is very responsive to suggestions so he's the one to approach with the suggestion of executing this from Grasshopper.

Great, I'm more than happy to help you with testing and applying these tools.  Instructions for getting started can be found here:

http://www.grasshopper3d.com/group/geometrygym/forum/topics/install...

I've set up a simpler but hopefully clearer example of IFC hierarchy.  In this image, I'm creating a building with a slab for each storey, I've imported the IFC file already into Rhino (file attached) so you can see the tree viewer.

 


And this images shows decomposing the data tree in Grasshopper. 

The relationships are definied within the IFC specification, there are many possibilities of relationships, for example a project might have many sites, and a site might have many buildings.  And a site might comprise multiple sites etc etc.

That's a really impressive project, and I'm sure it's going to challenge any of the CAD/BIM software.  From looking at the image, I would say if the truss chords are curved that's going to give you the biggest headache using IFC (as it will approximate it using meshed representations, an advanced swept rail can be used if it's a tube but not many of the BIM software out there acknowledge shape representations like this).

I forgot to attach the files.

Attachments:

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service