A few months ago, Ben Sitler created a guide for making Grasshopper components where, tucked in the bottom, are instructions for viewing the Grasshopper source code. Download the .Net Reflector from RedGate, point it towards the Grasshopper dll, and there it all is. Dissecting Grasshopper like this is against section 3.2.1 of the Grasshopper terms of service, however just looking at the code is unlikely to draw attention, copying the code on the other-hand is both unethical and illegal.
It is fascinating to see the inner workings of production software. I was expecting it to be overflowing with elaborate geometric algorithms, graph theory and optimisations, these are definitely there but for the most part the code is user interface. This probably should not be surprising, the interface to Grasshopper is fairly sophisticated with many different buttons and controls, while the geometry is largely handled by Rhino. The dominance of interface in code seems to be true for many other projects, I used to sell small software plugins and was always amazed by how much time I would spend not writing plugins and instead packaging software, writing instructions and providing support. Adobe seems to face a similar phenomena, about 25 minutes into this talk about Photoshop at Google, the Adobe engineer mentions that the interface of Photoshop accounts for about 1/3 of the code base, surprising when you consider how simple the interface is relative to how complex the tools are. I think as a user the output of the software gets all the attention, however under the hood of production software are elaborate algorithms, not to generate the right output, but to help the user generate the right output.
Lately I have been very focused on the output of CAD software, and whether software engineering can teach us how to make better parametric models. I wonder if I have this the wrong way around, perhaps you need to start with the interface.
Edit 3rd of August, 2010: Removed the sentence that stated: “David Rutten, the developer of Grasshopper, has mentioned that decompiling code like this is often against the terms of service, but I can not deduce if it is against the Grasshopper terms of service – I think as long as you are just looking and not taking anything, it should be fine.” And replaced it with a sentence referring to the Grasshopper terms of service, thanks to David Rutten for clarifying this in the comment below.
This is part two of a series on advanced design strategies for Grasshopper definitions. Part one looked at using design patterns to structure definitions and this part will investigate ways to optimise Grasshopper definitions. While it is written for Grasshopper, the ideas are equally applicable to other parametric modelling tools.
Why and when to optimise Grasshopper
In general optimising Grasshopper is a waste of time; the optimisation will take longer than any time you gain from using it. You spend far longer constructing Grasshopper definitions compared to using them so I would favor any change that makes a definition optimally readable over a change that makes a definition computationally optimal. However, in certain cases computational optimisation may be justified, particularly when dealing with real time transformations of models. A little optimization might kick a definition from unusably sluggish to fluid.
In general optimisation should only occur once the definition is fully functional – to avoid optimising a part of the definition that is either not used in the final definition or optimising the wrong part. Once you have the fully functional definition, you can choose the correct part to optimise by measuring how long processes take using the Grasshopper profiling tool.
Profile is under the view menu, and draws little boxes under each node with the time it takes to calculate.
Despite its three-digit accuracy, the tool is only approximate, so do not take it as gospel. You will want to focus your optimisation efforts on the areas that are taking the longest time and therefore offer the most reward for optimising. The following is a list of ways to optimise your definition, starting with the most basic and working into the advanced stuff.
Break the model up / Use the place holder pattern
This one is pretty obvious but I have included it for completeness. The general idea is to break a large calculation into more manageable parts. One way to do this is to look for moments in the definition where the graph narrows to one node. For example you might have a function that gives generates the lines for a set of columns and these lines are then fed into a function that generates the columns. You could calculate the lines separately and then in another definition import the lines to generate the columns. Another way to do this is to right click a node and either disable the calculations or turn off the preview. Yet another way to do this is to use the place holder design pattern where you replace complex geometry with temporary and simple geometry. So you might replace columns with a simple pipe and once all the pipes are in the right place, draw the detailed model in place of this pipe.
Simplify curves
Simplify is under Curve>Util
Simplify curves rebuilds the curve with less control points. This can significantly increase the speed of calculations with these curves, and any objects derived from the curves – like lofts and pipes.
Don’t repeat yourself
Repeating yourself causes twice as much work writing out the two definitions, twice as much work editing the definition in two places and causes the computer twice as much work doing the calculations twice. If you need a value, calculate it in one place and link this into the places where the calculation is needed. This is said another way in the DRY principle: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” Your code will be faster to write, faster to edit and faster to calculate.
Work smarter
Above: original definition. Below: Using just the z component of the vector
Grasshopper encourages us to think about problems geometrically rather than computationally. Most of the time this is a good thing, but sometimes it can result in very inefficient code. A came across a great example of this the other week when a friend wanted to get the normals of a group of points on a surface and ensure the normals are always pointing upwards. For every point, he took the positive and negative normal, placed a point at the end and took the normal that put the point the furthest from the ground plane. This method is how we think about the problem geometrically, but is computationally slow because it involves creating points, projecting them and measuring distances. He asked me how to make it more efficient. I told him to take the normal for the point, check to see if the z-axis component is positive, if it is not then take the negative normal. This may not be an intuitive approach to the problem, but it is computationally efficient. Reconsidering a problem from a mathematical perspective can sometimes be rewarding.
Write your own functions
Writing your own functions can be very fickle, on some hardware configurations I have found rewriting Grasshopper nodes into C# or VB can greatly increase their execution time (sometimes as much as 10X). Other times it runs significantly slower. The following code finds the normal of the closest point on the surface. On my laptop this reduces the execution time from 400ms to about 100ms, however on my desktop it actually runs slower.
// Returns the normal of the surface at the closest point to the passed point.
private void RunScript(On3dPoint p, OnSurface s, ref object x, ref object y, ref object z)
{
double passS = 0;
double passT = 0;
s.GetClosestPoint(p, ref passS, ref passT);
RMA.OpenNURBS.On3dVector normal = s.NormalAt(passS, passT);
x = normal.x;
y = normal.y;
z = normal.z;
}
Write your own code
Grasshopper is pretty fast, but sometimes it just is not fast enough. You can either throw better hardware at the problem or better software at the problem. Writing your own C++/C#/VBA code can generate programs that run significantly faster than Grasshopper. The work done in Grasshopper is not lost though; it can act as a guide for structuring your new program, or as a specification to give a professional programmer.
This semester I have been teaching two papers at RMIT that have involved getting students up to speed with Grasshopper. There are already some excellent tutorials on how Grasshopper works – my favorite is Zubin M Khabazi’s Generative Grasshopper Tutorials – Lift Architects and Woo Jae also have some helpful advice. However, there seems to be little advice on avoiding a big balls of tangled Grasshopper spaghetti. So I am going to share some of my thoughts on how using design patterns can help avoid tangling yourself in Grasshopper bézier curves.
Why spaghetti is bad
Unfortunately not a joke
Spaghetti is the technical name for a tangled mess of code, sometimes called The Big Ball of Mud. Often when you are producing spaghetti everything will be fine, but when it comes to editing or reusing spaghetti things can be pretty painful. Spaghetti can make it almost impossible to understand what your code does because understanding it involves following the paths of all the wildly connected data-streams. It makes editing the code difficult because you do not know what removing a node does or how to reconnect the other nodes when you do. It can also make it hard to trace problems through the code. And you will never be able to merge two balls of spaghetti together. Gah.
Functions in Grasshopper
One of the most basic strategies for avoiding Spaghetti is to break your problem down into small tasks. This is pretty much how all programming languages manage code and this was even a feature in Grasshopper until it got mysteriously dropped (I am still hoping they dropped it because they are working on something better). You want to break the problem into distinct units of work, which can be described in a short sentence. For example, in the Copenhagen project, we were distributing wooden elements onto an elliptical surface. This can be broken down into four main tasks: generating the elliptical surface, placing points on the surface, placing the wooden elements on the points, and analysing the wooden elements.
Once you have your problem broken down, you should consider what data you need to perform each task and what data each task will return. So for generating an eliptical surface, the inputs to the task are: the center of the surface and the scale of the surface in the x, y, z space. The output of the task is a surface. I like to create a column of parameters for the inputs and a column for the outputs. This both helps explain what data your task is using and it makes it easy to reuse the function in the future.
Inputs and outputs all setup
Once all that is in place all that is left to do is fill in the steps to transform the inputs into the outputs.
Final function
There are some really big advantages to this method:
Your definition becomes easier to understand. Rather than trying to follow big long tangled links, you can see the main steps of the program. Then within each task, even if you do not fully understand what is going on inside the task, you can clearly see what data the task requires and what data it returns.
You can test a project in parts. Because every task is independent of the other tasks, you can easily put data into the inputs and verify the output of the task is correct. If something goes wrong with your model you can check each task is functioning, rather than trying to test the whole project at once.
It is easier to reuse your work. When you copy a task to a new location, because the inputs and outputs are explicitly defined and clearly labeled, all you need to do is reconnect these inputs and outputs to the right data sources. Similarly, it is easy to swap tasks in and out of the model when the inputs and outputs are defined. So if we decided we no longer wanted to use an elliptical surface because the elliptical surface has an explicit output node, we could just connect a free form surface to that node. No more trying to follow a curves through the definition to link them back up when something changes.
Design patterns in Grasshopper
Once you start designing with functions for a while, you will start to see common patterns occurring. In computer science, the patterns that form code are called design patterns. In a strange instance of progress folding back in on itself, design patterns are an idea that was originally taken by computer scientists from Christopher Alexander, and now we are borrowing these ideas back to help code architecture. Robert Woodbury, Robert Aish, and Axel Kilian developed a set of design patterns for parametric architecture, displayed in this excellent website. The patterns are for Generative Components but are applicable to Grasshopper. I personally find myself frequently using The Jig, The Controller, and The Place Holder.
I have just returned from the CITA workshop in Copenhagen. One of the problems we were tackling was how to distribute elements onto a unevenly doublely curved surface. I decided to explore whether the surface could be generated from elements of the same size. The most natural solution is to draw the elements in two dimensions and try to wrap the two dimensional surface onto the three dimensional shape. However the process of wrapping a two dimensional surface onto a three dimensional shape creates so much distortion that the original properties of the surface are lost: the elements become to long or too short. To me it feels like we hit the boundary of most CAD packages, which allow you to work in Cartesian space, and provide tools to wrap/embed Cartesian space into other spaces, but they are not set up to allow you to work in the original non-Cartesian space. For a while it seemed like the easiest solution would be to lazer cut the timber to fit the computer model rather than to correct the computer model. It is interesting to witness such a high-end workshop, full of nerds, struggling to overcome the limitations of CAD and in many ways giving the design over to the limitions of the software – or at-least designing within the vocabulary of the software.
The solution I came up with to this problem was to use a swarming algorithm on the surface (seen in the video above). By creating a number of random points on the surface, and then iteratively pushing these points away from each-other until they were the desired distance apart, it was possible to generate the surface from elements of the same size. I uploaded the code to do this onto openprocessing here. In the video above you will also notice that there is a Grasshopper model on the right. The processing code saves a text file of the elements and, in real time, Grasshopper turns this text file into a Rhino model that it analyses. Due to some of the code inside that model I can not release it, but you should be able to create your own version pretty fast using the Read File element in Grasshopper.
Another project from the workshop is Anders Deleuran’s exploration of the accuracy of lightweight simulation (video above). In this case he is simulating a reciprocal joint held with the bending of timber. Both of these projects were discussed by Mark Burry at the AD magazine’s 80th Birthday durring his lecture on ‘The future of architecture.’ The lectures were filmed but I have yet to find them online.
Just finished a tool to visualise directed graphs in processing. It uses the bezier curve & box combination from Grasshopper, but since the visualisation is not a development tool, the nodes the free to float into place. I created it to expose the underlying schema of a parametric tool we are developing but it could be modified to display any directed graph /& relational graph.
Prior to the 1980’s it was not obvious that computer simulation would drive architectural change. As Sherry Turkle explains in Simulation and its Discontents, this was a time of batch processing before the development of the immersive environment of computer simulation. Simulation and its Discontents follows the introduction of computer simulation at MIT, exposing the still present tension surrounding our understanding, control and seduction by simulation. Those early debates at MIT seem to foreshadow our current situation; a period where the two major events – the global financial crisis and global warming – exist in, and as a result of, simulation. A situation that was not obvious prior to the 1980’s.
Reading Simulation and its Discontents, the global financial crisis appears to be caused by economists “drunk with code.” A large part of the cause (although I am no economist, and even economists disagree on this) seems to be the ‘black-boxing’ of assets into mortgage backed securities. These securities are a way to collectively value to highly risky assets, however hidden inside them is assumptions regarding the default rate on mortgages. Architecture was black-boxed in a similar way during the introduction of simulation. Engineering equations were hidden behind on-screen buttons, which caused architects to worry that a generation of students would not understand the limitations of these calculations. They were probably correct to worry, and they should have certainly worried about the economists who had black-boxed assets to the point where they became so “complicated that the authorities could no longer calculate the risks” according to George Soros.
Complexity and black-boxing is not the whole story. The financial intuitions all had a big incentive to understand the simulation, even if it was hard, complex and obscured. The reason they did not understand the complexity is likely to be an equally complex story and some have even speculated the institutions understood the risks, but thought they were too big to fail. One reason not to follow up on the complexity is given in Simulation and its Discontents: “Simulation makes itself easy to love and difficult to doubt.” This is true if the simulation is returning pretty renders, but I imagine it is especially true if the simulation is making you billions. And by not doubting Turkle warns that “it can be hard to remember all that lies beyond simulation, or even acknowledge that everything is not captured in simulation.” Clearly much lay beyond the financial simulations, but they worked exceptionally well for a long time, making it hard not to be “drunk with code” on the success of these simulations.
The global financial crisis is more than a source of unemployment for architects. It should be a warning about our ambivalence towards simulation. That is not to say we should reject simulation, but rather we should, as Sherry Turkle has done, re-examine our relationship to, and dependence upon simulation. The concerns of architects at MIT in the 1980’s are still true today and the tension between understanding, control and seduction is present.
Recently I have been producing parametric models for Antoni Gaudí’s Sagrada Família; in Excel. When I agreed to use Excel to produce the models, I signed on certain I would fail, such was the unlikeliness of Excel succeeding in producing parametric architecture. While I cannot say much about the project, I should say that we were only using Excel for research purposes and that the design of the Sagrada Família remains one of the worlds most technologically advanced architectural projects. Using Excel drove me pretty close to the wall, particularly at 2am on a Friday as I got the model ready for a deadline and was trying to figure out a formula for a circle intersecting a plane in three dimensions. After two weeks on Excel I am not a convert, but I have begun to re-evaluate the worth of the more technologically advanced tools.
One of the curiosities of Excel is that cell relationships are hidden. A cell displays data and the only way to see relationships is to click on the data and view the formula. This is the inverse of graph based parametric modelling tools like Grasshopper and GC, which graphically represent the relationship between nodes but hide the data – in Grasshopper you need to hover over each node to see the enclosed data. Both approaches achieve a similar result, which got me thinking about why architects use the graph based approach while Excel still uses the spreadsheet based approach.
I am not the first person to consider this. In 1997, Spreadsheet 2000 competed against Excel with a graph based spreadsheet (shown above), which looks suspiciously similar to Grasshopper, complete with Bezier curves. Incredibly Spreadsheet 2000 was itself created with a graph based programming tool, Prograph, by Steve Wilson who went on to become the vice president of systems at Oracle, where he still probably maps out systems using graphs. This must have all seemed pretty advanced in 1997, it still looks advanced today, yet Spreadsheet 2000 failed before reaching the year 2000.
There does not seem to be any analysis on why Spreadsheet 2000 failed, so I am going to speculate: relationships don’t matter. The problem Spreadsheet 2000 was trying to solve was the invisibility of relationships in spreadsheets (Wilson talks about the aims of Spreadsheet 2000 here). The solution was to use a directed graph that exposed the relationships between cells. The graph is successful in doing this, although its verbosity makes it inefficient compared to a normal spreadsheet. For example the relationship between the top right table and the bottom middle table is inversion. Using a graph this takes up a significant amount of interface real-estate – two lines and an intermediate node depicting 1/x – it could have just as easily been communicated by adding a column to the top right data headed ‘Inverse’. The inefficiency of the graph increases with complexity since more nodes make it more difficult to interpret individual relationships from the spaghetti of code.
By exposing the relationships, Spreadsheet 2000 aimed to reduce errors. This is not the case. There is no correlation between knowing the relationships between cells and the number of errors. Stephen Powell’s “A Critical Review of the Literature on Spreadsheet Errors,” references a study where one group of participants were given a spreadsheet on paper so they could not see the cell relationships, another group were given an electronic copy so they could see the formula, and both groups identified a similar number of errors in the spreadsheet, 50%.* Anecdotally I agree with this; I have never stared at the Grasshopper graph and gone ‘there is my mistake,’ I do however see errors in the 3d model and then find myself working back through the graph, hovering over each node to see what the data inside looks like.
Spreadsheet 2000′s failure seems to be a common occurrence for visual programming paradigms. It is only in parametric architecture that I have really seen graph based tools like Grasshopper and GC become so widely adopted. I am unsure of why this is the case. After using Excel I feel there is still room to improve on these paradigms, particularly the emphasis they place on relationships, which are often only needed at the time of construction. Despite this, unless you are Gaudí, I wont be giving up my graph based representations again.
* Similar research has been done by the European Spreadsheet Risks Interest Group, a group that gives me considerable comfort knowing that someone is looking out for our accountants and the risks they face.
Shot in 1962, this video of Ivan Sutherland’s Sketchpad is almost 50 years old. It shows Sutherland (just 25 year old) demoing his PhD project, a project that wins him the Turner prize (the Nobel prize of computer science). The program is running on the TX-2 – the last computer in America ‘to have its own roof’ (see the TX2 instruction manuals). There are a number of remarkable things about sketchpad:
It is the first use of a Graphical User Interface and the first CAD program. Prior to Sketchpad computers were just switches, lights and punch cards.
It is the first use of Object Oriented code. This is a coding paradigm which forms the basis of many modern programming languages.
It is an early example of a program not running as a batch. In batch mode there is no interaction, you put in the inputs and it would give you the outputs, in 1962, being able to interact in real time with the computer is quite remarkable.
For me the most amazing part is the way Sutherland constrains the lines. I thought seeing this done recently in Digital Project (2009, $30,0000 per licence) was cool, but to see Sutherland select a series of lines on different angles and morph them until they are orthogonal is pretty mind blowing. Using todays computer it would still be non-trivial to get the lines to morph into the right place, much less do it in real time on a computer that requires its own room. This feature makes Sketchpad not only the first CAD program, but also the first parametric CAD program. I also think the way objects can be referenced into the drawing is cleaver, and even Digital Project struggles to make instances of object like Sketchpad does.
Graphemes is a spring based design tool developed by Sawapan. The interface – like the program – is unconventional, playful and esoteric. Steve Jobs would have a fit seeing something so non-standard running on an Apple computer, thankfully it only runs on Windows. Despite its unconventional nature, it is quite easy to grasp with a wee bit of playing, and judging by the videos you too can become a Graphemes ninja.
Essentially Graphemes allows the manipulation of a spring based topology that seeks equilibrium in real time. Analysis graphs can also be overlaid – showing bending moments and stress in the structure. Designing a spring based structure is probably of little utility (unless you are designing a space station) but what Graphemes hints at is a future where the design/analysis cycle has been compressed into a just a design cycle. This allows the parametric model to have a dynamic topology and embedded logic. An unconventional design paradigm wrapped in an equally unconventional interface.
Graphemes is free to download from the Sawapan website (click on Graphemes to the left).
I learnt to programme using Flash. Today Flash is a bloated monster of a programme that wants to be Illustrator, iMovie and xCode all at once (its downfall is worthy of another post). Even though I no longer use Flash, learning it was not a waste of time since once you learn one programming language, you know all of the programming languages. For this reason I recommend people start on a language that is easy to learn, like Processing, and pick up the rest later. There are programming languages built into most design programmes such as 3dsMax, Rhino and Vector Works. It has been my experience that these languages often do not have the documentation and instructions necessary to help someone new to programming.
Processing is a free download and is focused on artists who are new to programming. There are some great lessons provided and there are heaps more on the internet. Just like learning French, it helps to become immersed in the language rather than just flicking through tutorials, so jump into the deep-end with a project and learning will become far more meaningful. One resource I often use is OpenProcessing where people post their programs and you can see both the code and what the code does. These programs can be modified and adapted to your needs provided you attribute the original work. Three particularly architectural examples:
Sight analysis – finds areas of plans that would be most frequently seen.
Dynamic relaxation – mesh behaves like a membrane and takes on form with least stress.
Photovoltaic cell shaper – A bit ugly, but it is a tool to design the optimum photovoltaic cell based on location.
rss feed
