ngy (as stand alone product). But on the other hand it's widely used and is the "standard" seed for cultivating the new generations. With this in mind I rate it ... er ... hmm... higher than Generative Components. Because GC (and the ParaSolids 3d kernel that derives from Siemens/NX) may be mighty (if we forget this, this and that, he he) but is almost totally inaccessible: requires several years of training and then ... yes ... it can eat GH for breakfast as regards AEC matters (but this IS NOT the point, nor it means that GH is "worst").
The analogy is: GH is like my FireBlade (homogenous, easy) and GC is like my Panigale (lethal if not treated properly). On the other hand Honda cells 100 times more Blades than Ducati Panigales.
2. This cultivation thingy is/was NEVER understood by Bentely Systems (I had some very nasty Skype sessions on that matter, he he).A critical mistake that one, but then again Bentley doesn't like going to bed with individuals and ... maybe ... they are in the right path (a bit hilly, he he).
3. Dynamo on the other hand ... well I'm a Bentley Systems man so "by default" I dislike AutoDesk products and/or bought ones (TSplines excluded). But humor apart ... I dislike Revit for a vast variety of reasons the primary being the approach for effective parallel/team work. AECOSim on the other hand is brilliant on that matter. But Revit is dangerously close to become the BIM standard (which means - by default - that's the wrong thing).
4. Thus ... are R/GH in danger for playing a role in real-life AEC? Well ... if there was not the cultivation thing ... maybe.
In conclusion: In Planet Zorg this is the way to do AEC stuff: GH (scripts only) + GH add ons (if required) + GC (works only with scripts anyway) + AECOSim + you name it + CATIA/NX + you name it.
Moral: A classic Alice in the wonderland case that one: i.e. an amoral one, he he
take care, Jack the Ripper…
. and the bad habits die last as they say. This means that ... well ... the adaptation to more realistic (and meaningful) things later on ...
3. I can easily provide some solution (ultra expensive in real-life) to do what you want but this would be carried over solely via C# code (NOT good for you especially when this would/could be used in some sort of Thesis). To make a very long story short the "curvy" parts is highly recommended being tubes ... and the "liquid" nodes required ... well ...that's another animal UNLESS one could accept an Academic over simplification by using balls of a slightly bigger R than the adjacent tube "struts" (whilst the "iso curves" [per BrepFace] would use an even smaller R and inserting crudely into the Brep Edge "main" curves). But since actually we are talking about a secondary random "lattice" per BrepFace the "iso curves" are actually stuff made via the Surface.ShortPath Method (not sure if this exists as GH component) using random points where their number is proportionally to a given BrepFace area (freaky stuff, trust me). This yields a "uniform" random secondary "lattice" in accordance to the whole "random"/liquid appearance of the T-Splne Brep.
The above a bit naive approach (obviously out of question in real life) can yield a solid thingy if we unite all the parts and bits (Rhino takes ages to do that if we are talking big numbers of Breps) ... thus some 3d printing is doable.
In other words we do a MERO "approximation" by hoping that no German guru reads this thread, he he.
We can provide a Frankenstein type of "pro" connectivity as well: since a Brep is actually kinda a Mesh (with regard connectivity of vertices, edges, faces et all) making the connectivity trees required is not a big deal (GH has the Brep Topology thingy as well).
But the whole solution could be a black box to you: if this what you want?…
was not all there myself. Overall the night wasn't that productive so I wanted to apologize, I will do a better job in the future.
Attached to this message is the Assignment sheet for the upcoming week. Please post the picture of the models before 7:00 PM Monday 2/16.
Here is a link to the completed script from last night, as well as the Rhino file and presentation pdf.
https://www.dropbox.com/sh/3g6fnue93dk8iub/AAB88CNVCtC64cmz_ENLlojQa?dl=0
A few notes:
- I added two separate tags to the end of the script. One set is for the 3D model of your form, locating where the pieces originally come from. The second set is for the flattened out sections, which can be etched on your pieces to actually locate them when they are physically created. Play around a bit in the script and try to understand what is going on between the different parts.
-Baking: We went over baking in last weeks class. You right click on the component you want in the physical realm and select bake. Rhino will then ask you to select a layer to place the items on. I would suggest having two layers, one will be for cutting and one will be for etching (when you bake the tags(optional)). Once the pieces are in Rhino, you can use the Make2d command and export to AutoCad where you can laser cut (if you are unsure about this process, Google it as there are numerous tutorials).
-I would recommend using chipboard as it is the cheapest and most readily available, but don't let me chain your creativity if you come up with another material.
I look forward to seeing your guys models. See you Monday!
…
pavilion) and from that i want to fabricate it using some paper or card bored .
for modeling the pavilion i used a simple kangaroo based algorithm to generate the desired form using mesh 3d plane faces . there was no problem with this part and i was able to get the mesh from geometry out put . then i wanted to use that output mesh to panelize it and then adding tabs and the nesting and cutting to get the parts. but the problem was every tutorial i looked up were using surfaces to panelize and nest so this was the first problem to convert the mesh into a surface and then panelazing and nesting . i tried using the mesh2nurbs but it didn't work out for me . (because i needed a single surface not some poly surfaces) . (attachment | input mesh )
so i started from the beginning and tried using a surface as an input for kangaroo and thus getting a surface as an output so i did that and tried to create a surface by the Surface from points component . and the result was not good the surface was kinda messed up and the the reason was the points were not ordered well i guess . so this was another problem for me . (attachment | input surface)(picture below)
so basically i have a few main questions :
1. is there a tutorial or any topic or book or somthing that explains from 0 to 100 from design to fabrication (as an example a pavilion) ?
2. can i use the mesh to panelize and nest and then fabricate ? and are there any tips or tricks to it ?
3. is the starting from surface for me a good idea or not ?
i am extremely sorry for talking this much and i'm grateful for the time you spent on reading this .
best wishes ; Babak.
…
chitects, Asymptote Architecture, Mario Bellini Architects and others to design the paneling systems.
Get a quick introduction to Rhino and Grasshopper.
Learn how to digitally reconstruction data from 3D scanners and even from regular photographs.
Experience how to print 3D models using state of the art machines.
Grant the opportunity to perform basic energy and performance analysis of your designs.
All this will be provided in a comprehensive 5 days workshop to be taught by international experts in the field as well as local researchers.
Organized by AUC American University in Cairo and GMVS Geometric Modeling and Visulization Center
…
Added by Zaghloul4d at 6:48pm on December 22, 2010
sistance of radiative and convective heat transfer through the _filmCoefficient input on the "Create Therm Boundaries" component. This filmCoefficient in W/m2K represents the "U-Value" of the air film between the edge of the THERM materials and the surrounding environment that is at the specified _temperature. The extra resistance from this air film is why the full construction U-Value that you are getting out of THERM is a lower than just the (conductivity of material) / (depth of the material). Accounting for air films is particularly important when you get constructions that have a high overall conductivity (like a single pane window), since almost all of the resistance of such a construction is due to the air films.
To elaborate further, you might have noticed that, in the example files on hydra, I set this filmCoefficient to be either "indoor" or "outdoor", which basically uses some code that I wrote to autocalculate the film coefficient for you. I take into account both the emissivity of the material at the boundary (which gives you more air film resistance for lower emissivities) as well as the orientation of the boundary in the 3D space of the Rhino model. The code I wrote will take these parameters and match them to those published in ASHRAE Fundementals, which you can see in table 1 of the first page of this PDF:
http://edge.rit.edu/content/C09008/public/2009%20ASHRAE%20Handbook
I interpolate between these values in the event that your emissivity is not 0.05, 0.2, 0.9 or the orientation of your boundary is not any one of the 5 that they give.
I know that THERM also has the capability to actually run the radiative and convective formulas that you posted, Mauricio, as opposed to just using a single film coefficient to account for all of this resistance. The running of these formulas is particularly useful is the radiant temperature at the boundary is different than the air temperature. However, as long as you are ok with this assumption that the air and radiant temperatures are the same (which is the case for all of the situations that I have encountered), the film coefficient is perfectly sufficient. If anyone ever has need for this capability of running boundary conditions that have different radiant and air temperatures, please post here and I can think of a way to implement it. I rather like the simplicity of the current interface, though, and I think that I will keep it this way until we understand the purposes for why someone would need separate radiant and air temperatures.
-Chris…
nteraction in the design of an enclosed volume.
Revolutions have occurred through architectural history and vary widely in terms of design methods and fabrication techniques. Focusing on inspiring natural form‐finding techniques, AA Athens VS works towards producing a large‐scale interactive prototype that alters in real‐time the perception of interior space.
Technology and architecture are coupled for the third year in Athens with a novel agenda of transforming an enclosed area and creating internal contrasting city‐life characteristics that transcend the local conditions. In collaboration with the National Technical University of Athens, Cipher City: Revolutions explores participatory design and active engagement modeling and continues building novel prototypes upon horizontal planes.
The toolset includes mainly ‐among others‐ Rhino Grasshopper, Processing and Arduino platforms. With the completion of the Programme participants receive the AA Visiting School Certificate. In 2013, the design agenda of AA Athens will connect with the agenda of AA Greece VS in the city of Patras. Participation in both Programmes will allow for a more extensive learning experience through additional tools like Autodesk Maya, Autodesk 3D Studio Max and more.
Discounts
The AA offers several discount options for participants wishing to apply as a group or participants wishing to apply for both AA Athens and AA Greece Visiting Schools:
1. Standard application
The AA Visiting School requires a fee of £600 per participant, which includes a £60 Visiting Membership. If you are already a member, the total fee will be reduced automatically by £60 by the online payment system. Fees are non-refundable.
2. Group registration
For group applications, there will be a range of discounts depending on the number of people in the group. The discounted fee will be applied to each individual in the group.
1. 3-6 people group: £60 (AA Membership fee) + 540*0.75 = £465 (25 %)
2. 6-15 people group: £60 + 540*0.70 = £438 (30%)
3. more than 15 people group: £60 + 540*0.65 = £411 (35%)
3. Participants attending AA Greece VS and AA Athens VS | 40% discount
For people wishing to attend both AA Greece VS and AA Athens VS, a discount of 40% will be made for each participant. (The participant will pay the £60 membership fee only once.)
£60 (AA Membership fee) + (540*0.60)*2 = £708
Eligibility The workshop is open to architecture and design students and professionals worldwide.
Applications
The deadline for applications is 24 March 2014. A portfolio or CV is not required, only the online application form and payment. The online application can be reached from:
http://www.aaschool.ac.uk/STUDY/VISITING/athens
Contact:
Alexandros.Kallegias@aaschool.ac.uk…
BIM world.
I can well imagine that modeling your design would be a lot more cumbersome in GH. It does not lend itself to the kind of wall to wall 'algorithmic design' that GH is geared towards. I suspect the approach RhinoParametrics takes will yield comparably quick results. I think GH could equal this ease of use and eventually better the MCAD-style 'feature based' approach Inventor/RP uses.
The design has a lot of arbitrary setting out points, and parameters that are not amenable to an overarching mathematical formulation like 'replication'.
It also is more fragmented, where there is no obvious 'starting point' or 'root input' for the whole design. Not sure, but changing one 'roof assembly' look like it would need to propagate to the adjacent assemblies. This would be a problem for GH's DAG?
The arbitrary nature of the design components/setting out, would ideally be defined 'by hand' using traditional CAD event-driven techniques. I guess Inventor's 'features' are like mirco GH scripts that are placed and manipulated as part of its 'main loop', and provides the user all the feed back, alignment and snapping aids that have been accumulating over the years.
The snapping would also be 'persistent', and a geometric constraints solver built into its 'history tree'. Like most MCAD modelers, defining profiles with standard geometric/dimensional/algebraic constraints, using a 'sketcher' is pretty quick, and doesn't require any scripting. The 'declarative' way that the constraints are defined, is going to be far quicker than the 'imperative' / sequential way GH's relies on parametric math. I guess, GC will regain the upper hand when the design can't be described with constraints very well.
Constraints between 'parts' or groups of features would also be constraints-solved using a 3d constraints manager or kinematics solver. Needless to say, all the features are compiled, and tested/error-trapped against the comparatively restricted gamut of possibilities; i.e. other vendor provided features.
Inventor also has iLogic. Not sure if this was used. iLogic is interesting as it functions like an 'active spreadsheet' where the user can script 'rules, checks and reactions' that have full access to all of the parameters that drive the model's features. It uses VB, so I suppose you could get 'generative' with it via .NET. Probably not as comfortable as Catia's Knowledge Advisor workbench... still.
Would the best of both worlds be something like Inventor (for the mainstream stuff), but fully scriptable (for the esoteric stuff) in one app/thread? The user would weave between a DAG and MACD style history tree?
…
quired)
// Agenda
Parametric Design, in the history of architecture, has defined many rules for current designers and for future practitioners to follow. One of the strongest aspects that are prominent from this style is ‘geometry’. Arguably, there is nothing new about geometry and aesthetics forming the most prominent aspect of any style or era. The language of any style, in the long history of architecture, is visually defined by geometry or shape, beyond the principles that define the core of the style. In the distinguishable style of parametric architecture, geometry has played and is continuing to play an integral role. And with this fairly young style, there are many strings of myths and false notions associated.
The workshop aims to provide a detailed insight to ‘parametric design’ and embedded logics behind it through a series of design explorations using Rhinoceros & Grasshopper platforms, along with understanding of data-driven fabrication strategies. An insight to Computational Design and its subsets of Parametric Design, Algorithmic Design, Generative Design and Evolutionary Design will be provided through presentations, technical sessions & studio work, with highlighting agenda of using data into Hands-on fabrication of a parametrically generated design. A strong focus will be made on ‘geometry’ and ‘matter’.
Day 1 Topics / Agenda
Rhinoceros 3D GUI and basic use
Installing Grasshopper & plug-ins
Grasshopper GUI
Basic logic, components, parameters, inputs, numbers, simple geometry, referenced geometry, locally defined geometry, baking, etc.
Lists & Data Tree: management, manipulation, visualization, etc.
Design Experimentations with Geometry & Data
Understanding Data for Manual Fabrication
Day 2 Topics / Agenda
Design Experimentations with Geometry, Form, Matter
Data for effective numbering and strategizing during Manual Fabrication
Collaborative effort for Hands-on ‘making’ process
Analysis & Evaluation of Fabricated Geometry
Documentation
// Tutor(s): Sushant Verma (Architect / Computational Designer / Educator)
…