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
6 Likes

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.

David,

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.

Cheers,
Marc

5 Likes

Eii @stevebaer, how is this today? is there a way to authenticate in a plugin with Rhino or other accounts? It would be super useful if we could link external accounts with the Rhino account.

I don’t personally know. @will is more knowledgeable in this area than me.

Cloud Zoo is open to plug-ins. If you want to use Rhino Accounts to control access to a plug-in, then this is the way to go.

CloudZoo to authenticate plugin licenses, seems useful but not sure it is for me. But about linking with other accounts? have you considered it? I think it would give enough room for new interesting features with little effort from you (just linking the rhino user profile with other accounts and an OAuth2 log-in/out interface with possibility to use the linked accounts of each user to log-in). Could you (re)consider it for Rhino 7 or 8 please?

Some applications: to do a modern log-in in Rhino from the mobile using the Google account; or be authenticated within a plugin as a developer by logging in with the Github account and validate that you are a contributor to that project (using the Github API); or a plugin that notifies the Rhino app of new topics you are subscribed to in this forum using a Discourse.McNeel account or post questions from the app to ensure that the user meets certain format or requirements depending on the type of question (such as including a file); or to streamline in-app payments using paypal; or to log-in in a future or, for the one I need for my monetization model, to unlock functionality of a plugin according to the role within a Discord server, one logs-in or links his Discord account to the Rhino one, and according to the permissions that user has in that server, the user can use come tools of the plugin. This would be amazing for me, because I can automate the assignment of roles from paid services like Patreon or using gamification/meritocracy for participating and helping on the server by earning points to achieve roles, or automatically remove a role of some user after a certain time to mimic the trial version, manage all this manually with a couple of clicks… many possibilities, much better than authentication by license for me.

I know I could implement a log-in myself using any API that offers OAuth2 or from an authentication service, but it requires a redirection url that I need to host somewhere and it makes sense to me to have a native log-in system in the app that instead of using the old email + password, uses modern log-in methods like two step validation or activity recognition from another device, to connect Rhino to other web services. One more step to bring Rhino closer to the web :slight_smile:

Rhino Accounts is a federated identity provider and does allow you to login with certain existing accounts (e.g. Google). However the foreign account must implement OpenID Connect and neither GitHub, Discourse nor Patreon support OIDC.

Rhino Accounts also supports OAuth2 so that’s a possibility for allowing your users to authorise your use of information relating to their account with us.

I know you say you’re not a fan of licenses but you could potentially automate every aspect of license management to the point that it’s pretty transparent for users. You (as an issuer) can add and remove licenses (for your product) from users’ accounts by making HTTP requests to Cloud Zoo. You could use OAuth2 and/or webhooks to receive information about members’ roles from Discord/Patreon and add/remove licenses from their Rhino Accounts automatically.

Rhino Accounts is the only in-app login system that we’ll be providing, so I’m just trying to think about how you could achieve your goal using what we’ve made available…

Thanks for giving it a thought. It’s fine for me to use your licensing system but I still don’t see how to keep connected the Rhino account with another one to avoid having the user to log-in in the external account each rhino session/once my plugin opens (like cookies? IDK). I think the time it would take me (I have insufficient web programming experience for the knowledge demand of your guides), is going to be much longer than the time it would take you to offer this account links to every developers and users.

Yeah that is, it’s not just about licensing or sign-in, I think it would be convenient to integrate it with CloudZoo and use everything you have in your SDK about licensing. But I think it’s more about authorizing applications (plugins or services) from the Rhino account, that the user grants certain permissions like being able to access email, name, licenses and other linked accounts. There is some guide about how to get the rhino users info?

I understand that the integration with other APIs is in hands third party developers like me. From the Discord API I can know some basic info of the members of my server, but how can I know the rhino account for each one, so that I can match discord roles with Zoo licenses?

Neither system allows you to store information or auth tokens from the other, so I think you’d need your own web app that, for example, would allow your members to log in with discord and then link their Rhino Account. This “link” (probably the user IDs from each accounts system will suffice) will be stored in your own database.