By Ping Lei
According to Simon Cozens, “Hello World!” is the “traditional incantation to the programming gods to help you learn the (programming) language better”. I have been trying to learn programming for quite a long time, but never had the chance to write my first “Hello World” programme.
So, why would I, or someone with an architectural background want to learn programming? The reason is simple. It is a trend, and also a response to a need. Technology affects our lifestyles, and even the way we design. With the advent of the Internet, Computer-Aided Design (CAD), Building Information Modeling (BIM), as well as parametric design, the skill sets of the architects nowadays are very different compared to a few decades ago. If we think of computers as our best design assistants these days, we should use them to do what they are best at – performing spontaneous repetitive calculations and storing huge amounts of information.
A designer’s imagination has no boundaries, but the most common limitation he may face is the tools he uses. Computers have limits, so we have to push those limits. Today’s computers are much more powerful than ten years ago, yet they are still unable to accomplish certain tasks that we humans can think of. Rather than waiting for the super computers of the future to arrive, I believe it is time to make a paradigm shift in terms of design thinking, methodology, and even our working relationship with the computers, so that we can still achieve something great within current technological limitations.
People often refer to the computing industry as “Information Technology”, or “IT” in short. Exchanging information is communication. Although it may appear that the only communication happens between human end-users, computers are involved in the process as well – they are the agents of their respective end-users, translating between human input and matrices of “0”s &“1”s.
If we want to make sure that computers perform their duties properly, then we need to communicate with computers in languages that they can interpret and understand. Most of the time, this communication is carried out in the form of a programme, or a script in my case.
In this article, I would like to share my experience with my Master Thesis project at NUS – both the sweet and bitter memories about design with procedural rule-based modelling.
Suzhou: Aerial View
My thesis design scheme was to create a series of floating food markets along the moats surrounding the ancient city of Suzhou, in preparation for the global energy-descent future. I started with the premise that Inland Water Transport (IWT) would be a more energy-efficient alternative to the predominant motorway transport. Suzhou, the city also known as “the Venice of the Orient”, was chosen to host the project site, because 42% of the city is covered by water, with 24km of navigable canals in the urban districts. Using the food market network as an architectural intervention, my thesis aimed to remedy the broken relationship between the waterways and the residents in Suzhou. It also attempted to address local issues regarding food safety and food prices.
The project embarked from the current post-peak oil global situation. Global oil consumption patterns have indicated that, almost half of the annual oil consumption is related to transportation. It follows that if we could change the way that we move people and goods around the world, a new low energy footprint lifestyle would result, which would ease the worrying energy future scenario by a significant extent.
The next question was: Can the scenario be improved via any architectural means in the near future, say 2030? Where to start? Being one of the fastest developing economies in the world, the energy demand in China is obviously high. China ranks second in terms of oil consumption, immediately after the USA.
As a 2nd tier city, Suzhou has a fast-developing economy and more flexibility to be shaped, compared to 1st tier cities like Shanghai, Beijing, and Shenzhen. In my design scheme, there are eight floating markets in total, located along the moats surrounding the ancient Suzhou city, immediately outside the downtown area. All the markets are located at the intersections between the public transport routes and waterways, and are connected via riverfront walkways.
A procedural rule-based design workflow was adopted both at the urban scale and at the building level.
The Waterborne Suzhou
Location of Suzhou, Jiangsu, China
Built in 514 B.C., ancient Suzhou city had already developed an extensive canal system a long time ago. These canals have been well maintained, added, joined, and extended over the subsequent 25 centuries, and they remain remarkably well maintained today, despite the fact that they are seldom used. The canals reach almost every corner of the city, from the downtown old streets, to the farms and agricultural land at the outskirts of the city.
Suzhou (Downtown) Canal Network in 2000
The Eight Markets
Overview of the 8 Sites
There are eight markets in total. All the eight locations were chosen based on the same set of requirements:
- There must be three main lines, namely the river (blue), the parallel road (red), and the flyover bridge (black) connecting the downtown Suzhou and outer districts.
- The market locations cannot be too close to one another, to ensure the efficiency of the market distribution and coverage.
- The passengers will approach the markets via public transport on land; the food will be delivered by boats via the canals to the markets.
Rules for Walkway/Market Platform
Walkway Modelling Rules
Taking the loop of the moats as the starting line, the two banks of the canal give the first two curves.
- A third curve is the nearest road, adjacent to the outer bank of the canal.
- The centre line is divided into 1982 segments, 8 meters apart (8m is considered to be the suitable column span, important for the modeling of market roof later)
- Two different types of event nodes are assigned (Market v.s. River Branch)
- The platform section will always be represented by a line formed by 24 points. The arrangement of the points will vary according to the FOUR different scenarios of event permutation along the waterway.
[A] River Branch Event: The platform will be raised at a level of +4.5m above the annual water level, to allow boats to enter and leave the ring of canal.
[B] Market Event: An additional platform will be generated from the 5th staircase step, form a parabolic shape for the market space, allowing trade to take place.
Rules for Market Roof (5 lines)
All heights in the chart are measured from the annual average water level. The roof structure covers the 180m range from the market location. The distance from the location point, X, is the control parameter which affects the roof profile.
Acoustic Barrier Tip varies according to the (1) height of nearest road, and (2) distance to the nearest road.
Roof Edge is kept almost constant.
Central Roof Ridge has a parabolic increment from 9m to 15m.
The Roof Kink takes off and starts to catch up with the Central Roof Ridge 40m from the market location. This is to provide a horizontal roof at the joint to the flyover. Pedestrians can thus access the food market not only from the road running parallel to it, but also directly from the flyover bridge. (Suzhou is a pedestrian and cyclist-friendly city; all major roads have at least 4m wide pedestrian walkways on both sides.)
Site One – Roof Sectional Profiles
Up to this point, all the above processes were carried out in Houdini – a parametric modelling software program developed by SideFX. Despite being a very flexible modelling tool, it could only allow me to model the rough backbone of the structure. After all, this was a design for the entire urbanscape, and there was a tremendous number of elements to be included. Any further detailing of the design would have a multiplying effect due to the project scale, and my computer memory would soon become a bottleneck.
I decided to export the individual market models, in order to focus on and develop the design on a building scale. To do this, I had to solve two problems. First, the inter-operability between software programmes, i.e., whether the model exported from Houdini could be accepted by the second programme. The other problem was how to continue with the same rule-based procedural modelling in the new software. The size of one market is quite large, and if I were to model each single component, I would miss the submission deadline for sure.
I found my saviour – Rhinoceros, a NURBS modeling software developed by McNeel. With a Rhino plug-in – Panelling Tools, I could easily solve these two headaches at one shot.
To simplify the design language, I adopted 5 types of panel geometries – quadrilaterals with apertures of various sizes. Horizontal Roof Panels and Acoustic Barrier Panels, are two special cases.
Exploded View of Components
Rule-based Panelling Technique
The space beneath the roof would be poorly lit due to the deep plan, so I decided to introduce more natural daylight to the space. A repulsion sphere was placed in the centre of each Horizontal Roof Panel to distort the rectangular grid so that the panels in the middle would be larger. Based on their proximity to the repulsion sphere, panels with larger apertures were located nearer to the middle. The effect of the “light well” effect can be seen from the renderings. I also wanted to retain the visual connection between the two sides of the Acoustic Barrier. An attraction line was used to represent the average eye level of the pedestrians on the road side, and panels closer to the attraction line have larger apertures.
Site No. 1
During the last month of my thesis project, I took a gamble to switch my operating system from 32-bit Windows 7 to 64-bit Windows 7. The only intention was to increase the usable computer memory to more than 4 GB. It was a risky decision, as the compatibility of some software is not guaranteed. There were some moments of pure panic, as I tried to find solutions or alternative methods to various issues that cropped up from online forums.
Eventually I was very pleased to finish the entire production within 3 weeks. Although the limitations of both software and hardware can be deeply frustrating, the benefits of rule-based procedural modelling have been tried and tested and it is in my opinion, well worth the effort. ♦