Location: NEW YORK, NY, USA
Date: SPRING 2006
Client: COLUMBIA UNIVERSITY
Digital tools: MEL SCRIPT, MAYA
Credits:
Design/ fabrication/
Implementation
MARK BEARAK
Description:
This project was my first attempt to generate a building solely from an algorithm. The idea being that an algorithm, in this case a variation of cellular automata or the game of life, could create an undulating porous surface that could synthesize programmatic inputs. Over time the system would create order and reason based on a variety of factors that would eventually create scaled responses such as floors and walls. Each of the iterations worked sequentially; this took advantage of the fact that the script was generated using MEL script for Maya, an engine that utilizes a timeline. While each moment of the iteration as fleeting to the casual observer, a second script was cataloging the results and then testing them with the proposed program. Over time,
the cellular automata not only dictated the perforations in the skin, but also influenced the size and location of specific rooms. The final product shown was the direct result of the script, not a single surface was modeled. In the truest state, the digital process leads to the unknown. The result of this script was something all together new, but not necessarily surprising. I found that imputing contextual factors, such as program and site, coupled with the control over the could create something not only controlled but ultimately plausible.
Project 2: TOWER TRAJECTORY
Location: NEW YORK, NY, USA
Date: SPRING 2008
Client: COLUMBIA UNIVERSITY
Digital tools: VISUAL BASICS, RHINO
Credits:
Design/ fabrication /
Implementation
MARK BEARAK
Description:
The tower exercise is a literal example of distance based trajectories coupled with programmatic inputs. In this scenario 6 groups of 30 trajectories are taken over a fictitious undulating cylindrical surface. Each time one of the 6 groups would intersect with an adjacent group, both would switch trajectories.
This would also create the opportunity to build programmatic pockets within the 30 trajectories of each group. Thus an entire city could be built in the sky based on a few mathematical principals. The various versions of the tower were generated by allowing the script to randomly choose the starting point and the initial trajectory of each of the groups. While this created an amazing array of results it also pointed out the contradiction of using something purely random in architecture. Over time more and more of the resulting towers had to be thrown out due to programmatic impossibilities. Eventually the window of randomness had to evolve into something far more controlled and ordered. This was achieved by creating a secondary script that was testing the outcomes of a purely random initial state. The tower was generated using Visual Basics for Rhino which had the ability to handle thousands of compound curves. Using that power, the script was able to generate thousands of different tower options based on those curves. It would be impossible to sort and categorize each of these towers through traditional manners so I started evaluating the overall set by their level of fitness. A second script was written that would color code each bundle of curves based on certain levels of fitness such as how many potential pods were generated or the feasibility of the structure. Over time the script would whittle down the numerous towers to one ideal tower that was considered most fit based on the tangible inputs.
MARK BEARAK
Description:The tower exercise is a literal example of distance based trajectories coupled with programmatic inputs. In this scenario 6 groups of 30 trajectories are taken over a fictitious undulating cylindrical surface. Each time one of the 6 groups would intersect with an adjacent group, both would switch trajectories.
This would also create the opportunity to build programmatic pockets within the 30 trajectories of each group. Thus an entire city could be built in the sky based on a few mathematical principals. The various versions of the tower were generated by allowing the script to randomly choose the starting point and the initial trajectory of each of the groups. While this created an amazing array of results it also pointed out the contradiction of using something purely random in architecture. Over time more and more of the resulting towers had to be thrown out due to programmatic impossibilities. Eventually the window of randomness had to evolve into something far more controlled and ordered. This was achieved by creating a secondary script that was testing the outcomes of a purely random initial state. The tower was generated using Visual Basics for Rhino which had the ability to handle thousands of compound curves. Using that power, the script was able to generate thousands of different tower options based on those curves. It would be impossible to sort and categorize each of these towers through traditional manners so I started evaluating the overall set by their level of fitness. A second script was written that would color code each bundle of curves based on certain levels of fitness such as how many potential pods were generated or the feasibility of the structure. Over time the script would whittle down the numerous towers to one ideal tower that was considered most fit based on the tangible inputs.
No comments:
Post a Comment