A note on the matrix: as always, I intentionally gave myself several goals to achieve so I could select from them as I progressed. In the end, there were some goals that, though I'm interested in them, I either didn't have the time or resources to achieve. Though obviously undesirable, it was anticipated and was part of my over all strategy for research during this semester.
For a summary of my experiments and their findings, please read this post.
Marketing "Images"
The set of building forms in this image are shown in more detail below. They were produced using a genetic algorithm I created using Grasshopper for Rhinoceros 4.0 Trial.
Rather than being distinct, the experiments at times melded in with one another conceptually. So, I'll describe them individually, but you'll likely see some overlap. To save on words, I'll also state here that many of the experiments served a secondary purpose of improving my programming skills.
Experiment 1 Programming Forms that React to Occupants in Unity3D
Purposes: Check feasibility of hosting a 3D model of a building on this blog that users can walk through and experience. Program forms that can dynamically react to someone's presence.
Observations:
It's possible to host a 3D model of a building on this blog, and users can walk through and experience it. Graphically not as pleasing or realistic as the Crysis Engine, but portability and formal nature somewhat balances this. Custom shaders could be downloaded and used to improve the aesthetic.
Forms reacted to someone's presence, but are too abstract for now so were left as ethereal blocks. This idea could prove useful and interesting for seeing realtime sections of building spaces.
Experiment 2 Evolution with Javascript
Purposes: Familiarise myself with concepts of evolution and encapsulating them through Javascript.
Observations:
Evolution was fairly simple to encapsulate, though the script started to get a little messy from a bit of design-as-you-code that was inevitable in this circumstance.
Russell commented that it the fine structure and processes behind the evolution weren't really being shown, so that could stand revision.
Experiment 3 Generating Forms in Grasshopper
Purposes: Familiarise myself with Grasshopper and Rhino for later use in evolving a building.
Observations:
After to referring to a few video tutorials online, some examples from Jeremy Harkins that Russell suggested, and doing a ton of trial-and-error modelling, I can safely say I'm fairly confident in Grasshopper now. It definitely seems promising to use in the coming semester!
Experiment 4 Growth and Evolution with Javascript
Purposes: Familiarise myself with concepts of evolution and encapsulating them through Javascript. Show fine structure and processes behind the evolution.
Observations:
Evolution wasn't successfully encapsulated this time, since I spent too much time trying to get the aesthetic both pleasing and simple enough for the canvas to render (quite a mission given the poor canvas support from most browser versions!).
HTML5 seems not to be as well-supported as needed by most browsers yet.
Experiment 5 Evolutionary Algorithms in Grasshopper: City Generation
Purposes: Familiarise myself with Grasshopper and Rhino. Seeing if I can produce something that looks convincingly like a city to test my understanding of city form and development.
Observations:
This was my favourite experiment of all, and perhaps the most challenging. The main issues I faced related to caveats of Rhino and Grasshopper functionality, some of which needed workarounds with VBScript components. For example, when offsetting a curve, there's no way to tell Rhino or Grasshopper to expand or contract it, so you just need to try an offset and see if the curve is longer or shorter than the original. The other issue was to do with iterating over trees and lists, and was solved with a Graft component.
Convincing city forms were successfully being generated, though the subdivision method for city blocks could do with improvement.
After reading through relevant information about evolution, I've got my head around how the Galapagos evolutionary solver component works, and tried it out with the city generator to optimise increasing city GFA against minimising total building footprint area, all while keeping plan areas within reasonable bounds. I'll definitely be involving Grasshopper in next semester's form generation.
Experiment 6 Viewing Sydney through Information Technology (Yahoo Pipes)
Purposes: Familiarise myself with Yahoo Pipes and see if it will prove useful as a design informant to look into the life of Sydney as a kind of living, dynamically changing organism.
Observations:
As a feed processor and design informant, Yahoo Pipes shows promise, but as it stands it's lacking in some basic areas of streamlined functionality (eg, the process of filtering out everything but the tags and images from a feed seems needlessly complicated, and getting results from the pipe sometimes requires clicking on each "element" in turn and waiting for it to do its processing.)
Over all, I think I can work a little with Yahoo Pipes, but I don't think it would be a good idea to rely on it too heavily.
Experiment 7 Retrieving Information Updated in Real Time with Yahoo Pipes and Processing it for Viewing
Purposes: Develop a means by which to view a collection of snapshots of Sydney found uploaded online; this collection will inform the range of lifestyles and events that a building might potentially be host to and exposed to. Ideally, this data representation will also be aesthetically pleasing.
Observations:
Once a Yahoo Pipe is constructed, it works pleasingly well and simply. Remotely extracting information from a Pipe proved fairly easy, needing only a bit of custom Javascript and HTML. Shuffling the results to reduce instances of contiguously-themed blocks of data was simple, too, thanks to a little Googling.
With some Javascript and CSS, a pleasing set of images were produced on a grid, which looks somewhat aesthetically pleasing.
To get a good snapshot of the city, it would be best to retrieve images from as many sources as possible to get a larger sample population. This means scouring the internet for image feeds.
Increasing Urban Density and the Utility of an Adaptive Space
As argued by Matthew Pullinger of Hassell, intelligently increasing urban density is an essential move to creating a sustainable city. With the implementation of a few simple strategies - intelligently measuring urban density (as mentioned), linking main city centres with an orbital rail network, and integrating mixed use zoning rather than compartmentalised zoning to reduce transit distances (ie, the failing of the garden city strategy) - a sustainable city can very likely be realised. One concern voiced by Matthew was that of amenity in urban density. Density can be increased, but often at the cost of amenity.
One idea that's stuck with me over time is that of a space which can physically transform to suit its function. Such a space could be argued as being active, alive, and adaptive. As an extended phenotype of its inhabitants, a building capable of physical transformations can effectively coadapt with humans through adjusting its amenity to survive.
Some quick examples of compact living achieved through a dynamic space design (there are plenty of examples online, but these two stood out to me for being a clever renovation of a space with existing dimensions rather than a compact design with a freer range of dimensions being plonked in the middle of a field or other open space):
Such spaces require active, able-bodied occupants. As suggested by Christian in the second video, such a space provides physical exercise whole also addressing the issue of intelligently increasing urban density. However, it's obvious that some living spaces would have to meet the physical capacity of less fit occupants. In this sense, a new, lighter degree of disability would implicitly be established in creating these apartments - the disability to live in such a dense, active environment.
Choosing Bemes to Include in Evolutionary Form Generation
In the final critique last week, it was suggested by two of the guest critics that I should narrow down the range of bemes (click for a definition of "beme") I am looking at so that I can specifically use two or three of them - for example, the increasingly popular beme for homes having a living space dividing the front door, kitchen, and bedrooms. A further suggestion was to choose bemes that can have their fitness in a given context measured. This gives the opportunity to actually test my design to see if it meets given performance criteria (eg, sun access, living space dimensions, etc).
A method I've found useful for planning work is to set two goals for myself. One that's realistic to achieve, and another that's far harder and thus more unlikely for me to achieve in the same timeframe.
The first goal, in this instance, will be the integration of two bemes into form generation that relies on the process of evolution. Since I'm aiming to improve amenity while intelligently increasing urban density, the bemes I've chosen are:
Optimal Sun Access for as many apartments (and offices) as possible, typically in the form of north-facing windows.
Optimal Apartment Dimensions for functions typically contained within them, while also considering compact apartment living types and prototypes I'll continue to research.
The second goal will be:
Automatic Space Arrangement within apartments and / or offices. This is something I've been wanting to do for several years, but until now I haven't really had the support to attempt it in a design studio. It'd be great to achieve this aim, because many projects in the real world could stand to have some automation to save manually designing each parametrically repetitive space in a large complex.
Here's a video of that City Generator I made in action, iterating through a ton of genomes within each generation, right up to about the 22nd or 23rd generation, at which point the morphology of the city had begun to stabilise into a reliable subset of the gene space.
The generator's still using a Substrate component to split the city blocks up, which is something I'd like to change for a subdivision method of my own devices later on. The issue with the Substrate component is that it occasionally produces incredibly thin city blocks, rather than more "neatly" spacing its generated lines. And with that, sleep!
The Pipe itself is fairly simple, searching a range of emotionally and culturally powerful terms that can be expanded as desired for more comprehensive information. As the experiment stands, it serves as a proof of concept for the kinds of interesting results that can come from a simple data-collecting process.
I noticed that certain images were being grouped together in the feed provided, creating sequential sets of data from like sources. To fix this, I found a clean, generic shuffle() function someone had written in Javascript, based on what they called the "Fisher-Yates" algorithm. This lets the image feeds be viewed the way I intended: in a random order, so that at a glance you have a good chance of seeing the face of the city for what it is to its locals and visitors.
I think something based off these snapshots would form a good background for the panels I'm producing for tomorrow. Like a randomly varied genome, I'll replace random sequences of images with new information.
Also, a note for me to read later: upload the timelapse of a proto-city evolving in Grasshopper with Galapagos!
Since what I've got going on in the background is somewhat transient and mixed with the other information on this page, I thought it'd be a good idea to throw together a bit of HTML to act as a locally available webpage that I (or you, if you copy the text from here and save it as a .html file) can access at any time and capture at the press of a button.
