Killer Product — A Rhino3D Grasshopper2 Follow-up

The wait for GH2 might not be long now!?

Back in April 29, 2020 I wrote the article Killer Product — A Rhino3d Product Analysis. You can consider this a long-delayed part 2.

To my surprise, the Rhino3D analysis was (and still is) a very popular article; one which also was seen by many McNeel staff. Thanks to Andres Gonzalez (from McNeel and the new Rhino3D.education) I was able to directly ask some questions to David Rutten about Grasshopper 2.

Unfortunately a year has passed and potentially we might see GH2 soon, but for the record, here is a short, edited version of our conversation. Due to this recent thread on McNeel’s Discourse forums, I was inspired to write this.

Update April 2022 — Grasshopper 2 Alpha has officially been released! In another post by David Rutten you can read a follow-up to the below discussion where there are updates on the issues discussed below!

For those who haven’t seen, David has uploaded some GH2 videos to his YouTube account.

Here’s an example of the new Tabbed UI and scrolling functionality. Source: David Rutten, YouTube

Darrel Ronald — Questions

Note: I laid out some questions and discussion points that I assume readers (including myself) would like to know. The below points set the stage for the email conversation:

For Users

• What conditions would make GH2 ready for release? Why not just release what is already working?
• What is the ‘wishlist’ you are working towards? Could this be public and voted upon? Ex. Dropbox early on had a wishlist (like a forum) where users could vote.
• New features, especially any entirely new feature sets. Ex. I think it’d be awesome to create components to build interactive interfaces, or panels.
• Deprecated features. Ex. Components we shouldn’t rely upon now
• Evolution of the User Interface.
• Will you bring any external libraries into the GH general library? Ex. I think you did this for Kangaroo physics?
• How will GH evolve as a ‘platform’? In my article I talk about what new things will exist for developers, how to monetize and distribute for example

For Developers

• Breaking Changes that would heavily impact our current scripts, this is especially important for managing larger office GH libraries
• Will the Rhino IDEs become more stable and complete?
• Improvements to the developer documentation and dev learning resources
• Any changes to creating and compiling components? I find it quite difficult to get an understanding of this — perhaps this is because I’m learning development.

General Remarks
In my article I was critical of the online presence / documentation of McNeel. I especially notice that a lot of my questions could be answered by more complete documentation rather than through forums. Luckily I did get answers for my problems from someone, but it’s not necessarily a predictable experience (for any software forums that is).

One example is the Rhino IDEs. I really need good intellisense when coding because I’m still learning OOP and the APIs/SDKs. But the builtin IDEs weren’t working well (ex. Python imports). I can’t easily get external IDEs to work well either. It would be awesome if McNeel provided great IDE experience within Rhino, or to provide plugins for VSCode or Atom or whichever–with live ‘run’ links of course!

Anyhow, these are my first thoughts. Thanks for taking the time to respond and consider if it’s worth communicating to the community. Probably I forgot something!

David Rutten — Answers

Note: David answers a mix of these above questions. (Edited)

…I also asked around within the office what info people would like to get and there’s a fair bit of overlap with your list. I do worry about talking goals and wishes and roadmaps as that too easily turns into expectations… I’ll try and give one short answers to your questions right away.

[Re: Team] No team, various people contribute to the final product (Giulio and Steve concern themselves with python, Daniel is in charge of Kangaroo, Will Pearson worked a bit on auto-plugin-loading, Brian is involved with the Compute side of things, etc. ), but grasshopper is mostly a one person project. I’m working with someone now on GH2, [on] documentation, example files, and linguistic consistency and correctness in the interface.

[Re: Time to create GH2] The truth is reasonably banal, gh2 is a multi-threaded program which is waaaay harder to make. It required a ground up rewrite and I’m just trying really hard to make sure that won’t be necessary again for gh3++. Which slows me down even more…

[Re: Open Source] I hope we decide to open source gh2, I can only see benefits there.

[Re: When is alpha/beta release] Before the first alpha version can be released I need to make sure the following things are working;

1. A couple hundred more components for very basic stuff. I’ve made about 100 so far, but they’re all just mathsy stuff. You really can’t do anything interesting yet with gh2 unless evaluating Airy functions of the second kind is something you find interesting.
2. Preview of geometric data types. At present nothing is drawn yet in the viewports.

That’ll be a disappointing but viable alpha release I think.

[Re: Breaking Changes] GH2 is a completely new product. Existing plugins won’t work, existing files won’t load. There may be something we can do about the latter, but there’s never going to be a complete coverage of the native component set of gh1. Initially I’ll focus on making it possible to send data from a gh1 file to a gh2 file. You’ll be able to have both versions installed though, and running at the same time in the same instance of Rhino. I expect a… transition period.

[Re: Platform] I’m not really sure about the platform question. I’m not particularly involved in things like Rhino Compute or Rhino Inside.

[Re: Dev Tools] I haven’t really thought much about dev-tools or docs either. That’s not really going to be an issue for a while.

[Re: Future Goals] Ending on a high note, major goals for the future are:

1. More mature mathematical foundation. […]
2. Multi-threaded solver. Both to keep the interface alive during calculations and just use those 15 other cores you paid good money for.
3. Decent documentation with example files.
4. Metadata support. I.e. you can attach meta values to any regular value, both for your own bookkeeping purposes and as a way to control in more detail how grasshopper treats data. For example “this shape should be previewed in orange”, “this shape should be added to layer Building A when baked” and so on.
5. Better ways to document and associate files. Working in teams on a single project should be way easier.

Darrel Ronald — Questions

Screenshot from the Authors questions to David. Source: Author.

David Rutten — Answers

[Re: What can I write?] You are very welcome to write whatever you deem relevant or interesting, would not be proper for me to curb or guide that. Freedom of the press and all that. I was thinking of writing or recording something myself, but if you want to publish an analysis or critique that would be a valuable alternative perspective.

[Re: Parallel Processing] How much in parallel better? Best case scenario, about 0.8 times the number of additional cores faster. There’s overhead involved in distributing and aggregating the data to and from multiple concurrent tasks. Worst case, it’s slower than before. However I believe the major benefit of multi-threading isn’t performance but responsiveness. We’ve all hooked up the wrong wire at some point triggering a half hour calculation of 15,000 useless solid booleans. If that calculation runs on background threads, it may well still retard your machine for half an hour, but it won’t stop you from continuing your work. But yes, higher performance is a factor too.

Screenshot from David’s response replying to my questions. Source: Author.

Author Note: From here the conversation stopped. I requested some more information, also about how to publish and get approval. But I assume I have clearance to publish this much.

Grasshopper 2 Colour Picker. Source: David Rutten, YouTube