Last week at the office I’ve been busy working out schedules for configurations of 350 dorm rooms for a student facility. It was about finding the right and most effective and economic configuration for six bedroom clusters, twin bedrooms and studios, based on a percentages which in turn were based on marked research done by the client. I had to take into consideration the positions of fire escapes, traffic lengths in case of emergencies and other building regulations as well as contextual aspects like the orientation of the site, planning specifications, the position of the sun etc. etc.
These rather dull exercises are necessary to develop a perception or ‘feeling’ of the building before the development of an actual architectural concept can commence. It means working through loads and loads of options, just to acquire the necessary intuition of what iss possible and realistic within the boundaries of your assignment, and what is not. It is sheer number crunching. Consequently I’ve seen loads of spreadsheets and schedules and done loads of calculations.
An iterative approach as such is inherent to design. And it applies to all levels of design. I remember visiting the Content exhibition of OMA in De Kunsthal in Rotterdam, where vast numbers of models were exposed of what was to become the CCTV building in Beijing. They were needed to get a perception of the concept, to explore all aspects and define the consequences of all options.
Norman Foster, when designing the Swiss RE or Gherkin building in London, used software to define the most profitable shape for the building in terms of aerodynamics. The aim was to reduce the winds at ground level or ‘canyon effect’ in order to keep life for pedestrians worthwhile.The computer iterated all options based on some predefined contextual parameters, and eventually the perfect section rolled out which provided the starting point for the actual design process.
Now Fosters approach could be seen as semi automated as most of the preliminary work was done by a computer. And truth be told, so was OMA’s, as all its preliminary work is done by unpaid interns. So we could cautiously conclude that the computer could take over some of the boring work done in an architects office. Regulations are fixed parameters and are not open to discussion or interpretations. So human involvement is not vital in this stage.
This video, made by Daniel Davis, illustrates this point beautifully.
Continuation: here.
1 Response to “Algorithmic Architecture (1)”