Grasshopper Development
We can build, fix or enhance existing Grasshopper graphs and train you to use them.
Grasshopper is the Visual Scripting interface for Rhino. It truly is the lingua franca of Computational Design. For those of us who dont speak Italian, that means it is the main language that we communicate in. Although it began its life as one of many Rhino plugins, Grasshopper has become more important than Rhino itself, to the point where we now see Grasshopper users who lack basic Rhino skills. The vast array of plugins available make it the tool of choice for anyone looking to splice together Off the Shelf components into a coherent workflow. But there is now so much available that keeping track of these plugins, and sorting out the gems from the rocks has become a task in itself. Over the years, I have developed many Grasshopper scripts for Architects, Civil Engineers and Urban Planners, always through C# custom components.
Technicians who cannot code or choose to build no code solutions will only ever be able to develop basic workflows because of the limitations of logic in this methodology. This is really inefficient to produce, often taking far longer than simply coding it up. AI may make it easier to get assistance with writing the code, but it is not a silver bullet. While AI can be assigned a small specific task, you still need competent code literate people to crosscheck the outputs to avoid slop, and coordinate how it integrates with the bigger picture.
The best thing about Grasshopper is the ability to connect these Off the Shelf tools with custom built components in C# or Python. We dont need to reinvent the wheel, but we sure can streamline the logic. Computational Design is often held back by the scaling problem, where the more complicated a graph becomes the less likely the average technician is to engage with using it. We get it, Spaghetti is intimidating! That is why we believe that we best way to solve this problem is by making workflows as visually simple as possible, and co-design with the end user. By burying the complexity we leverage algorithmic depth and democratise the tools to be scalable and accessible across the organisation, rather than a service only experts can operate. The end user only needs to know what inputs to adjust, not the mechanics of how it works.
Many AEC companies sit on a messy pile of Grasshopper graphs they dont know what to do with. Reliance on deprecated packages, or a failure to maintain with current versions of Rhino leave companies disheartened about digital transformation and sceptical about the value of Computational Design. The person who wrote those scripts might no longer work at the company, or is too busy on something else to maintain them. This is why any Digital Transformation needs a strategy for how to manage the files, train people to use them and resource their maintenance. We can help with that too.
Some of the larger companies in AEC have their own plugins and teams of product developers inhouse dedicated to identifying user needs and translating that into tools that enhance user workflows. This has so far eluded the smaller companies, who lack a userbase to make that viable. We aim to make that available to everyone, by giving smaller companies the option to share in the development costs and benefits so we can level the playing field. Smaller companies have the advantage of being less encumbered by bureaucracy, and therefore able to integrate Grasshopper into their existing processes at scale more easily.
