Project-equation

The creation of a digital model that communicates a generative design 

system in a rural environment with a  client using  Rhino.

Projects

Video-Sessions

Project-Equation Discussion

8 Responses to 02.03

  1. Peter Edward Atwood says:

    Although 02.03’s project equation has already been determined through elimination we should continue our discussion regarding the values. Specifically I think the concept of generative design has provoked some very interesting conversation so far on the role of technology and the computer in design. Additionally we have also talked a little bit about who it is we are communicating with whether it be a community, a contractor or in this case a client, but we should more specifically talk about how we use these tools to communicate an idea, or what are the implications of using these tools to communicate ideas. Is it important that the client understand the system at work?

  2. matthewmoeckel says:

    Not sure I have really rapped my head around the idea of generative design…
    So this may or may not make scenes…So I’m going to start talking this out. I looked back at the word study. Two main words that stand out to me is originate and also produce… I guess there are three, change and along the way (adapting)…
    I realize now that there’s good reason I could not fully comprehend this. It has to do with the nature of the generative… It has the ability to change and adapt as need for the problem throughout the process.
    After I use rhino GH it will better help me understand generative… As for the tools, I think the computer can be great tool, if the operator knows how to use the tool thus being the computer programs and from this the communication will be reveal its self… I believe to communicate something the operator has to have control of whatever he is trying to communicate so start first with the program and goes out from there. I think it will help the client understand what you are trying to communicate with them if they would have an overview of the program and its purpose… other than that I don’t think the client needs to know anything about the program/software being used… really they don’t even need to know the software if the person communicating takes that into account and used something to communicate the desired info to be shared…

  3. Matthew Dunham says:

    To respond to Peter’s posed question “is it important that the client understand the system at work?” In short, the system not the program or software I think is important to communicate. I want to reflect on two encounters I had previously. I remember about four years ago I took a personal trip with some friends to Chicago and before we got there I contacted SOM to see if we could arrange a tour. On the tour one of the female-architects made a comment about how the majority of SOMs work, regardless of the stage of the project always looks as though it could be built. Even if it was only a preliminary idea sketch. She said it was the way they win a lot of their projects. I heard another architect say several years before that the importance of keeping preliminary drawings and ideas to simple mediums such as hand sketching and basic programs, shows the client that further exploration and changes can be made and that the ideas were not a done deal.

    While I don’t believe the systems at work or specific software has to be communicated, I do think the choice of tools should be communicated and why they were chosen. The idea that the designer should communicate to the client that while the animation or render looks pristine and complete, it is just a delivery method and still only an idea. Basically that great renders and hand-sketching are still the same thing just different tools. One gives the illusion of completeness or the other does the illusion of simplicity and perhaps undeveloped.

    Then I believe there is a time to use high-quality, photo realistic, computer aided design tools to deliver precisely that: a complete, realistic demonstration of the idea. Clients want to be, and are, involved in the process. But as professionals there are elements they need to know about and elements that do not pertain to them.

  4. Matt Hoefler says:

    Now that we have the remaining list values we can see what we have left over from the lists. Most importantly is that we choose this values in the last project by not picking them, so we really created two different sets of values that can both lead to interesting ideas and projects

    As for the values chosen for this particular project I feel as if these values work together just like the other values in the other projects.
    I’m under the same understanding as Matt M on the generative value, I guess I’m not really sure what in entails either. I think generative means to produce something, however with any drawing or model we are producing something. So maybe generative is more about producing an effective result by means of design. Maybe we can create based on generation of a solution.

    Rural Locations lend themselves well to a wide spread type of creation – maybe like the farm fields in Fargo. Typically all projects will have a specific client or “owner” which will help navigate to the solution, in this case we can assume that the owner or client is up to interpretation.

    As For Rhino – I have only very briefly looked at rhino but I’m excited to see the opportunities in learning this new program!

  5. Peter Edward Atwood says:

    I agree that the term”generative” is perhaps the most enigmatic in the value list. Moeckle’s suggestion that generative has something to do with the ability to change and adapt could be used as a possible definition or distinguishing aspect of a generative system. Let us consider the alternative then, a system that does not have the ability to change and adapt. What does this look like? Perhaps it is a system with an input and a result and nothing in between, however I still have a difficult time comprehending such a system. Or perhaps it is a system which only ever has one predictable outcome. I find this interesting for there is no need for the system once it has been executed unless your desire was to continue producing the exact same thing over and over again. From this I might suggest that generative could be defined by the system itself being worth more then the result of the system. I think this line of thinking perhaps blends itself with our conversation concerning whether or not the client should understand the system or whether or not their knowledge of it is important. If we take generative as meaning the system is more important than the result then the client should understand what the system is since it is more important. An example of this could be when a client specifically states that a project must be design in Revit so they can have a BIM model of their building when it is done. Is the client more interested in the BIM model then their building? Could Rhino/Grasshopper some day occupy this same mentality. Would a client ever demand the use of rhino/Grasshopper like they might do for Revit?

    Two additional comments to push this discussion forward. Firstly Dunham makes a great point regarding the finished quality of architectural productions and its effect on the client. I agree that clients react very differently to a digital rendering then they do a hand sketch and that each of these is used selectively by the architect, yet would their be a time when the architect would want to show the client a Grasshopper map of the parameters they have developed?

    Secondly Hoefler said something very interesting. Generative is not only the production of something but rather the project by “means of design”. Perhaps here we could suggest that showing a client the system or software is important because it is the proof that it was by “means of design”. I am not sure that a software application can be used as proof of design however it is an interesting thing to consider.

  6. matthewmoeckel says:

    Peter, This idea of the software and the means of design, is interesting to me. I ask this question in an email to you Peter, but think it apples here now too. Is there one ways we should be learning these software programs for design? is there difference from just learning the program? Does this mean if we learn the program anyway possible that we are a designer now? Because it’s a design program?

    Peter, when looking at the way you have now define the generative system. I believe it would be very important for the client to understand this system. Because now it is what you are offering. The system is in its self now the final out come… So this maybe opening me to new train of thought in the way I see architecture being marketed.

    What are architects really offering the client? A building Final project that can not be changed or could it be a system… and the system defining its self as the architect? Therefore allowing the building to change as needed and or design… Are there other things that could be defined as the system and the work accomplished still be defined as architecture?

  7. Matthew Dunham says:

    There is a lot of great things on here I really want to comment about. Peter asked “yet would their be a time when the architect would want to show the client a Grasshopper map of the parameters they have developed?” I think depending on the client absolutely!! There are such complex projects being done around the world today that the parameters though software, while they may overwhelm the client, they support the evidence of sound research. studies and research that guarantee the design team has studied the projects/movements/details at hand. Just as we run wind and solar studies on more complete design phase ideas: we can show clients the parameters which will dictate the building outcome/model even before there is a building.

    I am most interested in this comment by Peter “If we take generative as meaning the system is more important than the result…”. I did a thesis about the Kinetic Morphology of Performance Space, which was a 2.1 million square foot athletic and performing arts stadium. It was all about the kinetics on the inside. Talking a stadium searing 55,000 people and sub-dividing it through automation into 10 separate theaters and concert halls each customizable. A year ago I had a vision for the exterior envelope and after hundreds of iterations in the fall I went back to the simple facade I had initially thought of. It was not about the facade it was about the function of the building… the system inside the facility was far more valuable and needed to be far more functional than any other detail. I came to the conclusion that the prototype building (thesis) was the kinetics not the visual client driven “look”. The concourses, lobbies and exterior (site) could change from anywhere around the world and look like a bunker or a Zaha Hadid project: what I was more about was the system on the inside than the final product “image”.

    Last, Moeckel poses a slew of questions about software. I think what comes to mind right away when asked if there is a way we should be learning these programs is how my brain thinks. I am creative but when it comes to buildings I think very systematically and very function over form. So to explore and let loose with the software is unlike my personality. But I feel like that is the end goal to combine this parametric world with art. Moeckel goes on to say as long as we [as software users] know the programs we therefore must be designers. If A therefore B. If not A not B. I think every tool in the chest is important to be a designer from free hand drawing to spreadsheets and everything in between. Each software program allows us to view our design/creation through a new lens which intern allows us to understand it more. However we learn these programs it helps us see the world differently.

  8. Matt Hoefler says:

    Parameters offer architects a way to express their designs thru systematic equations and thus creates a design. Using parameters in this grasshopper environment I found that these equations can get very complex very quickly and may look confusing even to the person creating the file. Its important to keep a very clean working environment – I was constantly moving the panels around to arrange in a way I could see functional.

    Looking at Peters comments on how an architect could/ should show parameters to a clients, I think that its important to remember that these parameters can be somewhat confusing so there would definitely need to be some educational moments in that meeting. Using the idea of inputs and outputs seemed very different to me at first, however I noticed later that we use inputs and outputs all the time in any design software. Grasshopper uses specific commands to create shapes, AutoCAD and Revit do the same, however in both of these programs that inputs/outputs are very literal and happen instantly by your commands. Its very interesting to create a command or input in grasshopper and watch it create something in your Rhino environment. I really enjoyed creating arcs and bi-arcs and seeing what interesting shape comes from the inputs – its really addicting after a while!

    Most people will have a different way of creating and learning using any software program, because there is usually more than one way to learn something. I found this especially true when using Rhino and Grasshopper, although it seems as if there are endless ways of creating shapes.