capture_032

Comment

Comment by peter fotiadis on June 15, 2011 at 2:13am

To give you a better view of things (the way that I see them, he he) I'm going to post here (in Rhino format) some portions of that ugly thing : a Project that started life ...er...3 days ago > a collection of 6 inverse conic membranes (the new Birdair stuff with that wonder mysterious insulation) that host an exhibition facility in some Middle East country.

For the moment, the "idea" (a bit silly) is to design some parametric metal truss that supports the membrane ("roof") and some custom planar glazing system that supports the exterior skin ("walls"). The "plan" (so to speak) is to outline the generic stuff in Microstation and then use Grasshopper for some "intelligent" portions of the metal structure (214 STEP format used for export/import)...and then transfer the whole thing to Catia for completing the study in nuts and bolts level of detail. Anyway..that's the theory...kinda like the third marriage: triumph of hope VS experience, he he.

 

As you'll discover soon...the "intelligent" parametric truss is the 1/100th of the whole challenge. Why so? Well...let's say that the client requires an accurate cost estimation of the whole envelope system BEFORE signing the dotted line (an almost impossible task, but let's pretend that's doable,

 

More in a while...

Comment by peter fotiadis on June 15, 2011 at 1:23am

"Gem" is a shortcut of "gemstone" ...meaning something "valuable"...like the min surf algos that could be useful in some future tensile membrane design application (Rhino Membrane is not the answer to that - not interactive enough for real topology exploitation(s)).

 

Let's say : kinda like the Formfinder Pro (useless as it is).

 

BTW: a proper Interactive Membrane design (in Final level of detail) application could worth solid gold. Keep in mind that designing the membrane layout is one thing....designing a myriad of custom tensile system metal members (fixing stuff, cables, masts, anchors etc) is another animal.

 

BTW: Given the opportunity study the entity names in View borders > notice that you can work (on a per View basis) with totally different (and independent) entities that compose the whole thing (in some kind of hierarchical relations the type parent-son etc). BTW: This (naif) case above can outline my thesis with regard the current state of dependent modelling as found in Grasshopper/Generative Components: Imagine having a simple task > cover some stadium with a primitive tensile membrane system. By cover I mean delivering a Final Level study of the whole thing (ready to be made). OK...the first step is to create some kind of script for the metal truss (AND for the metal trusses as a set). In that task Grasshopper beats Generative Components hands down...but...is this the main thing here? No, because the auxiliary things required (see Images: the real-life "details" of each truss and the fixing system as a whole) are 100 times more difficult (and time consuming) than creating some intelligent automated process for the truss abstract topology. But assume that some kind of ready to made "parametric" truss is made somehow...then...the membranes follow > and if we need some "parametric" process for these...meaning that the truss affects the truss set that affects the membrane layout/topology that affects the stadium layout....then we end with a "hierarchy" of complexity that clearly can't be addressed by the currently available methods.

 

And speaking about the visual GH programming approach... It's more than obvious what kind of "Canvas management" is required to address hierarchical intelligent modeling. Don't forget to include "component location" FROM Views TO Canvas as well (i.e. what's this thing? where in the Canvas is defined? etc etc).

 

In a nutshell: the challenge in the future of CAD is to mastermind real-life methods to advance from the "parametric"  topology definition to...er...the real-thing ready to be made.    

 

 

Comment by djordje on June 14, 2011 at 12:44pm

it seems my english is not good enough to understand everything you said.

Although I am dying to know more about these projects of yours. Too bad.

 

For example, what is "gem"?

Comment by peter fotiadis on June 12, 2011 at 3:33am

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.

 

Comment by peter fotiadis on June 11, 2011 at 8:52am

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.

Comment by peter fotiadis on June 11, 2011 at 6:11am

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.

Comment by peter fotiadis on June 11, 2011 at 5:36am

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) ....

 

Now...what if I would chan

Comment by djordje on June 11, 2011 at 1:31am

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?

Comment by peter fotiadis on June 11, 2011 at 1:15am

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?

 

He He

Comment by peter fotiadis on June 9, 2011 at 7:58am

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.

 

 

• ‹ Previous
• 1
• 2
• Next ›
• Page