Indeed this is not Rhino (but I work with CATIA, NX, Microstation and that ...er...hmm...Generative Components thing as well).
This tensile membrane project in particular is made with Microstation.
The generic problem with the 2 apps that support dependent modelling (MS, Rhino) is that they are both very poor in Assembly/Component concepts/tools/you name it. Defining topology is one thing...but real life projects demand a bit more than that.
And given the opportunity some (extra cynical) notes of mine with regard the new "trend" in architecture (supported by dependent modeling as found in Grasshopper/Generative Components/and soon in certain AutoDesk products).
See this? A 2400 seat WIP Opera Project. Imagine an outer envelope kinda a "shell" made by custom MERO members (a bit stupid engineering solution I confess) ... and various interior "shells" (concrete) that define the in-topology : audience/stage/workshops/activities/etc. About 70 heavily nested 3d files compose the total solution (in Final Level Study, meaning nuts and bolts Level of Detail).
On first (a bit Academic) consideration the envelope could be "easily" made by Grasshopper and/or Generative Components (patterning of some sort) by arranging MERO nodes and truss members across some V/U derived bezier curves ....the only problem is that the solution should...er...be a real-life arrangement of real-life nodes and truss members (not to mention real-life milling axis etc etc).
What about interoperability between the Architectural and the Structural Design team? What if the Structural Analysis/Feasibility study/etc indicates that the solution is not viable?
All that ... before designing some real-life skin support system (final skin: custom metal panels + 100mm Foamglass + membranes + custom alu support system + VM Zink).
All that...having in mind that some specialized manufacturer (like Donges AG) could receive structured 3D data that could/should comply with the way that MCAD apps - the likes of NX/CATIA - do business.
And that's the CATCH 22 these days: no non MCAD app supports any kind of meaningful assembly-component entity management. See for instance how naif Microstation is on that matter...not to mention Rhino (Rhino can't even manage different collection of entities on a per View basis - not to mention Dynamic Clips etc etc etc).
So the 1M question is : what serve power without control?
OK. Assembly/Component is a generic term...er...meaning methods and ways to manage hierarchies of...things...(nodes) either void or not (with regard some kind of entity related data). In MCAD apps you can work in any node of a given hierarchy tree (loaded in your work session) by making the node "active". "Nodes" can be other things as well (like workplane, clip definitions etc).
Why to do that weird thing? Well, think any design being "flat" > meaning that all objects are placed in a single file (and in a single layer). Not that good > although the items are present you barely can handle them (because power is nothing without control, he he).
Let's go one step further: we can start classifying objects in "groups" (like a directories/files organization in any O/S). This means, in MCAD speak, creating assemblies (a void thing kinda like a directory) that contain components/entities (kinda like files).
Several steps further we end up with severely nested "arrangements" of entities (an assembly could be parent of something and child of something else).
For instance, it could be rather obvious the logical classification of a "geodetic" (so to speak) structure like this : a 40000m2 "hangar" defining some thematic park.
I mean : a void master that owns 4 equal void segment sets that own 4 "legs" that own various geodesic structural members + cables + membranes + you name it etc etc.
Each "leg" owns the concrete base (Shared) and a rather complex set of objects.
Notice that some tensile membrane "fixture" combos (see above)...act as perimeter light fixtures as well...meaning that the membrane tension plate may could be a child of a void "light" parent...or may could be a "stand alone" assembly etc etc.
These arrangements can be internal (belonging in, say, a x node within the current active file) or external (belonging in a y node within another file). If they deal with the same (topologically speaking) object they define clusters of Shared entities (or variations)- where only the view transformation matrix changes (in the simple scenario, he he). For instance the disk shown above is a Shared Assembly that owns the bolts, the plates, the tension member etc etc. Selective Instancing allows modifying some attributes without affecting the topology (i.e. the geometry).
The whole (terrible) mess is controlled by some tree like "dialog" (in Catia is "transparent") that is called Structure Browser. By controlled I mean (1) display/display mode with regard any tree member combo/selection set (assembly and/or component) in any View (2) clip state control (3) active status (for modifications/variations) (4) workplane control (5) drag and drop ownership control (6) ....
All in all: the problem here is not to create the geometry/topology (that's the easy thing). The problem is to arrange in 3d space existed complex assemblies (like the green membrane tension "plates") in such a way that a meaningful hierarchy could be maintained (and exported) prior AND after the solution (in fact one solution out of many).
BTW: see the Catia "transparent" Structure Browser in action.
The fact that in Grasshopper you can "pick" an existed collection of objects ...and...continue from that point and on (is rather a mess to do it in Generative Components)...well...is the main Grasshopper attraction point. On the other hand, a totally new way to manage the visual programming canvas content (with regard complex/nested/hierarchical stuff etc etc) is urgently required.
taz
Um, cool but this isn't Rhino...
What is this software?
Jun 8, 2011
djordje
fantastic!
Autodesk robot sofware?
Jun 9, 2011
peter fotiadis
Indeed this is not Rhino (but I work with CATIA, NX, Microstation and that ...er...hmm...Generative Components thing as well).
This tensile membrane project in particular is made with Microstation.
The generic problem with the 2 apps that support dependent modelling (MS, Rhino) is that they are both very poor in Assembly/Component concepts/tools/you name it. Defining topology is one thing...but real life projects demand a bit more than that.
Jun 9, 2011
peter fotiadis
And given the opportunity some (extra cynical) notes of mine with regard the new "trend" in architecture (supported by dependent modeling as found in Grasshopper/Generative Components/and soon in certain AutoDesk products).
See this? A 2400 seat WIP Opera Project. Imagine an outer envelope kinda a "shell" made by custom MERO members (a bit stupid engineering solution I confess) ... and various interior "shells" (concrete) that define the in-topology : audience/stage/workshops/activities/etc. About 70 heavily nested 3d files compose the total solution (in Final Level Study, meaning nuts and bolts Level of Detail).
What about interoperability between the Architectural and the Structural Design team? What if the Structural Analysis/Feasibility study/etc indicates that the solution is not viable?
All that...having in mind that some specialized manufacturer (like Donges AG) could receive structured 3D data that could/should comply with the way that MCAD apps - the likes of NX/CATIA - do business.
And that's the CATCH 22 these days: no non MCAD app supports any kind of meaningful assembly-component entity management. See for instance how naif Microstation is on that matter...not to mention Rhino (Rhino can't even manage different collection of entities on a per View basis - not to mention Dynamic Clips etc etc etc).
So the 1M question is : what serve power without control?
He He
Jun 11, 2011
djordje
great opera!
you really are something.
But I did not quite understand you.
What are the advantages of NX and Catia in comparison to Rhino and Grasshopper?
Jun 11, 2011
peter fotiadis
OK. Assembly/Component is a generic term...er...meaning methods and ways to manage hierarchies of...things...(nodes) either void or not (with regard some kind of entity related data). In MCAD apps you can work in any node of a given hierarchy tree (loaded in your work session) by making the node "active". "Nodes" can be other things as well (like workplane, clip definitions etc).
Why to do that weird thing? Well, think any design being "flat" > meaning that all objects are placed in a single file (and in a single layer). Not that good > although the items are present you barely can handle them (because power is nothing without control, he he).
Let's go one step further: we can start classifying objects in "groups" (like a directories/files organization in any O/S). This means, in MCAD speak, creating assemblies (a void thing kinda like a directory) that contain components/entities (kinda like files).
Several steps further we end up with severely nested "arrangements" of entities (an assembly could be parent of something and child of something else).
For instance, it could be rather obvious the logical classification of a "geodetic" (so to speak) structure like this : a 40000m2 "hangar" defining some thematic park.
I mean : a void master that owns 4 equal void segment sets that own 4 "legs" that own various geodesic structural members + cables + membranes + you name it etc etc.
These arrangements can be internal (belonging in, say, a x node within the current active file) or external (belonging in a y node within another file). If they deal with the same (topologically speaking) object they define clusters of Shared entities (or variations)- where only the view transformation matrix changes (in the simple scenario, he he). For instance the disk shown above is a Shared Assembly that owns the bolts, the plates, the tension member etc etc. Selective Instancing allows modifying some attributes without affecting the topology (i.e. the geometry).
The whole (terrible) mess is controlled by some tree like "dialog" (in Catia is "transparent") that is called Structure Browser. By controlled I mean (1) display/display mode with regard any tree member combo/selection set (assembly and/or component) in any View (2) clip state control (3) active status (for modifications/variations) (4) workplane control (5) drag and drop ownership control (6) ....
Now...what if I would chan
Jun 11, 2011
peter fotiadis
All in all: the problem here is not to create the geometry/topology (that's the easy thing). The problem is to arrange in 3d space existed complex assemblies (like the green membrane tension "plates") in such a way that a meaningful hierarchy could be maintained (and exported) prior AND after the solution (in fact one solution out of many).
BTW: see the Catia "transparent" Structure Browser in action.
The fact that in Grasshopper you can "pick" an existed collection of objects ...and...continue from that point and on (is rather a mess to do it in Generative Components)...well...is the main Grasshopper attraction point. On the other hand, a totally new way to manage the visual programming canvas content (with regard complex/nested/hierarchical stuff etc etc) is urgently required.
Quest3D has some answers on that matter.
Jun 11, 2011
peter fotiadis
BTW: Get this 3d PDF and study the (naif) entity structure that Microstation can do on that matter using the Model Tree Dialog in Adobe Reader 9.x
https://rapidshare.com/files/3133775907/170_ThematicPark_V5_STR-STR...
Pretty much the same situation in Rhino as well...meaning that talking to applications that actually "make" our designs is not that easy.
Jun 11, 2011
peter fotiadis
BTW: Hope that you know that little gem :
http://www.cerver.org/?page_id=492
Not an alternative to FormFinder (genius algos, totally academic application) but not bad for a start.
Jun 12, 2011