Thesis: Done
Well, after 23 slides, 80+ pages, and hundreds (thousands?) of lines of code, my thesis is complete! The presentation went well and the discussion brought up a number of ideas on where I could go from here.
The thesis is entitled "Games as Design Environments," and looks at data visualization and gamelike interaction methods as possible templates for the future of digital design environments. I'm a bit exhausted on the topic and so won't go into detail today, but if you're curious I've put the research document in my issuu account for your easy perusal:
Watch this space for future posts where I walk through the presentation in detail.
aFloat @ MIT+150 is done!
Well, after a solid week of work, piles of LEDs, acrylic and 3d prints, and a half mile of wire, our installation went up! This project was an interactive light and sound installation that was designed to complement one of my favorite buildings in Boston - the MIT chapel by Saarinen. The project involved a grid of 150 LEDs with linkages connecting them in an interactive network. Sensors embedded in the grid sense movement and create responsive light and sound effects. Our team included Otto Ng from MIT, and Senya Zeitsev and Dena Molnar from my program at MIT. The project grew out of a final project for our Augmented Architecture class last semester. Thank you to the dozens of people that helped with this project, and also to George for the fantastic photos! Apparently we had over 2,000 visitors on a single night!
Until I can get php 5 running on this server, You'll have to be ok with a single image and a link to the facebook gallery that may or may not be public... oh well.
CS171 Final Project – Treemapping Architectural Program Documents
Treemapping a Middle School
It seems like all I do here is post Processing applets. Well, here's another one. This is the final project for my CS visualizations class, an attempt to use treemapping to explore architectural program documents. The full project presentation is here, which includes some background and discussion of the goals and implementation.
I started out thinking I was going to make an adjacency diagram tool, that used graph representation to explore the topology of an architectural program. This sort of idea has been explored fairly thoroughly by Aedas R&D as well as by a BVN Usyd team. However, after some research and test implementation I changed my approach to treemapping, which drops adjacency in favor of nested grouping. The reasons behind this were based not only on an interpretation of the data at hand, but also on the relationship between diagrams and built work in architecture and a desire to make something that was not formally suggestive.
Graph representation has at least a 50 year history computational design, with the initial apotheosis occurring in the mid 1970's at Cambridge University, in research labs aimed primarily at optimizing architecture for walking distances. This was part of a larger search for architectural problems that had objective solutions, to create a school of architecture that had a solid scientific basis. While the work done by the CU researchers was rigorous and interesting, ultimately walking distance faded as an area of research, partially because its optimal organizations often flew in the face of other architectural requirements (such as constructability) but also because the issue of adjacency was more easily solved through telephone and intercom systems. For a more in-depth exploration of this history, please read the "Fenland Tech" article by Sean Keller in the MIT press, or better yet his GSD thesis from a few years ago.
Compounding this historical warning flag was the fact that producing graph layouts of existing structures is actually a lossy, reductionist way of showing floor plan information - one early reviewer called the idea "idempotent." There is also some inherent flaws in the method, such as how to represent circulation space, particularly looped hallways. The topology of a building's room layout is invariably more complicated than a simple graph layout can really indicate, and usually some important detail is lost in the conversion. The BVN blog has a great post on the limitations of adjacency graphs.
I looked instead more closely at visualizing nonspatial data-- that is, the horrifically boring, overly detailed program requirement documents that get handed over to architects on pretty much any large scale project. I concentrated in particular on public school documentation, as they are inextricably linked to public policy and funding, and the building type is overdue for some re-imagination. On review, it became quickly clear that adjacency doesn't really play a strong part in program requirements, and where it is mentioned, relationships are unclear (adjacency can be defined by nearness, visibility, connectedness, etc). I chose instead to take advantage of the basic structure of the document - as a series of nested groups - and visualize this ownership hierarchy over some imagined or invented connectivity. Doing this also avoided a major pitfall of program visualization, which is that bubble diagrams or adjacency graphs can be too suggestive of a final form, leading to the architect "building the diagram." This method takes maximum advantage of the spatial encoding of data while being as neutral to the idea of a building's form as possible.
In the end, I'm not that enamored with the tool I've created, but the above insight makes the entire process worthwhile.
quick update/teaser
I apologize for the complete lack of activity here in the last month, as thesis and other projects are currently kicking me silly. I promise a barrage of updates as each project comes to term in the next few weeks. For now, here's a sneak peek at one of the many little things I'm working on at the moment - evenly spaced interactive tensor field hyperstreamlines. Woot.
Yet More Applets – now with springs!
It should be clear to pretty much everyone on the planet by now that i'm a big fan of the Processing visual programming language. Well, here is more evidence. In the process of trying out algorithms for my thesis, I made a couple of games using spring force / attractor algorithms where you can make little structures and play with catenary curves. Both games use a similar interface, the main difference is that one is 3d (don't be fooled by that third dimension, I think the 2d version is actually more fun.)
You can find the 2d game here and the 3d game here. I'm going to make a separate applet page one of these days, promise.
The games are pretty easy to play:
Happy springing!
Mux Redux {aFloat @ MIT FAST FESTIVAL}
Lastest milestone on the completion of our team installation, aFLOAT, for the MIT+150 FAST festival. This is a proof-of-concept for the multiplexing and animation code in the installation. It's run off of an Arduino and a series of TLC5940 multiplexing chips - we tried conventional multiplexing but had issues with flickering when we tried to dim the bulbs (not to mention overloading the Arduino itself). The animation is triggered by a piezo sensor at the upper left corner of the matrix. This version has 64 LEDs (8x8) on a 4"x8" breadboard. The final product will be 150 LEDs in a 12' diameter circle!
Dollas Dollas
For my Visualizations class the first project was to use screen scraping to get some set of usable data and make a very simple visualization using Many Eyes. I chose to scrape the Archinect Salary Poll for unknown, probably masochistic reasons. The data can be found in its very messy raw state here, and a simple scatter plot with substantially cleaner (but US only) data can be found here, or can be seen below. And yes, I doubt those 23 year old six figure incomes as well. I really wanted to get different colors for men and women, but unfortunately the software doesn't do that. If someone wants to come up with a better looking plot have a blast.
FAST @ MIT 150: aFLOAT
Well, it's official - my team project (with Arseni Zeitsev, Dena Molnar and Otto Ng) has been selected to be part of the MIT 150th anniversary celebration! The installation, similar to our project for Augmented Architecture last semester, will involve a large flexible grid of LED lights that respond interactively. I'll keep you posted as to the progress...
Games as Design Environments I: Tinkerbox and Other Opportunities
Spoiler alert - in the next few months, you're going to see a lot of noise from my corner about visualization, user experience, and games, as this is increasingly the concern of my thesis. Put very briefly, the current state of digital design environments are poorly situated to deal with both the overload of contextual and internal data involved in a project, and the interplay between flexibility and specificity that is necessary to explore the intersections and opportunities in that data. We have tools that can look at data (mostly with three-letter acronyms), and we have tools that are friendly to design (usually with fun, clever names), but very little that allows a bridge between the two. Autodesk is attempting to go a bit down this road with Vasari (as I mentioned a few weeks ago) and I feel that other, similar tools are not far off.
These kinds of tools, with immediate (hopefully real-time) feedback, clear metrics, and open interfaces, actually resemble games more than drawing or modeling interfaces. Actually, if you go by Chris Crawford's definition, they are more accurately called toys or puzzles. This kind of interface is becoming increasingly familiar, whether it is an interactive graphic for the NYTimes or some kind of physics or geometry based puzzle. Many of these games (Tetris, for example) can actually be seen as a kind of human-based optimization algorithm, where people's natural curiosity and competitiveness combines with an entertaining interface to incentivise the solving of a certain problem. Underscoring this trend would be Autodesk's new game, Tinkerbox, for the iPad, which is a physics-based puzzle/toy/game (that appears to include some fancy stuff like linkages and inverse kinematics). It only takes a little creativity to imagine how this sort of interface could get applied to solving problems with bearing on real life:
The application of games to "real world" tasks has already been achieved in fold.it, where protein folding (a complicated geometrical problem that is difficult to solve computationally) has been turned into a game - like some sort of massively complex combination of tetris and a rubik's cube:
This has been lauded as the "crowdsourcing" of science, but I think that's actually pretty inaccurate. Crowdsourcing to me implies that they are tapping into a latent resource, but what is actually happening is much more clever. The first thing you have to do after installing fold.it is to go through a series of training tutorials - a common task at the beginning of every game. This particular set of practice games introduces you to the rules of protein folding, as well as the very clever interface (which I will cover in a later post). The game requires not only a fierce competitiveness, but also substantial three-dimensional visualization skills. I would argue that what is happening here is not crowdsourcing (which has actually been attempted with some success with Rosetta@home) but rather a search for people with the particular skills for this task, and a tool to allow them to show off their skills (and help cancer research in the process). In fact, in this Wired article it's pretty clear that that was their goal from the start - the makers outright claim that they are "looking for prodigies." What this highlights is that a well-designed game interface can allow for an incredible symbiosis between user and computer to produce results that would be impossible without such dedicated nuanced communication both ways. It's not crowdsourcing- it's some incredible new combination of translation and HR.
I have two conclusions to draw from all of this. One is that there is a whole world of puzzles that can draw from physical reality that haven't been tried yet. What about a game based upon spring models? Or reticulation? Or thermodynamics? I'm no expert, so some of this probably has been tried, but it seems to be a wide field begging for exploration.
The other conclusion is that game environments are actually ideally suited to the design process. They provide an open-ended way to search through very complex and unpredictable problem domains, while allowing the user at every point to balance between quantitative and qualitative values. And while using some sort of "click and wait" or optimization process divorces the user from the problem, gaming your way to a solution keeps the user in constant direct interaction with the problem at hand.
It seems to me that in a few years, interacting with a model by moving sliders or modifying a matrix or table are going to seem hopelessly antiquated and slow, not to mention horrifically boring. It's time to get physics, geometry, and the rest of the things we're trying to compute out from behind the screen and poke at them in realtime, and see how they poke back.
A quick look into the future: here are some screenshots of some material density maps I made today playing around with topostruct, a tool made by Panagiotis Michalatos and Sawako Kaijima (they have also made other structural analysis and design tools that you should check out - educational versions are available on their website). I made these with a crowd of other GSD students, and we were all having a blast. Topology optimization is not a priori a thrilling topic, but the way this tool is put together makes it engaging. I, for one, am looking forward to a future where structural analysis can be as intuitive and innately enjoyable as sketching.
Fiction, Design, and Genetic Algorithms
Computational designers in architecture (and grasshopper dilettantes such as myself) love to (over)use genetic algorithms in everyday work. Genetic algorithms (or GAs, as the cool kids call them) are a particularly fancy method for optimization that work as a kind of analogy to the genetic process in real life. The parameters you're optimizing for get put into a kind of simulated chromosome and then a series of generated genotypes slowly evolve into something that more closely fits the solution you're looking for, with simulated crossover and mutation to help make sure you're getting closer to a global optimum than a local one.
For those that don't regularly optimize (I know I should more often, but it's so much easier to just sit on the couch and vegetate), the imagery that gets used is of a "fitness landscape" where you're looking for the highest peak or the lowest valley, which represents the best solution to a problem:
Often, however, you're talking about a landscape with many dimensions, with lots of local optima - the lower peaks in the image above - that can seem like the best solution when they are not. Searching the entire problem domain takes far too long, and so this is when your optimization algorithm takes over - it uses a series of rules to try and search intelligently for the best (or at least close to the best) solution.
Genetic algorithms tend to get used a lot by architecture students, despite being fairly controversial in mathematics. A lot of this controversy has to do with how good GAs are at finding the actual optimal solution in a certain amount of time, versus selecting or writing another algorithm that works more well on that specific kind of problem. I think they are popular for the following reasons:
A. Design problems often involve dozens of variables, and GAs are well-suited to complex fitness landscapes.
B. Architects are often more interested in a very good solution rather than the best, and GAs can find a very good solution with very quick setup.
C. Architects are less interested in the runtime of the algorithm, so "faster" methods that aren't quite as robust or optimal are not necessary.
D. GAs work well on a wide range of problems, which architects interpret to mean "work great on all problems" for the reasons above.
E. "Genetic algorithm" sounds really cool, particularly in a presentation or lecture.
F. Grasshopper has a built in GA solver called Galapagos that works really well and looks cool.
As it goes, I don't really have problem with any of this. Architects are not mathematicians, so it's great that we have a fairly robust, flexible method for optimization that can get us better solutions than we can think up by staring at the screen. I'm not going to complain.
Where I was trying to get with all of this is that when I read the post today on BLDGBLOG one of the things that popped into my head eventually is that a lot of what design does is similar to a genetic algorithm. Bear with me here...
The post linked above shows two projects by Lik San Chan that, loosely defined, are architectural narrative pieces about food and space. They are really interesting pieces of speculative urbanism, and you should check them out. However, in Geoff's write up he mentions
...it's one thing to create, analyze, or even editorially promote architectural projects as narrative ideas—that is, as scenario plans for future landscapes—but it's another thing to look at whether or not such proposals do, in fact, operate successfully as solutions to the problems they highlight.
To which I responded in the comments,
Geoff, I love your blog, and I really really enjoy diving into projects such as these, but I have to say that I'm skeptical that using the harsh light of quantitative analysis on either of these proposals would really be a good idea. The tempelhof project has some obvious sociopolitical issues (as well as some probable agricultural ones), but even the smaller-scale fish market seems to have more to do with the Bartlett aesthetic and a romantic fictionalization of urbanism and light industry than it does with a real proposal for social change. You've argued very eloquently in the past for a place for architectural fiction. Suggesting that such fiction should be held up to rational standards would, I fear, not be kind to the work presented.
Don't get me wrong: I would like to see both of the above projects re-imagined as real proposals. However, such an exercise would most likely involve an interdisciplinary team, a lot of effort, and the result would be much less likely to lend itself to viral blog dissemination.
As is usual in blog commenting, immediately after clicking "post" I thought of another thing I wanted to say to clarify what I had just written. I'm not going to double-post on someone else's blog, however, as that would identify me correctly as a long-winded blowhard. However, I have my own forum for long-winded blowhardery here, so here it goes:
I can't help but feel that a lot of design that takes a fictional or narrative slant is valuable precisely because it doesn't attempt to quantitatively define the solution from the outset. To use an analogy to optimization and genetic algorithms (that I have thoughtfully provided exposition for above), the kind of freewheeling, speculative work that you see on BLDGBLOG provides a kind of free-associative mutation that help find globally optimal solutions to global problems (see what I did there). By definition, a lot of these projects are going to be completely nonrational and impossible, because if rationality was the prime directive we'd simply end up with a solution that was almost identical to the status quo.
It is absolutely vital to design that we simultaneously promote both speculative/narrative and optimal/performative approaches to architecture, as they are both vitally necessary to exploring the incredibly complex domain of reality.