ALGORITHMICSKETCHBOOK ARCHITECTURE STUDIO AIR EDWARD KWAN-SHUEN YEE 699508
WEEK 1: SEEDING, GROWING, PRUNING
Grasshopper readily offers many tools and commands such as Delaunay Edges and Voronoi 3D to generate interesting shapes and patterns. In this week, explorations about how much control architects have over these ‘procedural form finding’ processes were conducted. I started off with three geometries that were modelled in Rhino and entered into Grasshopper:
ITERATION 1
Iteration 1: A fully capped contour model. Iteration 2: A rectangular box. Iteration 3: A curved wall following the golden ratio. Random point clouds were generated using the Populate Geometry command which were inputted Delaunay Edges and Voronoi 3D polysurfaces. Number sliders were connected to inputs Number of Points and Seed Numbers to adjust the geometries. Then, the most interesting geometries for each iteration were baked and ‘pruned’
ITERATION 2
ITERATION 3
Number of points: 50 Seed Number: 8
Number of points: 29 Seed Number: 15
Number of points: 50 Seed Number: 32
ITERATION 1 FINAL
ITERATION 2 FINAL
ITERATION 3 FINAL
Throughout the process, I realized that my control over the design were at two processes: 1) The number sliders influencing number of points and seed numbers, thus changing the algorithmic form generated, and 2) Manually deleting segments of the baked geometries. I found that the level of control I had with both design processes differed greatly with each iteration. Iteration 1 was where I had the most control in both. I had little control with sliding numbers to create interesting geometries for each segment in Iteration 2. The algorithm had more control over the geometries of each segment. With Iteration 3, I heavily relied on the algorithmic process to generate interesting triangulated lines that formed a spiral-like tunnel. This meant I barely did anything with pruning as the produced geometry from the first process was almost perfect.
ITERATION 1 FINAL PRUNED
ITERATION 2 FINAL PRUNED
ITERATION 3 FINAL PRUNED
WEEK 2: Parametric Shelther Breakdown In this week, I used individual base units to generate the three pavillions that are displayed on the right. Some of the questions that were asked: 1) How are your models different from outcomes that might come out of using other software programs? A: They can be easily edited and changed via their parameters at any point of the design process. 2) Do you prefer your pavilions ‘whole’ (ie. before you broke your smooth lofted surfaces down into discrete base units) or after? A: I preferred pavillion A to remani as a whole since the resulting morphed triangles were less desirable than expected. Part of this can be attributed to the unreliability of the algorithm which created strange morphed shapes when certain geometries and surfaces were too complex. For pavillion B and C, I feel that they produced interesting results once broken down into discrete units.
3) Did this process of breaking the pavilions into base units dramatically change their architectural language? A: I think that with Pavillion A and C, their architectural language remains largely unchanged. Both still represent some sort of surface that extends to form a shelter. Each individual element combine together to form the final shape. At most, it forms a facade for an existing pavillion structure. With Pavillion B, the feedback mechanism that influences the orientation and shape of the ‘lenses’ appear to be a new form. While the initial shape is still that of a shelter, the active movement of the lenses means the structure can take on more roles than just a shelter. It could form openings when people move near the edge or project images to a viewer wherever he/she goes.
PAVILLION A
BASE UNIT AND CROSS SECTION CURVES
CROSS SECTION CURVE PAVILLION B
PAVILLION C
DIVIDING SURFACE INTO CROSSSECTION CURVES
LOFTING AND BOX MORPH
DIVIDING CURVES INTO POINTS
APPLYING GEODESIC CURVES AND MOVE COMMAND
APPLYING BASE UNITS TO SURFACE
POPULATING POINTS WITH BASE UNIT
LOFTING CROSS-SECTION CURVES TO CREATE STRUCTURE
WEEK 3 & 4: Intro To Unity Our studio was finally introduced to Unity as the program upon which the game would be built on. First, tutorials were conducted to learn the basics of Unity, especially how to set up a playable character. I imported my pavillion into the game environment and played as a rolling ball. This was incredibly exciting for me because it was a form of architectural
INTRODUCTION TO THE PROGRAM AND IT’S COMPONENTS.
visualization except with an added benefit: interaction through moving within the environment. To me, it has the benefits of a video through an architecture except that the viewer/player now has the ability to move through the space with his own intent and narrative. This is especially effective in projects which the narrative is up to how the viewer perceives it to be.
THE PLAYER COMPONENT WHICH ALLOWS YOU TO CONTROL AND MOVE AN OBJECT VIA A 3RD PERSON VIEW.
IMPORTED PAVILLION FROM RHINO.
THE GAME’S 3RD PERSON PERSPECTIVE.
MOVING AROUND MOVES THE CAMERA ALONG WITH THE PLAYER OBJECT.
IMPORTED PAVILLION CAN HAVE AN OPTION TO ALLOW IT TO BECOME SOLID. THIS ALLOWS FOR INTERACTION BETWEEN THE PLAYER AND IMPORTED OBJECTS, IN THIS CASE, IT SIMPLY COLLIDES WITH THE PAVILLION.
THE CIRCLES WERE SUPPOSED TO BE TRANSPARENT IN RHINO. IT APPEARS TO HAVE RETAINED THIS TRANSPARENCY WHEN IMPORTED INTO UNITY.
WEEK 5: EXPLORING GROWTH TYPOLOGIES In this week, my group and I were tasked to research growth typologies. I looked into random diffusion algorithms and a simple ‘bomb explosion’ growth algorithm that was inpsired by plants.
Again, tying back to parameters being changeable at any point allowed me to generate many iterations within a short period of time. However, I felt that I needed to understand better how the algorithm functioned instead of just using it to generate cool looking results.
GRASSHOPPER DEFINITION WHICH WAS A VB SCRIPT
ITERATION AFTER RUNNING FOR 10 SECONDS
ITERATION AFTER RUNNING FOR 30 SECONDS
ITERATION AFTER RUNNING FOR 60 SECONDS
GRASSHOPPER DEFINITION OF SIMPLE BOMB EXPLOSION. PARAMETERS CHANGED WERE Z-COORDINATE AND ENDPOINTS TO GROW.
Z-HEIGHT = -7.9 END POINTS NUMBER = 53
Z-HEIGHT = 4.2 END POINTS NUMBER = 46
Z-HEIGHT = -3.8 END POINTS NUMBER = 26
Z-HEIGHT = 0.4 END POINTS NUMBER = 33
WEEK 6: KOCH FRACTAL GROWTH As I mentioned in the last week, I felt that I should understand the algorithm and hence I decided to look at the Koch snowflake as a precedent for writing my own algorithm. I used clusters and recursive definitions to generate a 3D pattern shape of the Koch snowflake. What i found extremely interesting was how linked mathematics with the concept of parametricism. The use of parameters and mathematical concept could potentially generate and create endless possibilities. However, it felt very sequential and logic and I wonder if the lack of emotive qualities in the process would be a good thing if we were to apply this to architecture in the context of site users and architectural space quality.
SELF WRITTEN GRASSHOPPER DEFINITION. USING CLUSTERS A
INITIAL BASE POLYGON
4TH RECURSIVE ITERATION
1ST RECURSIVE ITE
AND RECURSIVE DEFINITION TO GENERATE PATTERN.
ERATION
5TH RECURSIVE ITERATION
2ND RECURSIVE ITERATION
6TH RECURSIVE ITERATION
3RD RECURSIVE ITERATION
WEEK 7: CELLULAR AUTOMATA Our tutor suggested us to have a look at celullar automata as the logic and rules behind creating our system. Once again, I looked at Morphocode, a plugin for Grasshopper that had readily written cellular automata algorithms. Starting with 2D, I felt it was important to understand the various differences that could be explored throughout the process of cellular automata. I found myself noticing all the generated patterns and results that were created and I thought this was more of a outcomebased design thinking instead of a process-based design thinking. Again, parametric design (in this case, which would involve changing rules of cellular automata growth) should be a process oriented methodology.
MORPHOCODE 1D (2D) CELLULAR AUTOMATA
I then went on to the 3D algorithm of cellular automata which was essentially stacking each iteration on top of each other successively. This I felt was more architecturally linked as the 3D structures produced were spanning vastly and suggested a lot of architectural forms and spaces.
RULE 30
A GROWTH ALGORITHM
RULE 60
RULE 126
MORPHOCODE 3D CELLULAR AUTOMATA GROWTH WITH MEMORY ALGORITHM
R-PENTOMINO STARTING SHAPE
THE QUEEN BEE SHUTTLE STARTING SHAPE
DIE HARD STARTING SHAPE
GLIDER STARTING SHAPE
WEEK 8: CELLULAR AUTOMATA IN UNITY In this week, we were asked to change to exploring cellular automata using scripts in Unity. Given a code, we changed similar rules of cellular automata growth to create different results. My initial impression was that typing with script asked for a stronger understanding of how the logic works because you had to make sure you typed out the correct stuff. And, unlike the visuals of grasshopper, everything
DEATH RULE: <1 or >5 neighbours SURVIVE RULE: 2 neighbours BORN RULE: 2 neighbours
flowed in a rigid logic structure. I think this was good to make your processthinking more solid and less ambigious. However, I am not so sure if I liked it or not because of that lack of ambiguity. Unity also appears to be a little less visually representative of results compared to Grasshopper.
DEATH RULE: <2 or >5 neighbours SURVIVE RULE: 3 neighbours BORN RULE: 2 neighbours
DEATH RULE: <2 or >3 neighbours SURVIVE RULE: 3 neighbours BORN RULE: 2 neighbours
DEATH RULE: <2 or >8 neighbours SURVIVE RULE: 3 neighbours BORN RULE: 2 neighbours
DEATH RULE: <3 or >6 neighbours SURVIVE RULE: 4 neighbours BORN RULE: 3 neighbours
WEEK 9: LOCAL CA SYSTEM IN UNITY Having received feedback from our Part B presentation, we were advised to proceed into using Unity to continue our explorations and design the generative growth of the voxels in the park. We were given the working Unity file for the entire game and focussed on the part of the script that contained the CA growth. It was here where we were introduced to the concept of ‘inheritance’ and ‘resilience’. There were to be several different types of voxels that would be subjected to the CA rules and also could be subjected to rules that encourage interaction. I started looking at how I could mainpulate a certain type of voxel to interact with another voxel with the following rule/logic: ...ty project folder CA\Assets\Scripts\CustomExtensions.cs ThisVoxel.NextValue = cellVal; //NextCAvalues[x, z] = cellVal; if (neighbourSickness > 0) { ThisVoxel.sickness = ThisVoxel.sickness + 1; }
//PAPER SCISSCORS ROCK TEST // TYPE 1 LOOSES TO TYPE 2 // If this Voxel is TYPE 1 && it has a neighbour TYPE 2, make this voxel type 2 if (ThisVoxel.type == 1 && typeFreq[2] > 0) { ThisVoxel.type = 2; } /*if (ThisVoxel.type == 1 && typeFreq[4] > 0) { ThisVoxel.NextValue = ThisVoxel.NextValue + 40; }*/ /*else if (ThisVoxel.type == 1 && typeFreq[2] > 0) { ThisVoxel.NextValue = ThisVoxel.NextValue 20; }*/ //TYPE 1 looses to TYPE 2 /*if (ThisVoxel.type == 1 && typeFreq[2] > 0) { ThisVoxel.type = 2; } //TYPE 2 looses to TYPE 0 if (ThisVoxel.type == 2 && typeFreq[0] > 0) { ThisVoxel.type = 0; }*/ return ThisVoxel; }
// /////////////////////////////////////////////////////////////////// // REFCE03 Change the Y position // ///////////////////////////////////////////////////////////////////
3
A red voxel will turn blue if it has 1 blue neighbour. A voxel can have a value and having a certain number of neighbours can either increase or decrease this value. Based on this logic, I found out that coding could potentially create any kind of system rule or logic. On the other hand, a tool like Grasshopper is limited by the various components and functions that are available. It seems like scripts and coding have a huge potential in the design process.
...ty project folder CA\Assets\Scripts\CustomExtensions.cs }*/ /*if (ThisVoxel.type == 1 && typeFreq[2] != 0) { cellVal = ThisVoxel.NextValue 20; }*/ /*if (ThisVoxel.type == 2 && typeFreq[1] != 0) { cellVal = 100; }*/ //else if (ThisVoxel.type == 1 && typeFreq)
5
...ty project folder CA\Assets\Scripts\CustomExtensions.cs 4 //DEFAULT CASAMPLING // if the voxel is alive and stays alive public static int CAvalueSampling(this trimVoxel ThisVoxel,int[] typeFreq,int[] valueSum, int deathRate, int maxValue) { int cellVal = ThisVoxel.Value; int averageVal = cellVal; //everything in here happens when this voxel has neighbours of its same type if (typeFreq [ThisVoxel.type] != 0) { int chance = Random.Range (0, 4); if (chance > 0) { cellVal = valueSum [ThisVoxel.type]/typeFreq[ThisVoxel.type]; }
//type 2 voxels sink111 /*if (ThisVoxel.type == 2 && typeFreq [3] > 0) { cellVal = cellVal deathRate valueSum[3]; }
else { cellVal = valueSum [ThisVoxel.type]/typeFreq[ThisVoxel.type] deathRate /2; }
//if this voxel has more than 0 type two neighbours, this voxel sinks else if (typeFreq[2] != 0) { cellVal = valueSum [ThisVoxel.type]/typeFreq[ThisVoxel.type] deathRate; }*/ //add your conditions HERE /*
}
else if (your condition here) { your consequence here } */ //otherwise do this FAILSAFE, DON'T TOUCH else { cellVal = averageVal + Random.Range ( + 1); } }
/*if (ThisVoxel.type == 1 && typeFreq[2] != 0) { ThisVoxel.type = 2; }*/
deathRate / 2, deathRate
//if a cell has less than three neighbours, none of the same type, do this.. //decay by deathrate else { if (ThisVoxel.type == 3) { cellVal = (int)(cellVal deathRate * 0.5f); } else {
if (cellVal <= deathRate) { cellVal = deathRate; }
//dont touch if (averageVal <= deathRate) { cellVal = deathRate; } ////SPEND MOST OF YOUR TIME HERE! //if a cell has no neighbours of its same type, but has more than one neighbours, do these.... else if (typeFreq [ThisVoxel.type] > 1 && cellVal < maxValue) { if (ThisVoxel.type == 1 && typeFreq [2] != 0) { ThisVoxel.type = 2; } /*if (ThisVoxel.type == 1 && typeFreq [4] != 0) { ThisVoxel.NextValue = ThisVoxel.NextValue + 40;
RED VOXEL CONSUMES GREEN VOXEL. RULE IS IF GREEN VOXEL MORE THAN 1 RED VOXEL NEIGHBOUR, IT WILL TURN G
RED VOXEL WILL REDUCE GREEN VOXEL VALUE BY -20. WHEN GREEN VOXEL VALUE REACHES 0, IT DIES. COMPARED TO
YELLOW VOXEL INCREASES GREEN VOXEL VALUE BY +20. GREEN VOXEL EXHIBITS BEHAVIOUR OF BEING STRONG AND H
GREEN. RED VOXEL EXHIBITS BEHAVIOUR OF BEING THE DOMINATING VOXEL.
O PREVIOUS RULE, GREEN VOXEL EXHIBITS BEHAVIOUR OF SURVIVAL.
HEALTHY.
WEEK 10: GLOBAL CA SYSTEM IN UNITY This was basically an exploration around what effect would be generated if there was large number of randomly seeded shapes that have the CA rules and rules of inheritance applied. This would be described architecturally as a move from the micro scale to the macro scale.
25 SECONDS RUNNING ITERATION
Current rules generate a red voxel dominant environment over the thousands of iteration of each CA rules. I think the rules can be further tweaked to explore other resulting patterns.
STARTING ITERATION
55 SECONDS RUNNING ITERATION
5 SECONDS RUNNING ITERATION
75 SECONDS RUNNING ITERATION
15 SECONDS RUNNING ITERATION
90 SECONDS RUNNING ITERATION
WEEK 11 & 12: FURTHER REFINEMENT In the last two weeks, we received scripts that were much more refined. The previous script applied default or modified CA rules to all types of voxels at once. This one us to change individual voxel type CA rules. Also, the inheritance rules were refined to allow more complex relationships without generating any code errors. Code errors appear to be a major technical problem in designing with this tool. It slows down productivity
and I found myself getting too distracted by trying to fix the code many times as compared to critically thinking about how the process and outcome of designing with code. Nevertheless, interesting outcomes were created on the macro/global scale which proved sufficient enough to be implemented into the final game.
VEGETATION VOXELS CONSUME FLOOD VOXELS.
POLLUTION VOXELS CONSUME VEGETATION VOXELS. SITE USERS VOXELS CONSUME VEGETATION VOXELS.
NOTHING CONSUMES POLLUTION VOXELS.
VEGETATION VOXELS CONSUME SUNLIGHT VOXELS. SITE USER VOXELS CONSUME SUNLIGHT VOXELS. POLLUTION VOXELS CONSUME SUNLIGHT VOXELS.
POLLUTION VOXELS CONSUME SITE USER VOXELS.
In these iterations, the rulesets that were introduced were: 1) Pollution eats vegetation 2) Pollution eats sunlight 3) Vegetation eats sunlight 4) Site users eat vegetation The resulting interaction shows the vegetation voxel dying too fast while pollution remained as the dominating victor. Only site user voxels survive against pollutionâ&#x20AC;&#x2122;s rampage.
In these iterations, the rulesets that were introduced were: 1) Pollution eats vegetation 2) Pollution eats sunlight 3) Vegetation eats sunlight 4) Site users eat vegetation 5) Sunlight eats pollution The resulting interaction shows a very balanced system with sunlight and pollution battling it out with each other equally. This is classified a stable system.
In these iterations, the rulesets that were introduced were: 1) Pollution eats vegetation 2) Pollution eats sunlight 3) Vegetation eats sunlight 4) Site users eat vegetation 5) Sunlight eats pollution 6) Site users eat sunlight The resulting interaction is vegetation voxels completely die out and site users battle it out with sunlight equally. This would a somewhat unstable system..
In these iterations, the rulesets that were introduced were: 1) Pollution eats vegetation 2) Pollution eats sunlight 3) Vegetation eats sunlight 4) Site users eat vegetation 5) Sunlight eats pollution 6) Site users eat sunlight 7) Pollution eats site users The resulting interaction is a system where pollution completely obliterates all other voxels. This is the most unstable system yet.