Miiiiiiillllliiiiiippppeeeeedddddeeee
While I wasn't looking, sawapan have released a suite of Grasshopper components they are calling "Millipede." This is a diverse suite including finite element analysis, topology optimization, fourier transforms, eigenvalue partitioning, and much much more! I got to play with the alpha or beta versions of many of these components in Panagiotis' classes at the GSD and they are powerful stuff.
http://www.sawapan.eu/
The Nurbs-Fabrication Complex
… use computation, but stop fucking talking about it. Your project isn’t any better because you told me it was scripted from the secret code found in the lost book of the Bible handed to you by your Merovingian great grandmother. Nor because you spent a semester producing the most intricate parametric network ever seen by man, & still ended up with three crumpled potatoes in glossy grey.
(Mark Gage, "Project Mayhem", Fulcrum, Issue 18, June 2011. Daniel Davis' "Quote of the Year 2011")
For many, the idea of computation in architecture is synonymous with the use of form that is complex in very specific ways. These forms exist in a sweet spot that combines easy description via a parametric method (B-Splines, subdivision, Voronoi methods) with a dynamic graphic perspective image. In some, but not all, of these projects, additional limitations to the form may exist to ensure that the floors can be walked on, and that the structure does not collapse under its own weight. To highlight the formal dynamism, the chosen rendering method usually involves either a monolithic glossy grey appearance that has virtually no analogue in physical reality, or a similarly impossible ghostly transparency.
A great deal of mental energy is spent figuring out the proper way to derive these shapes, but even more is spent developing ways to construct them. Virtually every advanced fabrication project in academic architectural circles is devoted to novel methods to construct forms that are curved in two directions, whether through the digital generation of formwork, novel methods of panelization, curved origami, giant robot hot-wire cutters, or (if you are appropriately old-school) revisiting traditional thin-shell construction methods. These methods typically involve one or more of the following techniques - sophisticated automation, full size templates, or colossal quantities of volunteer hand laborers. Usually it is some combination of all three. More frequently, mock-up is built at a smaller scale, ideally a scale that allows for the actual connection of the members and panels to be made using methods that cannot be used in full scale construction - glue, zip ties, or slot-and-tab joinery. Usually it is a combination of all three.
Now, I have no problem with either of the types of projects mentioned above. Even after overexposure, I find a well-done architecture of complex surfaces to be engaging and thrilling, and display an admirable geometric virtuosity. As a postmodern apologist, I am thrilled at the graphic and media possibilities that some of these projects show. Likewise, assemblage projects are not only cool looking (particularly if they light up) but are an invaluable way to explore the intersection of idea geometry with physical reality.
My concern is that the two kinds of projects listed above - finding ways to design with complex surfaces, and finding ways to build the same - form a feedback loop that absorbs all of the thought and consideration of an academic group. Designing these forms suggests that time be spent figuring out how to construct them. Discovering novel ways to construct complex forms gives further credence to the idea that these forms are the sole future of design. This has become a tautology that we have learned to live with. It is implicitly assumed that you have two choices in engaging design culture - to join this computational circle, or to ignore or reject it.
What this obscures is the infinite other ways that technology could transform or inform architectural design and practice. Communication, interface, interaction, clarification, comparison -- non-formal possibilities are everywhere you look. And there is an incredible variety of form available that does not require the use of continuous curves or facets, that are equally amenable to computational description or interrogation. And many of these other possibilities have a much better chance of reaching widespread adoption in the physical world than the status quo, which frequently is difficult to inhabit and more difficult to construct.
If you really pay attention to how projects are currently designed, tease out the grasshopper definition or actually parse the script, you will often find some numbers at the root. These constants and variables are tweaked to get the desired result, frequently without fully understanding how they relate to the generated form (which, in review, will be referred to as "emergent". A quick note: the word "emergent," when discussing digital morphogenesis, should imply the use some kind of complex feedback system. Not understanding your grasshopper definition does not make your project "emergent").
What if, instead of using random inputs to achieve a desired outcome, we instead used meaningful, rigorously collected, verified, and curated data to generate meaningful and truly emergent designs? Computational methods are data hungry, and we currently are very short on architects interested in the front end of computational techniques. Or what if we used computation to change the design environment rather than the design itself? Where are the architects interested in the tools themselves? One teacher I greatly respect describes the architect's use of technology as being similar to bricolage. We grab whatever is near and figure out the way it fits into a scheme we have already conceived. What if, instead, we examined and altered this technology to reflect the techniques and abilities we would like to see?
Which leads us back to the quote above. The issue with what I would like to see, with treating computation as a context and not as a style, is that the designer is then forced to find meaning for the design that does not reside in the methodology itself. This is incredibly important if architecture is going to engage the outside world, and incredibly difficult if you are not accustomed to thinking about meaning in this way.
This is the point in the op-ed where the author usually acts as a doomsday prophet. I might say something like "the architectural community now has the choice between increasing solipsism and irrelevancy, or a role as an important partner in the creation of the future world." I'm going to scale that down a bit. Architecture does not exist in a vacuum, nor does it's relationship to technology or purpose in the world. The danger is not in architectural practice or design becoming irrelevant; rather, it is individual members of our community that have to make a choice: are you interested in the future, or just its image?
Centrality
Centrality is a concept that is, well, central to a lot of internet companies (ahem, Google), but hasn't really made the prime time in the architectural community. Urban planners and architects have started to come up with various algorithms to measure this property, whether it's to determine a "walk score" or "space syntax". And then there was the mid century attempt to scientifically optimize walking distance in architecture, which I have written about before. As Sean Keller has pointed out in his various articles and essays about the early days of computation in architecture, eventually the results of this research into walking distance were rendered obsolete by new technologies such as intercoms and email. This is not to say that location is no longer important, however.
While the methods above might seem fairly complex, there is a very useful and easy to calculate type of centrality that requires nothing more than a familiarity with Google Maps. If you have a list of street addresses and want to figure out which is the most central to a certain domain, a simple metric called "closeness centrality" is all that is required. To figure out this value, you measure the sum total of the distances from a location to a list of target distances (for relative internal centrality, this can be to the other addresses in the initial list). The location with the smallest total is the closest and therefore the most central. I have written a bit of JavaScript that does all of the heavy lifting for you: prepares the addresses, gets the values, calculates the totals and serves up some charts and maps to illustrate the results.
This version uses travel time instead of distance, as proximity to freeways can be a major factor. As I was initially using it to find relative centrality within a cities' boundaries, the list of target addresses were just the centers of each zip code, which also controls the results somewhat for relative density of population. I apologize for the messy code but this was my first attempt at anything asynchronous.
Here are the file locations:
And here are some previous versions, that use relative centrality within a list of locations, using distance as well as travel time:
Distance HTML
Distance JavaScript
Travel time HTML
Travel time JavaScript
Some disclaimers: first of all, the code is not well organized, commented, or constructed, sorry. It's also a deprecated version of the Google Maps API (v2) as this version had some methods that were useful. If you are going to use this a lot or write your own implementation, please PLEASE get your own Gmaps API key. And I would be remiss if I didn't mention that according to Google's terms of service you need to display a map whenever you query the API.
This tool has a few obvious uses. One is what was mentioned above-- ranking addresses by their relative centrality to one another. It's also good, however, for comparing entire groups of addresses to one another-- simply compare the grand totals. You can also use it to figure out a good "dividing line" when making zones of control for different areas (say, delivery areas for a chain of restaurants). Have fun!
Treemapping Redux
Oldie but (apparently) a goodie today. While I've linked to some isolated HTML for this project, I've never actually blogged about my data visualization final project from last year. This project looked at using treemapping, a fairly common technique for comparing relative sizes in a hierarchical organization, as a way to visualize dynamically the program requirements for an architectural project. I'm reposting this now for two reasons:
1. I am actually using this tool at work for program analysis at the beginning of projects, and it's turning out to have some utility, and
2. A co-worker pointed out that a NASA spinoff is actually selling a space planning consultancy with a basis in treemapping. The presentation is undeniably impressive but also to me a bit myopic - so much time is spent talking about optimization methods without any discussion of whether the set goals are even appropriate. It seems a bit silly that you would discuss reorganizing an entire campus without the possibility of changing any interior walls, for example. While the NASA tool does present a fully developed application for space planning, it ends up presenting as many new issues as it solves, issues that I didn't even consider below as I hadn't thought about this method used to reallocate existing space. It seems like this team needs to have a discussion with some CAFM people to figure out the true parameters of controlling space.
In any case, my research is presented below.
If you want to play with a demo, the applet is (as always) on my dropbox.
Introduction:
This project started as an attempt to use graph visualization to show the implicit room organizations of existing building plans (fig.1). Ultimately, the project shifted to treemapping architectural program documents, for reasons that will be explained below. In architectural language, the word “program” is used to describe the intended uses and requirements of a space. Thus a program document generally includes a list of required spaces and space groups, as well as details such as area, capacity, adjacency, and other general requirements. Preset architectural program documents are common for complex building types, particularly in civic projects or programs that are highly functional. For this project I have chosen to focus on a typical middle school program document, as the information is publicly available and relatively complex.
When architects are given this document, a common first step is to draw out all of the spaces required to gain an understanding of the relative sizes of not only the rooms, but the program areas and organization. This is often done manually, and often ends up such a large document that it is difficult to comprehend it in it's totality, or remove a lot of the detail.(fig.2) The goal of this visualization was to come up a way of automating this process, to allow someone who is unacquainted with the document to gain a quick but rich understanding of the size and organization of the spaces. I also added functionality to allow the user to make notes embedded in the document, for incorporation into the project later.
Given that a plan drawing already visualizes all of the information that would be in the graph, it seemed redundant to work on my original proposal. Since program documents can be confusing and are inherently non-visual, working from the “other end” with the raw program document seemed to be more useful.
 |
| Project Proposal |
 |
| Seattle Library Program Diagram |
Related Work / History
Topological models of architecture have a relatively long history – one early example is work by Philip Steadman at Cambridge University in 1973 on “Graph-Theoric Representation of Architectural Arrangement.”(fig.3). This work attempted to make a “library” of all possible topological arrangements in a plan diagram for a certain number of rooms. Also of note in the same program in 1972 was the work of Philip Tabor and Tom Willoughby on walk distance optimization, using a combination of graph theory and a traveling salesman algorithm. This research ultimately concluded that quantifiably optimized architectural solutions were not possible.
With the resurgence of computational design in the last decade, there have been more attempts to visualize room organization (although most designers work on issues in geometry rather than topology). The most notable attempt recently was by the Aedas R&D team (fig.4) which used a three-dimensional graph layout to show the relationships between program areas.
 |
| Philip Steadman Adjacency Graph |
 |
| AEDAS R&D Adjacency Graph Program |
 |
| Tabor/Willoughby Topology Diagram |
Approach
Ultimately, research into precedent and methods convinced me to shift my approach from graph visualization to treemapping. There are many examples of program adjacency diagrams in architecture, and they have a lot of use. However, generally they appear later in the design process, as a method of design itself. Program documents have much more information about the hierarchical grouping of spaces than actual adjacency; indeed, room numbering is treelike in nature, using dot notation (e.g. “Room 1.23.4”). Where adjacency is required and noted, it can be of different types – a circulatory connection, a visual connection, or simply a requirement to be physically near. This complicates the process of visualizing these requirements. Circulation space is also not typically indicated in these projects, and thus is difficult to visualize properly – in the Aedas example above, there are large “hallway” bubbles that would not have been in any program document.
Finally, I wanted to choose a visualization method that was the least suggestive spatially, to keep from the diagram being to suggestive of the final design. Architects have a history of “building the diagram” with mixed results. The best projects often purposefully mix or subvert adjacency requirements to add a sense of community or give a more engaging spatial layout. Thus, I wanted to make it clear from the outset that this tool was not a “building designer” but instead a simple method for exploring program requirements.
Data
The data chosen for this project was the middle school space requirements for the Clark County School District in tNevada. This particular document was chosen as it was easily accessible on the internet, and contained enough detail and depth to make the visualization interesting. It was also in a tabular format, within a pdf document, that I could begin working on immediately. The information I chose to work with was the space number, name, capacity, area, and quantity. The data was converted to a tab-separated value (.tsv) file to work with Processing, and also required some cleaning, primarily to change the numbering to make it more logically treelike (a space labeled 1.21.1 was changed to 1.2.1.1). This was done simply using regular expressions in a text editor (Notepad++) the .tsv file. Some errors, like misnumbered or missing parent spaces, were also corrected.
Implementation
This project was built in the Processing language, starting with the treemapping example provided by Ben Fry. This provided both the treemapping algorithm, an open source java library provided by Martin Wattenberg and HCIL, as well as some functions to help animate transitions. I also used the "Table.pde" .tsv reader and writer file that was provided for an earlier CS171 project. All of the code except for the libraries above underwent significant modification, both to the visual appearance of the map as well as the interface and functionality. The actual layout algorithm was changed to a "Squarified" layout that reduced the number of thin rectangles in the map. A detail window was also added to the right hand of the map to show the layout in outline format as well as some detail for the space on the mouse over. The labeling method was made more sophisticated, and a visualization of occupant capacity was added. Finally, the "controlP5" Processing library was used to add some notation functionality to allow the user to add notes to the document.
Results
The peer evaluations received confirmed some of my previous decisions – there was some concern that the visualization of existing plans simply duplicated and simplified the information rather than showing something new.
The system as designed works with the provided “data.tsv” file, although there is some file-selection functionality that has been commented out, as it did not work on the applet version. The file is intially displayed at the first level of detail, with the mouseover displaying some additional information to the right. Immediate child groups of the level you are at are shown with larger labels at the bottom of the space.
Clicking within the spaces opens them to reveal the child groups and rooms within. Each level down the group or room gets lighter, suggesting its depth in the tree. Area and capacity (for rooms) is also shown if it fits – capacity by drawing a darker box within the room itself. Finally, small white tags appear at the upper right hand corner of a group or room if there is a note added. The outline view at the right hand size shows a list of the groups and rooms that are visible. The mouseouver shows information about the lowest level space or room that is visible.
After the entire depth of a space has been revealed (down to room level), an additional click will zoom the treemap onto the next level down in that area. Repeated clicking will allow zooming to the lowest group level in the map. Right clicking zooms back out to parent groups, and when at the top level will “close” the groups again, hiding child groups and rooms.
Finally, hitting the enter key while hovering over a space will open a text box that will allow a user to add a note to that space. Adding a note puts a tag on the space, and a mouseover will show the note as well. Currently the model does not save the notes back to the .tsv file, however, due the the restrictions of the web applet format (the functionality exists but has been commented out).
Discussion
The strengths of this approach are the ease of interaction, and the immediacy of understanding – it gives a very quick overview of the area and ownership hierarchy in a program document. The animation of the zooming invites the user to drill down and look at certain program areas with more detail.
This approach is, however, can be seen as reductionist, as it eliminates adjacency (beyond ownership) from the diagram. The map is not user-editable, so awkward layouts cannot be changed or adjacency ideas explored. After doing this project I understand well the advantages and disadvantages of treemapping, and have been able to explore in detail the goals and implications of diagramming and visualizing architectural data early in the design process.
Future implementation goals would involve a more rich set of interactions with the data set, such as allowing modification of the size or capacity of spaces. The idea situation would be a hybrid treemap / graph layout which would allow the user to move between visualization and explore multiple dimensions of the implicit data, as well as adding linkages or spaces on the fly.
References
Ben Fry's treemapping resource : http://www.benfry.com/writing/treemap/
Aedas R&D: http://aedasresearch.com/
History of graph theory in early computational design:
Keller, S. (2006) Fenland tech: architectural science in postwar Cambridge. Grey Room, 23:40-65.
Keller, S. (2005) Architectural Theory at the University of Cambridge, 1960-75. PhD thesis, Harvard University.
Infant insomnia visualization
You may have noticed the three- plus month hiatus on posts here at work. Infants, particularly those that think sleeping is optional, can be a bit of a time suck. For those of you wondering how I have been spending my "free time" (ha!), my wife has prepared this lovely image:
That's right, she has Gantt charted Edie's sleep habits. This is one of the many reasons I married my wife. Remember, all of those blank spaces at night represent lots of patting, rocking, and shushing (don't worry, the big gaps at night are mostly just missing data. Mostly.)
And yes, this post was written on my phone while rocking and shushing my daughter back to sleep.
Patterns and Design
In the comments discussion on this post by Daniel Davis, the concept of design patterns was randomly (inevitably?) brought up, as a strategy in programming and UX design that might be used in architecture to deal with increasing complexity in a design project.
To quote someone we will spend the rest of the article discussing,
"[a design] pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."
The use of patterns not only standardizes nomanclature for common problems or conditions, but provides an easy reference to proven solutions to those problems and conditions. There has been an increasing interest in patterns in computational design circles, and with the recent release of "Elements of Parametric Design" by Woodbury et al, ideas have begun to converge, and various attempts at CD pattern libraries and their corresponding implementations have been started using a wide variety of tools.
This new interest architectural design patterns is actually the end of a forty year full circle. Patterns as a concept were invented by the architect Christopher Alexander, who was drawn to the architecture department at Cambridge University after initially planning to study computer science, and ended up being part of arguably the first computational design program in history. This combined passion for both data structures and the built environment led him to describing design as a language of connected patterns, a non-computational relative of his work on shape grammars and parametric design while at CU. Alexander invented a standard structure for the description of a pattern, beginning with the description of a problem, its enumeration, and finally a "therefore" statement suggesting a solution or desired condition. These patterns could then be linked using many different methods to create a non-formal, abstract description of a comprehensive design solution.
When my uncle (an accomplished architect in Los Angeles) found out I was going to architecture school, he immediately sent me copies of Christopher Alexander's books A Pattern Language and The Timeless Way of Building. These books, written in the late seventies, are more or less a complete expression of the idea of architectural patterns, and to a young person looking for a book that layed out the "what" "why" and "how" of architecture, were revelatory.
My first year of school, in a history and theory class, I learned that not all ideas are equally welcome. I brought those books up in discussion, and the professor didn't even bother to respond with more than a "don't waste my time" look and a quick change of topic. I put the books away and didn't revisit the concept for years. What happened in the decades between this book being published, by a well respected architectural theoretician through a major academic publisher (Oxford) and my unwelcome invocation in History and Theory 101? Well, a lot.
One clue can be found in this debate at Harvard between Alexander and Peter Eisenmann, on the eve of postmodernism in 1982. If I had my way this would be immediate, mandatory reading for every student of architecture, as somehow it's thirty years later and we still have not gotten past many of the precepts of this argument. Eisenmann was a contemporary of Alexander's at CU in the sixties, and likewise interested in computation, but this debate shows two very different opinions about the value, meaning and purpose of architecture. Alexander is making a humanist argument for an anthropological basis for building- an idea that there is a deep, human basis for architecture that can be traced, derived, and codified by examining not only buildings but ourselves and our world. Eisenmann, ever the deconstructionist, counters with an architecture that is a formal language unto itself, cut free of any dependence to history or humanity, that can be examined, critiqued, and designed purely in the abstract, clear of the confinements of an imposed humanistic imperative.
What is surprising in hindsight is that, in the transcript, it seems like the crowd was more inclined to agree with Alexander at the conclusion of this debate. However, anyone remotely familiar with the the last thirty years of architectural theory mist realize that the view of architecture expressed by Eisenmann was the one that ultimately ended up being discussed, accepted, and ultimately enshrined in the subsequent decades, to the point where my casual reference to A Pattern Language twenty years later was treated like flatulence in a cathedral.
There are a lot of reasons that a young student of architecture in 1982 (or now) might be more excited by deconstruction than patterns. Alexander's implementation of the concept is based on a historical determinism that, particularly to someone young and bold, might seem stodgy and limiting. The language of the patterns themsleves, with a lecturing tone and repeated "therefores" is almost a perfect foil for a rebellious youth, and would have a great deal of trouble competing with the (at the time) far edgier world of French philosophy. The book even looks like it was published in the 1940's, presumably because that is the timeless way of printing.
But the main reason we aren't all using this book as a bible is the content itself. Most of the patterns in the book are plainly useful, in fact aimed directly at the user - the back cover of the book proclaims a "new traditional post-industrial architecture, created by the people." But the utilitarian quality of many of these patterns - "Built In Seats," "Outdoor Rooms," "Row Houses," are somewhat of a letdown after the architect-as-industrial-sorcerer paradigm popular in high modernism. A Pattern Language laid architecture out as a rational collection of proven concepts, altered to suit user and context but sharing in ideas as old as humanity itself. Many of the patterns presented in his book are less like the patterns seen in programming, and are more like rules of thumb. Anybody passionate about their profession will bristle at the idea that what they do can be broken down into a simple set of guidelines, and this reaction is based largely on the truth that the whole is immensely more complicated than the sum of the parts. For all of these reasons, A Pattern Language seems doomed to a status as one of the many cul-de-sacs of architectural theory.
This, however, is not the end of our story. As I suggested above, Alexander's concepts have had resonance in other fields, such as programming and interface design. The idea of patterns was an excellent way to organize and understand object oriented programming, a parallel development that is now part of the underlying architecture of most commercial software. Software patterns are noticably more abstract than architectural patterns-- a particular example, like "Reactor" is more of a general concept that can be applied in multiple ways, scales, and situations. This makes software design patterns ultimately less suggestive, and easier to adapt to a variety of practices.
In the last few years patterns have returned from their roundabout journey back into architecture, this time as an organizational practice for computational design. As such, the patterns themselves are very different, having less to do with the physical form of the architecture itself than design methods used in the process of scripting. These new patterns have very little precedent in architectural practice, as they are not tools (like a t square or the offset command) nor heuristics (like a 30' column grid or proscribed parking ratios) nor stylistic imperatives (like the classical orders or digital neobaroque NURBS). They are, instead, meta-organizational principles, that are at least one step removed from the design of the form itself, such as the idea of a "goal seeker," or recursion, or a placeholder. In short, these are components of a digital workflow, an outline for how a computational practitioner might work efficiently and flexibly, keeping the organizational BS to a minimum. The use of these patterns also presupposes an algorithmic, computational approach to a design problem, which begs the question - are there non-computational design patterns that fit this meta-organizational mold? Such a pattern would not shape the form of the design, but rather the approach. For instance, "pattern-language based collaborative design workshops" would be one such pattern that might make Mr. Alexander happy.
There is one other way to look at the future of patterns in architecture, and that is to look at the way we are already working. The practice of architecture is currently making a laborious transition from drafting (CAD) to parametric modeling (BIM). Such a transition, at the most obvious, lay level, involves a change of language and approach, from working with lines and curves to working with digital objects - walls, roofs, etc. As anyone familiar with one of these parametric environments can tell you, designing completely within a BIM environment can become a process of learning how to work with, against, or around the interface and objects you are given to reach a particular design goal. Frequently one is driven to workarounds that hack the basic intent of the out of the box parametric components. As such, working in such an environment becomes a tripartate process- first you determine the design goal, then you come up with a strategy for modeling that goal, and then you implement. That second step, which did not exist in the world of CAD, is where the kind of patterns seen above live. Given the nature of this workflow, it seems to me that an obvious step in the evolution of BIM is to separate the category of an object from its organization, so that your primitives become complex patterns with known abilities and limitations. We are already working with patterns on a daily basis, but instead of being developed for utility they are the accidental inheritance of a digital environment designed to imitate a basic understanding of building tectonics.
If I've made anything clear above -- I doubt I have -- it's that, while patterns have a long history in architecture, their current purpose is still very much up in the air. It is my opinion that patterns are a vital ally in making sense of the still-nascent form of digital practice, an organizational tool that mediates between the goals of design and the power of computation. If computational design is going to be a ubiquitous practice patterns are going to be a necessary part of it. To put it simply, watch this space.
What Makes Design Computational
A recent post at the archinect forum has inspired my inner Ann Landers, and so I will slip on my curly Advisor Wig...
User "jojeg07" asks,
i am confused about the difference between digital and computational design. i had thought they were synonymous. my way of thinking of them now is that UCLA would be "digital" and MIT would be "computational". is that correct? what exactly makes them different? what is considered computational and what exactly is considered digital design?
This is a good question. I spent the last year doing what was essentially a survey of the past and current state of computational practice, and it is amazing how little consensus there is on terminology and titles. While all of the terms used -- digital, computational, parametric, algorithmic -- have specific (and easily defined) meanings and associations, the hybrid, messy nature of a design practice often leads to a confusion or misapplication of labels.
The simple answer would be that a "computational designer" uses methods directly associated with programming and computation -- algorithms, mathematics, data structures-- as a central part of their design process, where as a "digital designer" has a more normative design methodology, using tools that just happen to be on a computer. The simplicity quickly breaks down, however, when you try to apply these criteria to actual practice. For instance, BIM programs like Revit have a computationally-based tree-like structure, with acyclical parent-child relationships (what has been called "parametrics"). However, most of these programs use a graphic interface that requires no previous knowledge of programming or computer science. Grasshopper is an even more direct example of this strategy, as it is essentially a perfect graphical representation of a directed graph structure in a computer program, similar to Scratch.
Do programs that use sophisticated computational methods inside of a friendly, graphical user interface belong in the canon of computational design? Well, given my outsider status as a programmer dilettante, I would say absolutely yes. Even if the user isn't wholly aware of computational strategies being utilized, the approach is still taking into account algorithmic and parametric methods. Throwing these users out would be like programmers completely dismissing people who code in Python or Processing -- excluding higher level methods than your own leads to a one-upsmanship that eventually excludes everyone (as the xkcd cartoon below parodies perfectly).
In the end, as design software becomes more sophisticated, and digital design processes start to resemble data visualization more than drafting, digital design will become (at least partially) inherently computational. I argued in my thesis that computation in design has a future as a context, not as a style. The flip side of that will be that in order for computational design to have lasting impact, we all must become computational designers. And this isn't going to happen by getting every graduating architect to understand search algorithms and integration methods. It's going to happen by people bridging the gap and making software that harnesses powerful computational methods to the inherent spatial and visual abilities of design thinkers. These new computational designers might not know if their design problem is NP-complete or not, but they will understand how to use machine methods in design the same way we know how to catch a ball or read a face - as an inseparable, inherent part of their working knowledge.
Thesis Presentation : Pt. 3: Stuff I Made, Next Steps
Given the rather diffuse nature of the previous presentation, I chose to do three small projects to explore and illustrate applications of data visualization and game interfaces in design environments. The first project was a fairly dry implementation of a common data visualization method -- treemapping -- to a common source of architectural data -- program documentation:
I blogged about this project previously so I won't go into too much detail. The project did help to explore the tension between having a tool that does not unnecessarily suggest formal solutions, and having a tool that is formal/spatial enough to be used in a design methodology. It was also a good way to come to terms with the nature of program diagrams, and the various competing concerns that exist in the initial program explorations - assumptions about the most important relationships within the program have enormous impact upon the underlying structure of a design project.
The next project presented has also been presented previously on this blog:
Due to its popularity in the last year, I felt I had to do at least a simple exploration of game-like interfaces using spring algorithms. The project brought with it some useful insights. The first and most simple is that interface strategies have associations - the side-scrolling 2d version of the applet was regarded by users as a toy while a 3d isometric version was treated as a serious tool, regardless of the fact that they had identical interfaces and functionality. The development of the applets also provided valuable experience in difficulty and payoff involved with live, additive interfaces. Both of these characteristics I feel are vital to promoting creative exploration, but require both strict attention to the runtime costs and also the development of a natural and quick interface, with no lengthy searches for commands or tools. Finally, research into developing a web-based multiuser version of the tool has convinced me (as it has some other folks) that WebGL, WebSockets, and the Canvas tools in HTML5 are going to be the new power tools in creative software development. Watch that space, people.
My final (main) software project attempted to take all of the ideas above, alongside some additional computational strategies, and make a usable tool. The base algorithm I chose to work with was tensor field streamline integration. This is a technique that has been used in MRIs, structural analysis, and wind flow simulation, but my plans for use are more similar to what has been done in computer modeling and graphics. The procedural generation of tensor fields is something that is now commonplace to remesh 3d surfaces or make painterly or sketchy effects on raster images (think photoshop filters). This method of pattern generation is simultaneously powerful, requiring a minimum of input to a maximum of effect, while remaining intuitive and predictable, even as it increases in complexity. It is also possible to maintain a real-time editing environment, which was vital. This algorithm has a myriad of possibilities in architecture, from surface discretization to street map generation, to pattern generation. I chose to make a Nolli Map generator, as it is entertaining and easily understood, and also gave me the chance to play with displacement mapping and pixel shaders. As can be seen from the image above, the project used a pipeline approach where user input is first used to generate a bidirectional tensor field. The input comes in the forms of lines and singularities, with the option to pick an extent of affect.
Further input can be provided in the form of a bitmap (also with a range of effect) which is then put into the quadrangles created by the initial tensor fields. Multiple bitmaps are combined in an additive fashion using a pixel shader if more than one is provided.
Finally, a three-dimensional view uses displacement mapping to show the spatial implications of the drawn black and white map.
The project included peer-to-peer functionality that allowed for multiple users to work simultaneously on the same map, with live updating -- this is a particularly interesting feature of environments that use implicit rules, as there is no need to "lock" individual elements to preserve relationships. There is also a notation function and the ability to export to dxf.
My takeoff from all of the above is twofold. First of all, I am convinced that we are about to see a revolution in lightweight, interactive digital design environments that incorporate rich feedback and the possibility of implicit algorithmic integration. I am likewise certain that the future of digital design will lie in the ability of designers to navigate between multiple tools and methods, which will make knowledge of the underlying mathematical and programming techniques all the more important. Architects must make good use of these new quantitative techniques, not only as a way to maintain agency and relevancy, but also because it will ground our nascent computational design culture and improve the status of the built world.
I've taken the last six weeks off to get a breather, move to the other side of the country, obtain a job, and secure a mortgage. I'm about 80% percent of the way there, and once those goals are complete I'm going to have to take a long hard look at where I want to take this research. First things first, I'm going to release some of the tensor field code -- I've got a grasshopper c# version that needs to be cleaned up and packaged for general consumption. I'll consider releasing the larger tensor fields project but honestly it's such a mess I'm afraid to do it (the important bits of code are in the appendix of my thesis document which you can find here.) After all of that is done, I'm kind of at a loss. Revit API work? Architectural data visualization? Mobile apps? It's a wide world out there. I'd better start taking some big steps.
Thesis Presentation Pt. 2: The Monolith vs The Ecosystem (Heuristics, Feedback, and Implicit Rules)
I left off the last post with a suggestion to find a way to leverage the methods of game environments to make richer, more sophisticated design environments. If one was looking for a real-world example of this dynamic in action, it would be harder to find one more perfect than FoldIt. Designed by a multidisciplinary team at the University of Washington dubbed the "UW Center for Game Science," FoldIt was created to help solve one of the most complex problems in biology- predicting the folded structure of proteins. Properly predicting the forms of amino acid chains could potentially enable not only a better understanding of cell biology, but also the design or discovery of powerful new drugs. Predicting the folded structure involves finding the "lowest energy" solution for a particular chain - the best fit structure where hydrophobic parts of the protein are hidden and hydrophilic portions exposed. Unfortunately, the biomechanics are still only partially understood, and thus algorithmic solutions are incomplete and often get stuck in local minima. Often these solution to the sticking points were obvious, even to people with little understanding of the problem. The UW team, seeing this, decided that instead of additional computing power they would harvest the enormous visual and spatial processing abilities of human games by designing a competitive game based around finding the proper folded structure of proteins. This game would act as a kind of talent search for protein folding prodigies. Within weeks of release, their site had registered hundreds of thousands of downloads, and a devoted user base. Within a year, their user teams had derived solutions that beat even the best algorithmic models. One of the best teams was headed up by a thirteen year old, who claimed that he found solutions because "they just look right." In educational parlance, this is referred to as perceptual learning -- the brain's ability to model a complex system intuitively.
This strategy was not successful merely because people are great at these tasks -- it was successful because human ability was married to an interface that managed to hit on all cylinders, enabling real solutions to real problems by people unfamiliar with the context of the problem, simply by providing clear feedback, an intuitive interface, and good tools. Some of the most important aspects of this interface have been called out above. FoldIt incorporates a wealth of visualization techniques, such as motion, glyphs, ghosting, and even auditory feedback to give a clear indication of the state of the game. Clear nonspatial feedback is given with a numerical score and a score history (with, of course, an all-important "undo" function). While many of the moves are done manually by "grabbing" protein chains, there are limited stochastic search ("wiggle") tools that allow for a player to find slightly better solutions in the neighborhood of their current position. There is also a sophisticated help and user forum interface built within the game, as well as multiple social tools such as a leader board and chat functionality, that all combine to produce a competitive but friendly community of engaged users.
The work of the Boston-based firm Utile has shows a sensitivity to interaction design and the incorporation of heuristics into design strategies in the service of seemingly everyday issues of profit, space planning, zoning, and sustainability, that warrants an extended look. “Heuristics” in this case represent both architectural rules of thumb (such as 30-foot column grids) as well as more sophisticated rules based upon related fields, such as development pro-formas or zoning codes. They have developed sophisticated internal tools to help provide rapid feedback on design decisions, often within client meetings, to help ensure that collaborative design decisions are grounded in objective reality. For developer clients, they have integrated a simple pro-forma tool within the schematic design modeling tools in Revit, that allow for an immediate comparison of the monetary value different general strategies for a specific parcel. They have found that this process, instead of being limiting, is ultimately liberating for their design process, as it provides a solid basis at the start that prevents a client from making drastic changes farther down the line, using efficiency as a justification.
Tim Love, a principal at Utile, has also experimented with using heuristics and feedback as didactic tools in a Yale design studio. At the outset of the studio students were provided with an "Urbanism Starter Kit" that comprised of BIM families of several building types, that incorporated many levels of heuristic devices, from a 30-foot structural grid to floor plate width rules to exit strategies. The students were made to use these digital "building blocks" at the earliest stage of design, with a specific ratio of square footages for each type. Immediate feedback from the BIM model was used to ensure that rules were being followed and enabled live tweaking of the designs. Only when these restricted designs had reached a sufficient level of performance were the students allowed to modify the structures themselves. Despite severely limiting the freedom of the designs at the most conceptual, schematic phase, the final output of the studio displayed a range and variety that belied its origin. In addition, this limited beginning ensured that the projects maintained a certain level of performance as an urban agglomeration, allowing for direct comparison of different solutions as well as freeing the discussion of the projects from purely practical concerns. Finally, the act of struggling against the given constraints was in itself a valuable experience for the students, as it introduced a range of strategies to overcome the limitations of the given structures that, while common in practice, are rarely explored in academia.
If one is looking for confirmation that visualization and feedback are increasingly important in design, you need look no farther than the Autodesk Labs, the R&D wing of the billion-dollar CAD behemoth that provides the vast majority of architectural software solutions in the U.S. Several recent Labs releases, most notably the Galileo and Vasari projects, are lightweight, simple schematic environments that incorporate multiple levels of analysis and feedback within the tool itself. Vasari is particularly interesting, as it is ultimately the combination of several products that Autodesk has already developed: a simplified version of Revit's schematic design package, with the Nucleus physics engine from Maya and environmental modeling tools from Ecotect. It is, however, more than the sum of its parts. Autodesk has, first of all, made the program free, and has packaged it as a simple executable, which promotes sharing among users. They have also built in some collaborative features, such as a dedicated user forum. Finally, the incorporated analysis is geared towards quick, even real-time results, which promotes a rapid response loop in the design process that approaches a game-like environment. Particularly in the incorporation of the Nucleus physics tools, these methods start to look more like the kind of implicit rules you'd see in a video game, rather than explicit ones applied selectively, that you normally see in parametric design environments. This distinction is vital in transforming a program from a passive tool to an active symbiotic collaborator, as it allows for the kind of perceptual learning described above.
Even if it is fairly certain that these feedback methods will make it into design software, the strategy for implementation is still very much up in the air. Currently there are two main strategies being used by design software companies to produce complex products. The reigning solution for the last few decades has been that of the "monolith," an all-encompassing, proprietary, black-box program that attempts to have a feature that meets every possible user need. This worked well when the goal was 2d CAD, but newer parametric software has tended to be overburdened, buggy and confusing, as the development teams go chasing too many rabbits down too many holes. The end result of this strategy ends up being something similar to Digital Project/CATIA, with multiple "workbenches," tiered pricing structures, baffling documentation, and a learning curve that is essentially a vertical wall. In addtion, monolithic software often ends up so large it has difficulty making transitions to take advantage of changing technology or practice. The alternative "software as ecosystem" strategy is currently exemplified in the world of design software by Rhino. The idea is very different - create a stable, well documented core program, ideally with some open source component and a fully developed API, and enable independent developers to create extensions and plug ins to extend the capabilities of the software. This leads to a more flexible, nimble platform for design, and is perhaps better suited to the end needs of a forward-thinking architecture firm, where multiple programs are used in series or parallel to achieve different goals at different times. This diagram by SHoP of their workflow reveals this central dilemma to digital practice:
What you have there is easily six figures' worth of design software, much of it having massive amounts of feature overlap. I'm not saying that a cutting-edge digital practice shouldn't have a big toolkit, but some of the nodes in that diagram were purchased to use only a tiny portion of their core functionality -- it's like buying a Ferrari to use the radio. Obviously, a few flexible programs would suit this sort of workflow far better than a big pile of inflexible monolithic software. However, the monolithic approach can have advantages as well -- it is more stable, easier to standardize, and often more predictable. Apple is essentially a monolith, with the notable exception of the app store (which, I might add, is rigidly policed). There are a lot of people (including myself) who are more interested in a stable and easily usable interface for their phone than the flexibility and hackability of an open-source, device independent communication OS such as Android. This is, I feel, the reason that there is no ecosystem-based parametric software solution as fully featured as DP or Revit -- BIM implementation in offices values stability and reliable standards much more than flexibility or openness.
Schematic design environments, on the other hand, value flexibility, independence, and adaptability, which suggests that Rhino or something like it will likely be seen on more and more screens in practice in the near future. Innovations such as Kangaroo and Grasshopper have no real equivalent in anything produced by Dessault, Autodesk, or Bentley, and I feel that is unlikely to change. The primary danger I see in the incorporation of implicit rules and rich feedback in design environments is that designers might not "push back" enough, leading to uninspired and predictable results. If the incorporation of these methods was relegated to a "black box" in the software that is a far more likely outcome. However, when incorporated in a plug-in users are more likely to customize and understand the implications of the environment they are creating, leading to a richer and less constrained outcome.
Next: Pt. 3: Stuff I Made, Next Steps
Thesis Presentation: Pt.1: Data Visualization and Cognitive Co-Processors
The title image for my presentation is a little facetious. My thesis is not about World of Warcraft as a paradigm of design, nor is it even about the possibilities of game engines as design environments (though I'd like to see an attempt.) The image was chosen partially as a provocative seat-filler, and as a shot across the bow: self-seriousness will not be considered as an important metric when judging the relative fitness of computational design environments.
But before we move on to the next image, let's give this one it's due. Because, orcs and white tigers aside, World of Warcraft has some of the most sophisticated interface design of any consumer software in history. This is an interface that has its own API. Its user base is so dedicated that there are not only open-source skins and addons, there are open source IDEs dedicated to producing new skins and add-ons. This is to clicking and scrolling what muscle cars are to driving-- so much innovation piled on top of itself that the question of "authentic" or "original" loses meaning and the only real metric becomes relative performance. You can write methods and tools into this interface that contextualize themselves to the environment around you, or to the time of day, or to what kind of mood you are in. In short, the interface is the environment. And what an environment it is, with embedded physics, dynamic lighting, and hundreds of visual effects and glyphs that let you know exactly what is going as clearly and quickly as possible. And on top of all of this is a sophisticated, dynamic method of communication that combines aspects of IM, forums, text messages, and email into a single communicative package.
So the question becomes: why the hell don't I get to use this at work?
With the advent of powerful building information modeling and design development interfaces, as well as a panoply of other new technologies, architects now have access to unbelievable amounts of embedded or intrinsic information. Enhanced geometric information like curvature, slope, and curl. Structural data from finite element analysis. Material data, cost data, project schedules and team makeups. Environmental analysis results. GIS contextual info about rainfall, wind, demographics. Satellite imagery, geotagging, foursquare check ins. FOI requests on security cameras pointed at public space. And yet, with this ocean of information, we have the tiniest of straws to access it in a dynamic and understandable way. The above image shows fabrication data about a curtain wall, but in order to be published the drawing had to be run through an entire secondary graphical process to make the information understandable. Why is this necessary?
Here we have four images of the same project, all produced by Autodesk Ecotect, showing entirely different types of information: wind pressure, wind temperature, insolation, and visibility. Despite the wide variety of data types, the same method is being used to show all four of the sets: a rainbow heatmap. First of all, this is perhaps one of the worst ways to accurately show quantitative information. The colors used all have different brightness values, distorting the scale and making certain equal steps in value seem farther apart then others. It's also notoriously hard to convert to a form that is machine-readable, making it difficult to incorporate into a computational strategy. It's notoriously sensitive to the von Bezold Spreading Effect. And what do you do if you're colorblind? At the very least they could have used Colorbrewer (or, dare I say, made it greyscale). But even then they're eliminating valuable information and making impossible to compare any of these datasets in the same image. Why not use a method that also shows wind direction to talk about pressure or temperature? Why not indicate the point of view when talking about visibility? Heatmaps are used for two reasons : a) they look "scientific," and b) they are easy to program. If we're going to understand any of the quantitative data underlying design, we have to do better than this.*
I would argue that in order for data-driven, computational methods to ever make an impact in the practice of architecture, the basic definition of architectural output has to be changed from a geometric idea of drawing to one of data visualization. The definition above allows for the incorporation of nonspatial or extraspatial data, while maintaining the agency of the designer as priority one. The computer is recast as a form of augmentation-- what visual researchers call the "cognitive co-processor." The design process becomes one of synthesis and feedback, where intuitive exploration is combined with algorithmic optimization to produce results that surpass the abilities of either method on its own.
If one is inclined to understand design as a process of problem solving, than the problem domain is always going to be ill-defined, discontinuous, and unpredictable. Using data visualization and rich feedback gives the designer the ability to explore non-"optimal" solutions in the service of other requirements or desires that cannot be described in an algorithmic process.
So, what does all of this have to do with games? A visualization environment is by definition providing guidance to reach a goal, however unfocused or poorly defined that goal may be. The exploration of possible solutions or paths to that goal, with accurate and well-defined feedback to help in the exploration, is more similar to a puzzle or game environment than it is to drafting. In fact, games themselves, if well designed and popular, can showcase the very best of the human ability to find patterns and extrapolate results. The above diagrams were drawn by Jamey Pittman to describe the AI and interface details of Pac-Man. In the decades after its release, Pac-Man was so thoroughly analyzed and reverse-engineered that players were able to achieve perfect scores and essentially beat the game - a task that the game designers had tried to make impossible. More incredibly, the majority of this analysis was done purely through gameplay, and was then later confirmed through examination of the source code. We have within our skulls the most powerful visual and spatial analysis tools in the world. It is time that our software took advantage of that fact.
Jane McGonigal, in a 2010 TED talk, claimed that the average young person in a country with a strong gaming culture will have spent 10,000 hours playing video games, which is incidentally the same amount of time they will have spent in school between fifth grade and high school graduation. This "parallel track of education" is attuning the latest generation to pattern-finding within a certain type of interface. If we are to leverage this ability, it might be a good idea to examine the interfaces themselves.
Coming Soon: Pt.2: The Monolith vs. the Ecosystem - FoldIt, Utile, and a million-dollar gamble.
*If you want to learn more about the human visual system, please please read "Visual Thinking for Design" by Colin Ware. I would make this book required reading for any designer if I could.