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)
…
low cost fabrication techniques developed by RC6, a research laboratory based at UCL / The Bartlett School of Architecture. A part of Bartlett's BPro programme, RC6 traditionally engages in the development of design methodologies positioned at the overlap of digital and analogue computation, primarily investigating concepts which merge traditional, low-tech manufacturing processes and advanced technological concepts.Topic of this workshop - Composite Bodies - represents RC6’s ongoing research into hybridised material systems consisting of soft membrane materials and light-weight infill aggregates. In this particular case, from a material point of view, we will be looking into custom designed lycra pieces, filled with styrofoam beads and spheres and constrained with series of performative stitches. The resulting parts will be coated with latex and used to create series of interlocking components and surfaces.The workshop itself will consist of 2 stages. The first two days will be dedicated to intensive software training sessions. Students will be introduced to multiple digital platforms focusing on scripting in Processing and 3D modelling/sculpting in Maya/ZBrush. Aim is to enable students to understand algorithmic design processes and procedural modelling techniques and to help them to learn how to customize pre-made scripts and how to embed them in their individual workflows.The remaining five days will be dedicated to the fabrication of a spatial installation. Students will learn how to translate digital models into prototypical components and work alongside tutors to aggregate those into one large-scale architectural object which will be exhibited as part of SBODIO32 Exhibition for Milan Design Week 2017.Dates: March - April 2017 RC6 Program Director:DANIEL WIDRIGwith IGOR PANTICSTEFAN BASSINGSOOMEEN HAHMWorkshop Tutor:IGOR PANTICLead Designer at Zaha Hadid ArchitectsVisiting Lecturer at UCL Bartlett School of ArchitectureTeaching Assistants:Thomas Bagnoli, Evgenia Makroglou, Kalliopi Mouzaki, Darshan Singhaniaucl bartlett rc6 graduate studentsSoftwares: Maya, Rhino, Grasshopper, Processing*Previous knowledge of the softwares is not compulsory. Fabrication Tools: Lycra, Styrofoam beads, Latex, Sewing machines…
Added by Amrvitaloni at 9:38am on February 25, 2017
to do once I figured out how you use only a small portion of each of my generated curves to make the 360 degree Loft surface. I had a huge AHA! moment when I realized the complete Loft surface really only needs a small portion of the generated curves rotated around to form a closed (except for top & bottom) surface. That is a major new insight for me and I appreciate you pointing it out.
I also tweaked the Twist angle parameter a bit so the resulting positive and negative Twist surfaces, when combined, yielded a result that was closer to my original shape. This is when I discovered something very interesting.
When I baked/exported the result using just one of the 2 twisted surfaces I got an STL file that had no errors, that 3D Builder was able to simplify from a 37 MB file to a 3 MB file, and that sliced A-OK. But, when I combined the left and right twisted surfaces, I was back with my same set of problems: the exported STL file had many errors, could not be fixed, and did not slice properly.
I went back to my original layout that uses the complete set of generated curves to create the Loft surface and found I got exactly the same results - using only one twisted surface worked fine, but nothing worked when the left and right twisted surfaces were combined. By nothing I mean I tried all the standard methods (GH Join and Sunion, Rhino Solid/Union, Join, etc.) What I think this means is that the Loft surface behaves the same, and apparently is the same, regardless if it is generated by rotating strips or by using complete closed curves.
Furthermore, I am guessing the problems with the combined/exported STL file made from both left and right twisted surfaces has to do with overlapping/coincident parts of each one - like the top & bottom planar surfaces and some of the wiggly parts.
If I am correct about this then it suggests to me that there is some sort of glitch in Rhino's STL Export function. This is surprising to me since I though an STL file only paid attention to the external shape of thngs,and did not know or care about any inside stuff. Of course this is all conjecture on my part, but at least for now seems it will be impossible for me to actually print the double-twisted geometry.…
Added by Birk Binnard at 3:52pm on September 23, 2016
ake a network of lines (i.e. a graph) and make a Plankton Mesh, from which you can use Cytoskeleton to make a solid mesh (and then smooth it with Weaverbird).
Works with ngons (polygons with 3 or more sides). Other examples I found only worked with tris and quads.
Works on open or closed surfaces
While these examples start with a surface, you could start with a network of lines and make a patch surface
This is meant for 2D networks/surfaces. I haven't attempted filling a 3D volume. My guess is this wouldn't work as it would require a non-manifold mesh that Plankton wouldn't handle.
Note similar results could be achieved with the following:
TSplines
MeshDual (dual of a tri mesh, not as much freedom/control)
Working backwards, here is the GhPython script from Will Pearson that builds a Plankton Mesh from vertices and faces. The vertices are a list of 3D coordinates, the faces are a tree a lists, with each list containing the indices of vertices that form a closed loop. From Will, "Plankton only handles manifold meshes, i.e. meshes which have a front and a back. This orientation is determined by the "right-hand rule" i.e. if the vertices of a face are ordered counter-clockwise then the face normal will be out of the page/screen."
# V: list of Point3d # F: tree of int
import Grasshopper appdata = Grasshopper.Folders.DefaultAssemblyFolder
import clr clr.AddReferenceToFileAndPath(appdata + "Plankton.dll")
import Plankton
pmesh = Plankton.PlanktonMesh()
for pt in V: pmesh.Vertices.Add(pt.X, pt.Y, pt.Z)
for face in F.Branches: face = list(face)[:-1] pmesh.Faces.AddFace(face)
These vertices and faces are precisely the output from Starling. Starling takes in a list of Polylines which form the (properly oriented) face loops.
The polyline face loops can be generated...
Directly from Panels on a surface using LunchBox
Using any network of lines/curves on a surface (curves will need to be converted to polylines before Starling)
The latter was achieved using the Surface Split command, then converting the face edges (converted to curves) into polyline loops to represent faces.
…
o use these extensions in order to integrate numerous tools for analysis and simulation in the architectural process.
This course aims to develop a link between the virtual and the real context model through structural or environmental simulations, using other software or plug-ins dedicated. Through this link the virtual model receives physical properties that can further modify and adapt the initial model. This creates feedback loops that can optimize the design to provide an object responsive to environmental conditions.
Curriculum
Mesh subdivision with Weaverbird, continuous surfaces without NURBS
Genetic optimization with Galapagos, optimal search
Physical environment feedback with Diva and Geco, solar and day lighting analysis
Adding physical properties with Kangaroo Physics, interactive form-finding
Linking the parametric model with structural analysis using Karamba, structural performance simulation
Extracting data with Firefly and Kinect, 3D scanning and human movement tracking
Exchange of information between Grasshopper and other applications with Ghowl links to internet feeds or Excel files.
Schedule:
Module 04 / Grasshopper intermediate & advanced (24 h)
11 Oct – 26 Oct 2013
Fri:
Sat:
16-20
10-14
Language: Romanian
Organized by:
OAR Bucureşti – Romanian Order of Architects, Bucharest Branch
Trainers:
Ionuț Anton, idz arhitectura (ART-Authorised Rhino Trainer)
Daniela Tănase, idz arhitectura (ART-Authorised Rhino Trainer)
https://www.facebook.com/cursurigrasshopperrhinoceros
http://www.oar-bucuresti.ro/anunturi/2013/02/27/d/…
Added by Dana Tanase at 2:49am on September 5, 2013
2013 | Sábados 19 y 26 de octubre. 15 Hrs.
Horario: 9:00 - 18:00 Hrs.
Instructores por BIO|Architecture Studio: A design & building laboratory.
Palabras clave:
Diseño Computacional, Scripting, Rhinoceros 5.0 + Grasshopper, Parametrización, Análisis, Fabricación Digital, 3D print.
Para mayor información:
MArch. Kathrin Schröter. E-mail: kschroter@itesm.mx
Dirección de Arquitectura. Oficinas de Aulas 1, segundo piso.
Carretera Lago de Guadalupe Km.3.5 Col. Margarita Maza de Juarez, Atizapan de Zaragoza. | 5864 55 55 Ext.5750.…
eated testing shows that it's just doing a Rhino Boolean Union internally, first, and thus fails whenever a normal Boolean fails, which is all the time if you have dozens or hundreds of bodies:
It's exactly the deal killer of failed Booleans that is driving my quest here, since using them ruined my original MeshMachine tension membrane relaxed modeling system, every time a casual user of it point edited a surface or a single sphere object until two faces nearly coincided and then the Boolean failed and it was hard to know where. This is totally robust, I believe.
$13K Materialise Magics has real Shrink Wrap which will wrap things nicely, and tightly, even perforated solids so it retains the holes, while closing off small gaps you can control the sensitivity to.
Microsoft has a rolling ball algorithm that does exactly what it sounds like it does, along the outside surface.
Once you have a fine mesh from my system, one offset by a fixed distance from each point, you could just offset the mesh inwards by that distance (after isolating it from the inner artifacts you can see on the left in green) and thus have a real hull, the need to smooth it to remove marching cube anti-aliasing affording some transition smoothing:
You could ramp up the number of points vastly, and set the radius of influence way down, to get a tighter initial result that would sharpen up even the transition, but this is pretty fast the way it is (1 second).…
merely automates finding clear intersections between pairs of objects and then splits the objects along those intersection *curves*, deletes the trims, then joins the remains, and cycles on. But within the confusing Rhino Settings tolerance value, wherever surfaces actually just sort of come closely together, there *is* *no* clear intersection curve. So it bugs out and stops working EVERY time you try more than a dozen or two spheres.
Some software can do this by switching to volumetric pixels (voxels). $9K-$30K Geomagic Freeform is an example of this. It also fails sometimes, often due to memory issues, as you can imagine since it needs to fill all inner space of each sphere definition with 3D pixels.
Materialize Magics for $16K can often handle such Booleans well. It will take a seeming lifetime to figure out such often pirate software kludges though.
One thing you can try though is to simply drape a mesh or NURBS plane onto the top of your spheres.
There's a well known *reason* your Booleans are failing. Nobody here has yet even hinted at it:
The main reason is that Rhino/Grasshopper developers don't care about the human element. The math exists to make this work very fast, every time. It just has to join things *right*, incorporating human knowledge of kissing surfaces, instead of acting stupidly, like some pocket calculator. But that would involve hacks that make 99% of complex Booleans work instead of 10%, and we can't have that since it will be SLOWER for the other 1% that just happen to have no nearly kissing or really kissing surfaces.
You could also use the new Cocoon plugin to do a surface *around* your structures, with a given radius of extension beyond the spheres, then offset that surface back the same radius. That is 100% robust, but won't offer quite as sharp of intersections, more rounded, like most everybody wants anyway.
You can *test* Boolean failures, by running a Grasshopper intersection command, to see the intersection curves, and zoom in to see how badly many of them are, all knotted, or twisted, or even with gaps, often with gaps.
It's a math problem nobody at McNeel wants to solve, sorry.
Just write a check for $25K and spend six months taking notes, like I did, and you can merge your simple spheres finally.…
Added by Nik Willmore at 6:33pm on October 20, 2015
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…