How does grasshopper affect creative thinking when designing?

Grasshopper
1

Hello,

I’m a student in the UK and have been using grasshopper for a couple of months now. I’m doing a research project into using algorithms and scripting in the design process and what effect this has on creative thinking.

So firstly, what are people opinions on how creativity is affected when using a tool such as grasshopper to design?

Also, how do you tackle a design brief when using grasshopper? Do you have a fixed idea of the outcome before starting or does the algorithm dictate what it looks like?

Thanks to anyone who is able to help me with this!
Joe

2

Grasshopper is a gateway to algorithmic thinking. This is the point. It is like a efficient framework to solve creative problems because it is based on analyzing all the elements and relationships between elements that have the problem, to establish a cognitive environment with more restrictions (the fewer restrictions, the more difficult it is to create or find a solution), from top to bottom (from the whole to its parts) breaking down the problem into more treatable subproblems; or the other way around, from the bottom to the top (from the parts towards the whole) where step by step you build what is necessary to continue walking. I mean, creativity is a process too. Like life, cultural evolution or brewing coffee, are also processes. And algorithmic design or generative design is the art of processes, where the algorithm is the entity that gives skeletal stiffness to the amorphous bodies of ideas.

1 Like
3

In addition to @Dani_Abalde’s statements (which I agree with) I’d also say it makes computational design accessible. For certain types of design problem this was already possible through the medium of physical models, but that typically requires a lot of time, effort and skill, and oftentimes significant financial backing as well. The point of computational design is that if you have “a fixed idea of the outcome before starting”… you’re doing it wrong.

1 Like
4

It’s also faster to change. I think people often stay with their current design state, because changing things at the “bottom” would be too much work. Algorithmic design allows fast changes, even when your project is nearly finished.
You are also able to get fast many outputs by changing parameters (form etc) which can be compared. Would be much work if you do this in a model or something.
It can create complexe structures or forms, which people couldn’t handle. And also threw coincidences awesome stuff could be created.
In my opinion one of the biggest advantages is the possibility to fast changes.
And ofc, complex structures wouldn’t be possible to build without algorithmic design, but I think that’s not your Topic :smiley:

5

For me is a way to prove/disprove solutions, optimize intent, kill repetitive tasks.

1 Like
6

Grasshopper is a godsend for all the reasons stated above, but algorithmic design does have its pitfalls. In general, the specialties of any particular design software seems to predetermine the final outcome. The ease at which flowing surfaces could be finally be created with Rhino spawned a species of design that banished right angles and led to situations where a toothbrush, a sneaker and a concert hall all ended up having a strong family resemblance. In computational design, its all too easy to input an array of parameters into a black box, and “let 'er rip”. What emerges might be spectacular or awful but still requires a discerning eye to separate one from the other. And, since the outcome was, to some degree,unexpected, who takes final credit, the algorithm or the designer?

2 Likes
7

A different analogy might be comparing creating a piece of geometry with writing a computer program. When most people develop a program they first think about what the program’s end result should be, and then they start writing code. This requires knowing all the syntax, keywords, and procedure calls their programming language supports.

For many people a better way to develop software is to use a node based system like the MIT AppInventor. This approach eliminates the need for syntax awareness and allows the developer to focus on the objects involved (data sets, images, specifications, etc.) and the relationships between them.

Grasshopper is much like that I think. Before developing a GH script one has to think about and understand the various pieces of geometry required to produce the end result, and their relationships, but does not require the detailed awareness of the myriad menus, commands, mouse clicks, etc. that every sophisticated 3D modeling program employs. My sense is that his enables people to be far more productive than would otherwise be the case.

1 Like
8

“Creative thinking” may be a bit misleading in context of design. Creativity and thinking (in the analytical sense) are two different concepts.

Creativity is related to exploring what can be done with “what you have” (tools or proven concepts). Most people don’t “have” any software language syntax, but simple shapes with simple symbols or words are quick to pick up, and so then you “have” at least that. And GH is quick to rewire and you get immediate feedback. Creativity is about exploring and where the tools for trying new things isn’t stealing focus.

My grandma, born 1917 in Russia (in today’s Finland) was a programmer. Her syntax was plain Swedish when she wrote down her food recipes. But she used an incredibly complex crow-foot syntax when documenting her crochet recipes, a syntax which involved symbols as well. But these activities were essentially exploratory activities, which ended in specifications of her discoveries. Exploring and discovering and specifying it, is not what constitutes design.

Design (here is not meant graphical design but the general concept of designing things) consists mainly of analytical thinking and discernment. It’s about limiting and arranging an infinite number of thinkable ways to configure “what you have” (tools, resources and knowledge) in such a way that an end goal is reached. This process is deterministic in that it requires analytical thinking on order to find the better option of two possible (in achiveing that foreknown goal), or if you whish, sorting out the less fit option from the better fit options of reaching the design goal.

Design in the general sense (not limited to graphical design) is essentially based on foresight (about a goal, about an end) and intentionally planning for how to reach that goal.

It follows that exploring and designing this is NOT the same thing, although they are often performed “intertwined”. Most important is that the designer is not exploring when he’s designing.

However, (s)he may well have to spend time to explore what options there are to achive the fore-known goal, the end which exist in his foresight.

Notice that it is mainly the foresight, the goal known beforehand that differ design from exploring what or how to achieve that goal.

So, it is not a given that the final specific implementation of a solution was known in advance when starting what we use to call a “design project” (which often consists of more than the specific act of designing/thinking). But the goal, or the aim to solve a specific problem, or to find a specific form, or if the form is part of the exploratory stage, the implementation of the chosen form, is definitely the what constitutes the actual design part of the process.

So apart from the design part, the exploratory freedom to try and test different solutions which GH provides, leaves us with a special focus on flexibility, which in turn invites a playful approach, which in turn invites exploring new ways of solving end goals. The design part in any such process thus is the “thinking part”, or the part which involves “excluding that which does not lead in the direction of the fore-known goal”. The process of expluding sometimes makes exploring and design very tightly interwined, while one should keep in mind that “explore” is differenbt from design in that it may have the intent to find the Goal, while design still is about intentionally finding a Way to the fore-known goal.

GH provides with a greater “playful freedom” with nearly immediate feedback, which invites or allows for testing more and perhaps even different solutions that would not have been tried at all if it had been harder or taken longer to even try.

Or if switching the perspective: Limiting playful freedom, which is essentially the same as saying limiting the “search space” or the number of (possible) exploratory attempts, is a known problem in stochastic optimization methodolgies where it is known as increased probability to get stuck in “local optima”, meaning that there probably are more and possibly even better (opimal) options to be found if more options are being explored, where the absolute best thinkable solution would be called the “global optima”.

This is why the “exploratory stage”, often called being the creative stage, is so important before deciding on final design details.

But one of the least understood concepts among us is the concept of design. Design is essentially about planning and implementing a solution to some goal which, and it follows, is known in advance. This is true whether the goal consists of functionality or form. Every END which is “unknown” beforehand is not part of what is rightly called design.

Rules tends to have exceptions: If visual components is the ONLY tool which a person has learned for dealing with algorithms, then that is also his “syntax” which is at risk of LIMITING his thinking about his goal. Not all kinds of abstract thinking is “supported” by every set of symbols or symbolic language (I think we can come up with some arguments for not going back to Hieroglyphs, for example).

Words are different in this respect. Even mere thought often allows for a “broader exploratory search space” in problem solving than if constraining the analytic thought process with symbols.

But then again in some cases it is the other way around - expression languages doesn’t always “reveal” the potential search space that may exist in symbolic language or in the 3D space which symbols often allude to. Math is an example where the complexity of expression details may obscure solutions which are obvious if visualized graphically.

RELATIONS
One positive aspect of “visual language” that GrassHopper does NOT exploit in full is connections or relations between specified functionality. Messy wires (here meaning bent lines) does not hint as clearly about where they are leading as straight strictly ordered lines are. Therefore they are not giving immediate and clear overview of connectivity, or what KIND of relation exists between components. This is actually defying the basic idea of diagramming in general where relations play a major role.

If comparing GH with UML Object diagrams and Class diagrams for example, one of the most obvious differences are role names at the relation end points. Role names are special in that they cannot generally be limited to only one name on a component (names on ports), because a “role” is meaningful only in a unique relation and so should have a name relecting that unique role. But a prot name on a component is always the same.

If trying to “weigh” the significance of Role names vs Component names (resembles class names in UML class diagrams) I would ascribe Role names at least the same weight as the Component/Class names. The lack of role names is a weakness in GH.

If the “diagram” aspect of, well, a diagram, isn’t very clear to the explorer/designer, he will at times miss not only explicit meaning of relations, but at times also implicit meaning which is inherent in, not the relation alone and not the component alone, but in the structure of part or the whole of a diagram.

Richer and clearer meaning of relations is one benefit with diagram types with stricter layout features than GH.

In summary: A more flexible and simple (to pick up) symbolic language (which GH really is) which also provides immediate feedback when experimenting, invites and enables exploratory activities which may not have been tried if only more error prone coding och expression languages been available. This could be perceived as “widening the search space” for solutions, which in turn can lead to better (more optimal) final design. Immediate feedback on changes can also give a deeper understanding of algorithms and how parameters influence geometric form and specific design solutions, and so it serves well as a learning tool in the domain of geometric design.

// Rolf

Cusiosity:
Regarding the significance of relations in diagrams. Inherent in the structure of logical networks there may also occur something which I once dubbed “implogic”, which stands for “implied logic”. This means that the structure itself provides with added useful functionality and/or logic which arises “by implication” (because of chosing one specific structure to serve a functionalty instead of chsing another structure). I have seen this effect in UML diagrams, but never in GH diagrams.

2 Likes