Overview - Design Computation

The course work in Design Computation involved two aspects - a project work that introduced me to the platform of coding/algorithms in architecture and the second aspect which involved getting familiar with the theories of digital (I cannot be sure if digital is right word that describes all the aspects of it ) architecture with bi weekly sessions of reading and discussing.

Reflection on the Project work and Readings 

As this was my first experience in trying out algorithmic architecture - if I could describe algorithmic as a word wherein me as a designer 'writes' or pulls out a set of instructions for the computer to follow rather than use a visual software to 'draw' - I chose a simple design project - an interactive bubble diagram. This blog has been describing the process of the project. 

I am still contemplating on the switch of architects increasingly moving to 'writing' a code for their design rather than drawing it out. Definitely algorithmic architecture has helped automate the design process conveniently and increasing the intricacy of the design. It has also helped designers design without having to visually define the end objective but rather concentrate on the process and evolve the process and then at a point decide which  can be the best possible outcome.

I could not agree more with Carpe ( from the discussion on 29/04/14) as he stated that this whole realm of digital technologies (architecture) is advancing without any ideology of progress. Anyone from any field is able to pick this tool of writing an algorithm interpret/write it in  numerous ways and share it, for others to add on/ subtract/modify it. Hence the 'design space' has opportunities that cannot be necessarily imagined as a whole. 

There was a time when the hardware and the mechanics of things were given importance. But today, I feel the attention has shifted to the software, the digital realm of making things work rather than the physical. 

From all the various topics we covered - Algorithmic architecture, biological analogies, design space, design science, emergence, technology, computational theories and the project work - all of it can be clearly linked to this digital realm that I have been referring too.

All of these also dwells into processes of design rather than the objective or an end product. Algorithmic in itself is a process, though it can be rightly said that to write an algorithm, you need a clear goal in mind. The goal can be fixed, but the output can vary with the designer stumbling upon various 'reactions' and 'potencies' of the code.

The design computation course has left me wondering on a higher holistic level - is the digital realm popular among the 'human race' and of course architecture for our increased eagerness to automate or is  it purely an outcome of curiosity and inspiration ? 

The Bubble Diagram in Processing

Being fairly new to programming, which seems similar to learning any spoken language, requires to understand the basics of the 'grammar' of the language.

Below is the screen shot of a 5 program (LR, K, DR, BD, BA) bubble created in processing.

In this output the user is able to move all the five bubbles in any direction. Also the logic of spatial connection ( in this case BD and BA are always adjacent to each other. LR is connected to K and DR. DR and K are connected to each other) can be easily implemented in processing than it could in GH.

Similar to GH, spring systems is used in processing too. Each of the line drawn is a spring and helps enhance the user interaction.

In processing user interaction can go to a higher level, where users can add more bubbles with a right click and create a spring connection. 

Switching to Processing

The bubble diagram is just a small means to understand the potential of using programming language contrary to any visual medium as an aid for an architect to design.

GrassHopper is definitely a visual form of programming with ready to pull and plug in icons, but it can lack the flexibility of actually writing a programme code to perform a desired output.

Processing is an open source programming language meant for graphics and visual outputs.

The aim to use Processing as a language to programme the bubble diagram, is mainly to understand this flexibility that writing a programme provides and to see whether the issue of anchor points can be resolved with processing.

Final output in GH

A bubble diagram in GH is deterministic on the anchor points.As mentioned earlier, multiple anchor points can be assigned in GH, but assigning a point as an anchor point restricts the spring motion/ rest lengths we can assign to it. This means that a bubble that has its centrepoint as an anchor point can be moved as per the user's but will act as an independent bubble from the spring system.

Below is a bubble diagram for a  simple 2 bedroom residence.

In this bubble diagram, the anchor points are assigned to LR (Living Room), BD1 (Bedroom 1), and BD2 (Bedroom 2). The K (Kitchen), and DR (Dining Room) are assigned to the LR, with rest lengths zero, indicating they need to be adjacent to to the living room. The user can move the LR in any direction or distance and the K and DR would move long with it. 

Similarly BD1 and BD2 are also assigned anchor points and the user is able to move them both in space. In this case the T1 and T2 are given rest lengths zero and would move alongside BD1 and BD2. 

The bubble diagram works well in this system, as it is less complex. In cases for example where we would have to move K or DR the problem becomes complicated. Assigning K or DR with anchor points would make it act independent to LR. 

Using the Kangaroo Plugin

For this diagram we need to use the Kangaroo component with springs as a force object. 

The kangaroo component looks like the one indicated below in the image. A spring force can be added by using the Springs component. 

In this case our input geometry is a line and output geometry is also a line that acts as a spring. The input Rest length in the Springs component is what lets us add a constraint of adjacency.

An other important input is the AnchorPoints in the Kangaroo system. Any number of points can be assigned as Anchor points. Any point assigned as an anchor point lets you move that point in the Rhino interface but also the constraints of rest lengths no longer affect the point assigned as anchor point.

Hence deciding which points can be the anchor points in the bubble diagram is quite critical.

The Kangaroo plugin to create the interactive BD ( Bubble Diagram)

To create an interactive BD, the adjacency logic of the bubbles have to be translated to grasshopper. 

The Kangaroo plugin in grasshopper lets you create a spring system. Now imagine if the lines connecting the different circles in the BD were springs of various rest lengths depending on their adjacency. If you pull any circle, it maintains its relationships with its connected neighbors. 

The first step to using a spring system to clearly define the adjacency logic of a BD using a matrix. The image below shows a simple example of a residential matrix. 

We can now define a rest length for the three cases : 

Rest Length - 0 indicates the circumference of the circles stick together. 

Rest Length - 4/ random indicates that there is a line connecting the circles to show the connection but the distance can be randomly arrived at depending on the interaction of the user. 

Rest Length - no connection indicates that there is no lines connecting the circles. 

Using Rhino and Grasshopper to create the BD Algorithm

The first trial to create the BDA (bubble diagram algorithm) was in Rhino and grasshopper. To create a static bubble diagram with circles and lines is convenient using grasshopper and rhino. Even a statically drawn bubble diagram, gives the user the flexibility to change the size and the position of the bubbles at any point of time. Hence reworking is easy.

Below is one of the first trials of creating a basic bubble diagram. It is interesting to note that unlike most algorithms where you can loop to create repetitive patterns, in grasshopper looping works by breaking down components and extracting lists.

The points are drawn in Rhino and hence the points can be moved in the Rhino interface. See below how the bubble diagram can be manipulated in Rhino.

If you are wondering whether text can be added to the bubble diagram - the answer is yes. Text can be added and the size of the text can be changed too. The location of the text can be selected as well, but in this case I have been able to make the text sit only in the centre. I have also not been able to figure out how text can be wrapped in the circles.

The image below shows the addition of text in the bubble diagram.

So to brief it up and to list down the steps to arrive at this bubble diagram :

1 - Draw points in Rhino. These points are the centre of the circles that represents the bubbles of the bubble diagram.

2- In GH ( Grasshopper) assign these points to the points parameter.

3 - In case you want to criss cross lines between all the points  - duplicate the points parameter. Now both the points parameter contain all the points in Rhino.
Use the CrossRef parameter to plug in the points parameter and give the output geometry as a line.

4- To draw the circles, extract the end points of the lines. Collect all the output of start point and end point in a point parameter.

5- Use the CullN to cancel off repeated points and avoid drawing two circle from the same centre point.

6- Extract the list of the points using List Item parameter. Draw circles from the extracted list.

7-  Use the Boundary to create a plane from the circle. Which gives it the red colour.

8- Add the text Tags using  the Tags component.

Below is the image showing all the steps in the GH window.