Welcome to the home for Digital Research 2013

Here you will be asked to post a screenshot as well as an approximately 400 word description of the criteria or parameters that you implemented in your use of this weeks precedent study.

Here is the schedule for the semester, including the student responsible for moderating the discussion:

Performative
8/20- Shanghai Tower- Beorkrem
8/27- Versioning- Steven Danilowicz
9/3- Adaptive Components- Dylan davis
9/10- Material Constraints- Christian Sjoberg
9/17- Programmatic Constraints- Neil Edwards

Generative
9/24- Aesthetic- Trevor Hess
10/1- Biomimicry- Ben Sullivan
10/8- NO CLASS- Fall Break

Interactive Design
10/15- Smart Objects- Lina Lee
10/22- Smart interfaces- Isabel Fee

Data Visualization
10/29- Emotive Expression- Chris Pockette
11/5- Physical Expression-
11/12- Daylighting-
11/19- Final Project begins
11/26
12/3

Monday, September 2, 2013

Versioning - Shape Grammars


Rather than spend my post talking about the significance of each component in the shape grammar script, I’d like to talk about the implementation of a more thorough shape grammar script in Grasshopper.



Unlike most scripting languages, that must be programmed in text, Grasshopper is interesting because it allows you to see and create scripts quickly. It suffers, however, in that flow control, and loops are hard to do in a node-based scripting language (as opposed to text-based programming languages). Thus, much of the data manipulation occurs in lists, and you must have a clear understanding of the goal of the script before you start. The shape grammar script that we worked on in class is a prime example of this. While most of use jittered the point list, the way that we should have composed the script was by jittering the list of shapes. Compared to other programming languages, the list in Grasshopper, acts like a list in python. But, the data structure that we really need to solve the problem identifying the stare modules [in python] is a dictionary. This would allow us to tag each Brep in the list as a specific type of module, like stair, column, floor, room, etc. From there we could just specify the indices each stair module on the first floor, and delete those from the second floor.




But that’s not to say that it is impossible. Rather, the repeated list of breps should have jittered, instead of the list of points. Thankfully, the jitter also allows you to look at the indices of the shuffled list so that you can see what the original position of each item in the shuffle list. Since our original list of breps was 4 components long, we know that a stair component occurs every 4 items. Thus, by taking the list of original indices, and doing some mathematical filtering (i % 4) we can make each stair component in the list 0 (shown below). Using an equality filter this turns into a True-False list that can be used as a cull pattern. Deleting components above a stair module on the first floor is a simple matter of using this cull pattern to filter the second floor list of movement vectors, and breps.


No comments:

Post a Comment