Grasshopper 2 as Maker Platform

One of my great hopes for Grasshopper 2 is that it moves more in the direction of a proper platform for makers – including all of the tools required to deliver high-quality products to end users without the need for any Grasshopper knowledge or skills.

Grasshopper is in my mind one of the great visual programming platforms thanks to David’s unusual skill in both technical deployment and UX; it is a truly great environment that is a pleasure to use and intuitive enough to be approachable. That has contributed to its immense success in the design community. That said, Grasshopper was clearly developed as a single-user tool development platform, and it requires a substantial amount of work to deploy user-facing tools that are scalable.

As Grasshopper has matured, it has become more and more capable and can be hacked to a level that hints as its power as a maker’s platform. At NBBJ we have been focused heavily on building our own internal infrastructure to support in-house tool deployment, to any user regardless of Grasshopper skill. In fact, we have gone to great lengths to ensure that our users don’t ever need to touch Grasshopper or even see it. That includes but is not limited to the following:

  1. UI – we built Human UI (now open sourced) to allow for complex interfaces that hide the GH canvas from users
  2. Dependency management – Andrew built our own in-house dependency manager for ensuring consistent plug-in deployment across our firm (Yak now looks promising!)
  3. Cloud analytics – I built a custom analytics plugin for reporting usage of our platforms (Rh/GH) and our deployed tools (with UI-level event reporting)
  4. One-Click Installers – For deploying tools to any of our firm’s machines, regardless of software/plugins installed.
  5. Custom data models – For storing metadata and configuration information at the file level, to allow tools to work with any Rhino file you might open
  6. Two-way binding with Rhino – For synchronizing GH-built interfaces with the Rhino interface (involves a lot of dicey event listening and flow control)
  7. Connection to web APIs and big data sets
  8. Authentication

This last one is perhaps the most controversial but also perhaps one of the most important, in my mind, because it is necessary and useful for creating a marketplace that encourages innovation in the AEC space. In my mind, the biggest thing that is lacking in the industry is a proper platform for AEC computation professionals to produce deployment-ready tools that they can monetize, which would constitute a new revenue model for a service industry that is threatened by technology and software providers.

McNeel is perhaps the Robin Hood character in this narrative – McNeel has always been very friendly to students and educators and has an ethos of knowledge sharing and inclusive development. Those are all great things. That said, to allow users to have granular control over their work product, and in fact to provide a mechanism for AEC professionals to monetize their work, should not be viewed as an assault on those values, but rather as a great gift to the community – “Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.”

In a technology landscape where big fish gobble up all of the innovation, the little players have very little influence and very little opportunity to dedicate resources to innovate. (Sorry, now I’ve conflated the fish metaphor.) Regardless, AEC firms are reluctant to fund full-on development of scalable tools, 1) because not many people are doing it yet (because GH1 doesn’t cater to it OOTB), and 2) because it is difficult to see immediate results – even then, it is limited to the sometimes intangible impact you can have in a single organization. A recurring revenue stream, on the other hand, could turns heads at the leadership level – the people who sign the checks. Imagine a technology team at an Architecture firm develops a tool that they are then able to license to other AEC professionals. It is a success and starts bringing in revenue for the firm. That revenue is the argument that the team uses to fund further development, expand their team, and hone their focus around tools that can deliver value to the industry – because it promises future growth of ongoing revenue.

Of course, this is an idealized scenario, and perhaps only a handful of firms would focus their efforts on building tools for external deployment. But I contend that building the tools to deliver at scale to non-computational users would both encourage innovation to appear out of the woodwork, and would result in meaningful new products that make our lives easier as designers, scaling up the impact of Grasshopper in the industry well beyond where it already is.

You’ll note that the maker platform for AEC has been a holy grail in tech circles for some time – but I would contend that Grasshopper has a running head start, with a huge, talented community and battle tested UX paradigm. I would love to see it take the next step and become a true maker platform with a marketplace model. Could Grasshopper 2 be that opportunity?

  • Marc
    Design Computation Team Leader, NBBJ

I’ve always preferred the “Give a man a match and he can light one fire. Set a man on fire and he’ll be warm for the rest of his life.” version.

I’ve created the following YouTrack issues, however they are very broad in scope and as such cannot really be ‘finished’. I imagine when the time comes these will be associated with far more specific entries.

RH-42477, RH-42478, RH-42479

Note that meta-data is something that is already finished. The GH2 data tree class is able to associate meta-data with any (non-null) entry. Meta data in GH2 is an immutable dictionary using hierarchical keys and a limited amount of immutable value types. I really want every instance of metadata to be completely immutable because the assumptions are that meta data is:

  • Created and modified only rarely.
  • Shared across many different entries.

I’m heavily considering putting a bunch of standard information on meta-data such as Rhino reference ids, bake target layers, preview colours, bake object names, etc.

I’m a bit confused about ‘authentication’. Can you describe an ideal workflow for such a feature?

That is really a general “Rhino/GH as a development platform” issue. Making sure someone is allowed to use your custom product because they paid for it or belong to a group with rights to use the product is what authentication is for. I would imagine that Rhino accounts would play a role in this.

1 Like

Its really interesting to see this list, Marc.
I’m right next door to you at Handel Architects (assuming you’re in the NYC NBBJ office), and we’re probably a few steps behind you in the computational realm, but have actually identified many of those same issues as development targets over the next year. Especially dependency management, cloud analytics, one-click installers, and custom data models.

Creating some link between Grasshopper and Food4Rhino (which I think is maintained by McNeel, no?) would be really awesome, and potentially hugely simplify dependency management. I could image a Grasshopper file being able to identify which plugins are missing when an attempt to open it is made, then if those plugins exist on Food4Rhino, prompting the user to accept an automatic download and install… (I’ve dreamed of making a plugin that could do this and calling it dungbeetle… because “it rolls up all the shit”).

1 Like

This is already in the works although it is not tied to Food4Rhino (yet). We haven’t really discussed this in the open yet as it is still in it’s early stages of development.


Steve and I chatted about this at AEC event, so he’s already basically answered… but yes, I’m talking about the ability to seamlessly authenticate a user for use of any platform-related product… ranging from Rhino + Grasshopper plugins all the way down to the Grasshopper definition itself. I could see a world where you have the option, as a maker, to authenticate a user against Rhino Accounts to run Grasshopper in a headless mode so that your user 1) must be authorized, and 2) never even sees Grasshopper at all. I’m currently hacking that together myself.

That last one is the more controversial one, I would assume… but also one of the most interesting to me. I recently built a high-level application that requires absolutely zero Grasshopper interaction from the user, even when moving from project to project. It has all of the elements in the list in my original post (the authentication piece is the crudest and weakest link) in addition to others. It has an onboarding flow and in-app documentation, for instance. 18,000 components and about 16,000 of them are dedicated to the infrastructure of making a working application with intuitive UX. I actually would be happy to give you a live demo, because I think it showcases the power of what a maker platform could be for an average power user, not just an expert user.