LAX refuge, pt01

sound energy:

sound from around the site, primarily from airplanes and vehicle traffic, produce energy flows that are captured by machines acting on the parking garage decks. the machines use this energy to carve into the floorplates as well as lay concrete down for floorplate expansion. two datum are established to establish a minimum and maximum floorplate dimension. the time in which these floorplates move from minimum to maximum, a deflection of 30-40 feet, is on the order of months to years, depending on the available energy during that period. as soon as a datum is reached, the machine performs an opposing action (from carving out/grinding to pouring concrete). as sound energy is being absorbed for work, the formal behavior of the collective machine resembles an oscillating wave.


a simple GC model demonstrates this action.

multiple sound energy sources will influence this behavior, thus multiple wave propogations will be evident in the overall form. interferences will also occur as these waves meet to produce variable results.

research directions:

reacting facade GC model

Hans Jenny - Cymatics
Resonance tests (video)

importing gc models into gc models

to import a gc file (such as the sun path model into the lax_site model), first consolidate the transactions of the sun path model (highlight all the transactions and right-click for the menu). this will collapse all the transactions of the model into one script. go to the script editor and copy all the text.

next, go to the lax_site model and after the very last transaction make a new model-based transaction. edit this transaction (it is currently empty) and paste the script from the consolidated sun_path model. this will include all the graph variables from the sun_path model.

LAX site GC model

Here's the parking garage in it's current state.

GC Sun Path Model

a sun path model, made in gc.


the controls are: latitude (degrees), date (1-365) , and time (0-24). at the moment, the time variable is a series from 5am to 8pm, which produces the arc. you can change it to a single time to view the specific position of the sun at that time.

download the gc file here.

final transition|interval stab

using the last two models as foundations, here is the final model for the exercise.

GC file is here, with the instantiated feature defined here.

(to find the .dll file, in GC click on 'tools' -> 'manage loaded feature types' -> click on 'select pre-compiled assembly file'. in the window select your feature (in my case it's called GC.scale_03.dll) and COPY it to your desktop to upload later. to search for this file you have to go through a few hidden folders, which is kind of a pain.)



physical model made of bristol paper, mylar, and 2-ply chipboard.

transition|interval stab02

now working with a surface, the idea is to control the angle of a series of fins along a surface. i created a second surface above the fins to control their angle via T values along each polygon. the angle of the fin is determined by the volume of space in each specific section.

the next version of this will be to instantiate a shape onto the polygon surface. the goal will be to create a shape that informs its neighboring cells as well as rotate with the spine of the volume, much like the scales of a fish or snake.

physical model:

transition|interval stab01

from the gate the plane fuselage, the transitions observed are three fold: one is of volume, another of organization, and lastly of speed. at the gate people are occupying a large space, scattered in various positions, and relative to the ground they are nearly motionless. upon takeoff in the plane, people are occupying a vastly smaller volume of space, sitting in tightly supervised columns and rows, and flying at high speeds.

my first attempt was to simulate the elements (people) moving from a chaotic, unorganized state to one that has some observable degree of order.

this really didn't lend to any form finding technique, so it was abandoned as a scheme.

had it not been so late, i would like to have developed a scheme to 'randomize' the bottom elements (gate condition) to juxtapose the order seen at the top (plane/takeoff condition).

the first stab doesn't seem to represent these idea very well, though hints of speed and volume are observed. after creating this, i wonder if generating a surface condition is more beneficial than what seems to be an object.




my left leg for an undo button, for the love of god.

swarming killa bees

the goal here was to simulate the reaction of a group of bees when a hornet is introduced, as in thermo-balling introduced in a previous post. the desired effect was for the bees to be attracted to the hornet (moving their position on the grid) and also to collapse their wings.

a few shots of tinkering with position functions. it seems that the bees (yellow dots) are swarming around the hornet (point symbol), but what was unexpected was that they actually follow the hornet when it leaves the area.


i don't really know why this happens, but it turns out the function i wrote didn't make sense. so i changed it.


now the reaction makes sense.


building a skeleton for the actual bee head and wings.


i tried creating the left wing and something went wrong. the result was unexpected.


getting there. there are a few outliers where a bee's wing is significantly collapsed but it's position isn't very close. the swarming effect isn't as accelerated as i wanted, but increasing the power of the position function didn't resolve it either. ultimately i'd like to set a radius (or even sphere) of influence for the hornet, such that any bee within that radius is strongly drawn to the hornet.


i couldn't figure out how to write a function for the wing rotation based on the distance between a particular bee and the hornet, so i based the wing geometry on a triangle. the length of the bottom leg of the triangle was based on this distance.

gc_pyramid

Generative Components ex01