nd me to kill him but give him my regards anyway) is still around in BirdAir Italy ... talk with him.
3. Hope that you understand that designing the "details" means some decent MCAD app + FEA + this + that. "Fusing" this with some abstract graphic editor like GH ... is ... er ... impossible (in real-life, you know, he he ). Generative Components on the other hand may qualify but requires a lot of time in order to fully master it (approx 2-4 years).
4. FormFinder ... well ... that's utterly Academic but on the other hand ... (good luck).
http://www.formfinder.at/main/software/team/
5. http://tecno.upc.edu/cotens/software.htm
6. This is the second best (after the BirdAir internal stuff) but costs an arm and a leg
http://www.ndnsoftware.com/
7. This is a !%$!%$ in the !%$%!$:
http://www.sofistik.com/no_cache/loesungen/fem/leichte-tragwerke/
My realistic (low cost) advise:
use K1/2 (especially if you are after "parametric" exploitation(s)) ... and then diversify tasks: stuff for the structural department, stuff for whom claims that he can(?) design the "details" ... whilst be in a constant contact with the membrane provider (and in fact: the contractor for doing the real thing as well)
…
th a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).
3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).
4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).
5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).
6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.
best, Peter…
and Grasshopper installed, or Rhino 6. 2-Install GHPython from here (Rhino 5 only). 3-Select and drag all the userObjects (downloaded here) onto your Grasshopper canvas. 4-Restart Rhino Grasshopper.
Check out our example files to get yourself familiar with typical SkinDesigner workflows. Also SkinDesigner Tutorials will be posted in this YouTube playlist as they become available.
You should also feel free to post any questions, feature requests, or bug reports to the SkinDesigner Grasshopper Group as discussions. Finally, SkinDesigner is an open source project and all of the project’s source code is visible on SkinDesigner’s Github site as well as within the Grasshopper components (by double-clicking on them).
…