Grasshopper "Good Practice"
Introduction
Expected Time: 30 min
The following section provides an outline of "good practice" habits when managing your files in Grasshopper. If your model is not constructed according to these instructions, your instructors are not obliged to help you on your files. By maintaining this logic across the student body, files will become easily understandable for instructors, but also exchangeable between fellow students, resulting in a rapidly expanding knowledge.
"While poorly written code is often manageable, a poorly organized Grasshopper document can be absolute hell." -Alexander on Grasshopper Forum
Systemic Setup
Make a systemic setup by clearly identifying systems consisting of inputs, processes and outputs. A system is an abstract notion of a group of things that work together like the machines of a production line. Therefore it might be useful to think of your model as a production line with machines that can be altered or substituted at any moment without disrupting the entire production line.
Use Pseudo Code
Before jumping into Grasshopper, it is important to have a step by step logic of what you want to do and a clear idea of how you are going to do it. This is also known as pseudo-code. In Informatics, pseudo-code is an informal description of the operating principle of a computer program or other algorithm that uses the structural conventions of a normal programming language. It is intended for human reading rather than machine reading.
Be Systematic/Methodical
The Grasshopper file should be structured according to a systematic procedure. Think of your whole process as a method to produce something of certain quality levels. Ideally, the method should be re-applicable to generate various instances of the same product. Refer back to your description (pseudo-code) of the process and organize your file according to those steps.
Organize your Model
Inputs and Outputs
In a parametric definition, input consists of a series of geometries and parameters located on the left, which enter a process consisting of a set of operations which generates output data or geometry, located on the right. Outputs of one process might then become new inputs for the following process.
Organize inputs and outputs for each process and do the same before connecting them to the next process (see image on the right). Collect all Design and Referenced Geometry in one place, typically in the top left hand corner to allow a user to only have to focus on one part of the canvas when making changes.
Referenced Geomometry
Referenced Geometry is the geometry that is defined in Rhino and important into Grasshopper by using Set Geometry options. These can be either points, curves, surfaces, breps, boxes, meshes, groups, etc. Geometry can be defined in Rhino as well in Grasshopper. This difference will dictate the possibility of changing the geometry later in Rhino and not only in Grasshopper. This will influence the design process and the capacity to effectively altering your design geometry. If the content of the parameters is defined in Grasshopper, the options of modifying the geometry in Rhino itself will be lost. If however the content of the parameter is based on Rhino geometry the geometry can be altered in Rhino resulting in a modification of the whole Grasshopper geometry. Clearly label Referenced Geometry.
Design Variables and Parameters
Design Variables, or sometimes referred to as User Defined Variables, are those parameters that are crucial to the concept definition of the design. Often those parameters contain numerical inputs that are allowed to change during the design (and/or optimization). A parameter is a symbolic name often associated with a numerical value and which may be changed. Not all parameters are Design Variables but all Design Variables are parameters. Parameters could be constant. If this is the case, do not use sliders to define their values, but Set Numbers instead. Clearly label Design Variables.
Extract Parameters
Do not plug Design Variables directly into components, but use paramater containers to clearly identify them. To extract a parameter, right-click the parameter and select Extract Parameter. A new parameter container appears. Depending on the type of parameter you are extracting, this usually is either an integer, or number but can also be text, a boolean, domains, matrices, etc. These parameter containers can be found in
Groups and Clusters
All the relevant components are grouped together under a meaningful title. These modules can be turned into Clusters and eventually User Components for use in other definitions. The outputs of the Groups or Clusters are always labeled with "text" with a meaningful name. Also Clusters and User Components can be labeled.
For more information about clusters, take a look at the Tutorial Clusters and Hops.
Consistent Wire Types
Use Hidden Wires when passing Design Variables around the canvas and Faint when passing Objects/Results from one module to another. Copy frequently used Design Variables to the locations on the canvas where they will be used again and connect them with Hidden wires. This way your files will not turn into a spaghetti-like mess.
You can replace a single item wire, list of items wire or data tree wire by a faint of hidden wire. Make sure the user can always track where the wire comes from.
Save States
You can save the state of a definition with option from the upper menu bar. It allows you to save the current combination of parameters so you can restore previous settings and alternate between different setups with out having to remember specifics. This is very useful when showing various design alternatives.
Crediting Authors
Since Grasshopper is a relatively new tool, academic standards have not yet fully been defined and plagiarism of Grasshopper definitions occurs frequently. As is the case for academic writing, to claim someone else's work as your own is plagiarism and therefore in violation with the TU Delft Code of Ethics. To avoid this, we insist that you credit the authors for parts of your Grasshopper definitions you did not make.
Grasshopper Forum
Grasshopper is supported with a Forum that uses an open-platform ideology which means that many definitions are used and shared across the world. The forum can be a useful way to solve technical problems with your Grasshopper definitions. When you ask questions and/or upload definitions, usually somebody responds and offers help. If somebody on the forum fixed a part of your definition, you need to identify the portion of the definition which the person altered, credit the author and list the date when this occured.
Plugins and User Components
Accross the forum and on personal blogs or webpages, you will find many plug-ins and/or user components. These are either clusters or scripts (VB, Python, or C#) made by individuals who deserve credit when you are using them. List the author, the URL where you've retrieved them from and list the date when this occured.
Instructors
When you are taking a course in handdrawing, you do not turn in the sketches made by your instructor while he was explaining. This also holds true for the Grasshopper definitions made by your instructors, even during the workshops/seminars. It is crucial that you credit your instructors for the parts of your definition they wrote. List the instructor and the date when this occured.
How to Credit Authors
For TU Delft purposes, we define a standard method for crediting authors. If you fail to comply with this and your instructors notice that you are using definitions that are not your own, you will be subject to further examining.
Following the example in the image on the right, group the part of the definition (or user component) and define the group color as white. Underneath you will place panel (also colored white) that outlines all necessary information.
Phase Model
To help you create a systemic setup, it is highly recommended you make use of a phase model. A phase-model illustrates a time-based description of a process and all the contributors and their relations in terms of the information exchanged and the order of operations. Each phase develops in complexity as the relations between contributors become more interdependent. It should help you to hierarchically structure your decision process.
Flow Chart
A flowchart is a conventional graphical representation of a computational design process in relation to its sequence of functions and the data transferred between those functions. A flowchart is constantly revised as the computational workflow also changes.
Flow Chart Symbols
Please use the following symbols to represent your computational process.
- Start/End: an oval represents a start or end point
- Data: a parallelogram represents input or output
- Decision: a diamond indicates a decision
- Process: a rectangle represents a process
- Connectors: A line is a connector that shows relationships between the representative shapes and the sequential order of the decision making process
Example of a flowchart as made for a TU Delft course
This is a simple representation of the functional steps you have to make to get the network you need for your task. It can be even more simple then this example.
