ONE SIZE ALMOST FITS

Back in early August, I had the privilege of speaking at USC’s annual BIM Symposium on the topic of visual programming. This post is my attempt at a sort of editorial that follows the narrative of that talk. Along the way, I’ll include a few of the videos that I shared at the presentation which hopefully demonstrate the kind of tool creation I’m talking about. Hope you enjoy.

It’s been 5 years since we officially launched our research program at the Yazdani Studio of Cannon Design. During that period we’ve come to understand that the evolution of our process reflects the larger, changing relationship architects have with their means of production. We’ve always been a profession of hackers. Every building is a one-off made up of countless elegant hacks, each bringing disparate materials and systems together into a cohesive whole.  But when it comes to the software that designers have come to rely on, most of us have been content with enthusiastic consumerism, eagerly awaiting the next releases from software developers like Autodesk, McNeel and Bentley. In late 2007 something changed. McNeel introduced a visual programming plugin called Grasshopper authored by David Rutten, and more and more architects began to hack their tools as well as their buildings.

Building Optimization Tools – The Grasshopper definition and breakdown.

About a year ago I was asked to speak at the University of Oregon’s annual H.O.P.E.S. conference and lead a workshop demonstrating the computational approach to design we promote on this blog and at the Yazdani Studio. The workshop focused on the optimization tools we have been piecing together using Grasshopper for Rhino and its many add ons. Today we’re going to share an updated version of the Gh definition used in the workshop. A video that breaks down the definition and various steps involved is also included below. The goal here is to share a general framework for creating optimization tools with Grasshopper. My hope is that the script below, along with breakdown video, might be a useful guide for anyone interested in developing their own optimizations or tailoring them to specific situations. In the example provided, the definition is used to optimize a building form to receive the minimum possible total solar radiation given only the geographical location, building area, and number of floors.

Optimization with Galapagos

It’s been several years now since the Galapagos component was included in Grasshopper for Rhino. Back in 2011 Charles Aweida wrote a blog post that included a proof of concept in which he used this tool to optimize a simple multi-sided form to receive the lowest amount of heat energy from the sun. Since then, we’ve been trying to create optimization tools at the building scale that can inform our decision making process during design. The videos below are optimizations for heat gain and views on a site in Boston, MA. We are actively looking for ways to expand this list to include a wider range of project / site specific design drivers such as daylighting, structure, and wind.

………………………………………………………………………………………

LA Courthouse Competition Responsive Facade

This past fall, the Yazdani Studio, along with Gruen Associates and builders Hensel Phelps participated in an invited competition to design a new US Courthouse in the heart of downtown Los Angeles. The site for the project is located at the intersection of Broadway and 1st, one block West of the LA times building and a few blocks east of the Walt Disney Concert Hall.

A New Way of Visualizing Solar Radiation

Last fall a custom data visualization developed by our research team was featured on the information is beautiful website as part of their information is beautiful awards. In this post we discuss why we developed the graphic and how it is used.

Incident Solar Radiation is one of the most common types of analysis performed by architects at the conceptual design stage. Results indicate where solar heat gain might be an issue. These are areas where glazing should be minimized and exterior sunshades should be considered. Unfortunately, Ecotect does not have a way of communicating all of the results of this analysis in a single concise graphic format. As part of the research effort, we have developed a grasshopper definition that generates a graphic representation of both heat intensity and panel orientation in a single frame.

Evolutionary Form Finding with Grasshopper + Galapagos

Evolutionary problem solving mimics the theory of evolution employing the same trial-and-error methods that nature uses in order to arrive at an optimized result.  When automated for specific parameters and results, this technique becomes an effective way to computationally drive controlled results within the iterative design process – allowing designers to produce optimized parameters resulting in a form, graphic or piece of data that best meets design criteria. In this post we walk you through the process of using Galapagos, an evolutionary solver for Rhino/ Grasshopper, and show an example of how this method can be tied in with analysis tools to optimize form based on energy data.

Energy Analysis Feedback Loop

I had the pleasure of exploring stadium concepts for a potential project in Saudi Arabia. The stadium typology has much to offer on the subject of skin, response and computational design with its sheer size and volume of components. One avenue explore was a loop consisting of  analysis data generated by Ecotect and a design concept formulated  in Rhino3d. Extracting data from Ecotect is quite simple. A .txt file with data in the CSV format can be exported from Ecotect through the following location: Display->Object Attribute Values->Properties->Export Data… This data is saved as a .txt file and can be directly imported into grasshopper with the ‘read file’ GH component. Although the information is accurately imported there is a break in the loop which forces one to stop, export and re-import the information. Luckily Ecotect creates a Dynamic Data Exchange server which allows running applications to speak with each other. The GecoGH plugin is a great set of tools that executes this exchange in a seamless loop where the scripted geometry/design is streamed to and from Ecotect. Below you will see some screen shots of a process utilizing this functionality.

GH mesh geometry

Building things that talk part 3 [kinetic aperture]

Part 3 has an identical flow of data to part 2, the only difference is the type of sensor and the 3-dimensional relationships it effects. In this example we use a PING))) Ultrasonic Sensor to measure the proximity of an object (in this case my hand) to the sensor.  The ultrasonic range finder works by sending out a burst of ultrasound and listening for the echo as it reflects off an object. Code written to the Arduino board sends a short pulse to trigger the detection, then listens for a pulse on the same pin using the pulseIn() function. The duration of this second pulse is equal to the time taken by the ultrasound to travel to the object and back to the sensor. Using the speed of sound, this time can be converted to distance. For more information on the code and circuit click here.

The code written by Arduino prints values in “in” and “cm”. In this example we only need one value so we will use Serial.println(cm) and comment out the other Serial.print() functions. This will send a single array of values through the serial port similar to the example in our previous post. In Rhino the aperture is built by crating a circular array of pivot points about a center axis. These pivot points rotate a series of overlapping blades controlled by a singe parameter.

The values streaming from the serial port are fed directly into the grasshopper build driving the rotation of blades. To see this process in action see the video below. Notice the values printed to the ‘right’ screen displaying the distance in centimeters.

See the video in HD here.

Building things that talk part 2 [maximum balloon]

In our previous post making things that talk part 1 the analogy is used where a group of people communicate allowing them to share and transfer information. In this post we build on the same concept with the micro controller (Carl) and the sensor (Susan). There are two changes; (Paul) from processing has left us and is replaced with (Grant) from grasshopper and the source (Sam) is still here but he is measuring wind variance vs light. In this example we use a really interesting anemometer/wind sensor from modern device. This little sensor uses a technique called “hot wire” which involves heating an element to a constant temperature and measuring the electrical power that is required to maintain the heated element at temperature as the wind changes. With wind variance the sensor produces voltage/values. These values are sent through the serial port into grasshopper via the generic serial read component from firefly. Once the values are pipped into grasshopper they alter a series of relationships that inflates a 3-dimensional balloon.

The single array of data streaming from the sensor controls 4 relationships.

• a. varying division points spaced along central axis
• b. varying circle radius about the division points
• c. mesh surface constructed from control curves
• d. z axis translation based on radius

GHX build

Final build showcases the digital inflation of a balloon translated by a wind sensor.

See this video in HD here.

Building things that talk part 1 [visualizing data]

Our previous post thoughts on response and interaction mentions the idea of embedded systems and the process of physically making things talk. Our first example uses an Arduino micro-controller , ambient light sensor the Processing programming language/development environment and a source of data which in this case is light. This communication involves 4 participants with the micro controller acting as the manager directing all parties involved. To make things simple I will make up names for each piece of technology used. We will call the micro controller (Carl) the sensor (Susan), the Processing IDE (Paul) and the light source (Sam). We will assume that each person speaks a few languages, in reality this communication takes place via programming syntax.

The dialog goes as so:

1. Carl the controller goes to Susan the sensor located at room (A0), he asks Susan to get data from Sam the source.
2. Once Susan the sensor has the requested data she sends it back to Carol the controller.
3. Carl the controller then takes the data and sends it to Paul from Processing.
4. Paul is very artistic and draws the data on the screen.

Carl is quite demanding looping through this sequence over and over again…

Ambient light data display via Processing and Arduino

In reality the process goes something like this:

1. Code is written to the Arduino micro controller asking for the anolog input voltage streaming from pin (A0).
2. The sensor plugged into pin (A0) captures the numeric values of light in the form of voltage ranging from 0 to 1023.
3. The Code written to the Arduino micro controller grabs those values and sends them through the serial port.
4. The Processing code catches the values from the serial port and draws vertical lines based on the values, which in turn gives us a graphic representation of light

As we build on this example take note to the fact that the general story stays the same, we swap out a few different characters, a few different roles, a few different languages but at the end of the day its still a group of ‘people’ ‘talking’ and relaying information.