Back home

After a 4 week stint in Seattle at Robert McNeel & Associates headquarters I’m finally back home. A lot of things were decided regarding the future of Grasshopper 1.0 and 2.0, however since I haven’t even started writing 2.0 I don’t want to list a bunch of features that may or may not make it in lest it be misunderstood for a list of promises. Instead allow me to list all the areas in Grasshopper where everyone is agreed problems exist that we need to attempt to solve for GH2. As a result of this reformulation I cannot mention any totally new features we are planning. I guess they will remain a secret for the time being…

Documentation is woefully inadequate
VB/C#/Python scripting tools are woefully inadequate
Canvas UI doesn’t scale well to large files
Grasshopper is probably only using a small part of your computer’s processing prowess
It is too difficult to find out which plugins exist for Grasshopper
It is too difficult to find out which plugins you need to open a GH file
It is too difficult to use Grasshopper
Grasshopper SDK is cumbersome to use in many places
Grasshopper doesn’t scale well to high resolution displays
Grasshopper UI doesn’t scale well to many custom tabs
It is difficult to work with multiple users on the same project
It is difficult to debug a GH file, especially if it was made by someone else
It takes too long to start Grasshopper, especially if many plugins are installed
It is often too difficult to edit data quickly
It is difficult to associate custom information with Grasshopper data items
It is difficult to maintain version control over large Grasshopper projects (i.e. who made what changes when, which plugins were used and do all the features today work in the same way as they did when this file was last edited?)
Grasshopper has badly suffered from feature-creep and bloat and is in need of a thorough spring cleaning
It has also been decided that Grasshopper will become part of the standard Rhino toolset, meaning that Grasshopper 1.0 will be available in Rhino 6.0

Once the Remote Control Panel is available again, development for GH1 will stop (apart from bug fixes) and I can start typing on GH2. I’m very much looking forward to this as there is some really exciting stuff that might not even take that long to code up. Running on Rhino6 means that I can switch to .NET 4.0 or even 4.5 and those have some really cool async and threading features. But most of all I want to be able to rewrite a lot of core classes because GH1 is a total mess under the hood.

All in all it’s pretty good news me thinks. I was a bit surprised that we ended up deciding to merge GH and Rhino and that I shall be developing GH2 beta as part of Rhino6/7 beta. It does mean I no longer have to worry about installers but it also means I’m tied to the Rhino release cycle. Luckily our new updating system means we actually tend to push out beta’s every week now so it will hopefully not be a big problem.

If you have specific wishes (especially regarding the SDK if you’re a GHA developer!) feel free to post them on our forums or send them to me directly.

ps. Simon Singh was on my SeaTac → Heathrow flight, 10 rows in front. It was an overnight flight so I didn’t want to disturb him but I managed to make a fool out of myself in a record 3 seconds by thanking him for Big Bang while deboarding. In case you haven’t read it yet, do so now. Seriously. Now. Shared first place with The Selfish Gene and Chaos in the category popular science.

13 responses to “Back home”

Sameer Kumar

November 10, 2013

David,

It is impressive how sincerely and honestly you all take to self-assessment and self-criticism. It is also heartening to see the generous openness with which you are inviting all of us to peek into this complex process of development of our beloved tool.

I wish you and everyone at McNeel the best. I have been a dedicated user of Rhino since 2001 and have never had one day of doubt or anguish for the software. I surely cannot say this for any other tool that I have used. You can be sure that you have a silent fan always rooting for you!

Hope to see you again in NYC on your next trip here.

Reply
1. David Rutten
  
  November 11, 2013
  
  Thanks Sameer. I’m very lucky indeed to work for/with a company that doesn’t feel the need to keep secrets. Hopefully as GH2 development progresses we’ll be able to share more details
  
  Reply
Thorsten

November 11, 2013

Hi David,

indeed, it’s impressing how honest you judge the situation.
I directly understood all addressed points but would never have put it this harsh..

Everybody is excited to see the future development, and we are convinced it will be awesome.

The only point I would hesitate is binding GH releases to Rhino specially Betas.
For several projects over the last 5 years we where bound to a particular version of GH related to plug-ins we used. (we stayed with the big, stable version like 0.8.0064 or 0.9.0014 for some month, since third-party dev. didn’t go with every step)
Fortunately we kept (nearly) all versions of Explicit History and were able to open files, dating back to autumn 2008.
If the user is not able any more to choose his Rhino/Beta and his GH version separately, it might mess up the workflow.
I hope that there are methods in the background which will allow us so, which I’m just not aware of at this time.

But you will do a great job anyway, I know..

All the best,
Thorsten

Reply
Ángel Linares (@_aLinG_)

November 11, 2013

Hi David (and hi T.T. :P)

Thanks for the honest and clear exposition of the situation. I really love to be able to follow development of GH from “inside”. I think that at the end if the “small” problems related to files version control and plugins are fixed/solved including GH in the Rhino package will be very nice and will make it even more popular (and we are going to have a proper icon in the RH toolbar, not a custom made one :P).

I think that the multi-threading approach to the new core mixed with a better workflow to deal with large definitions will be a nice improvement that lot of architecture office will celebrate :)

Cheers,
Ángel.

Reply
Atis Sedlenieks

November 21, 2013

Multi-threading is SO necessary!! i think it has to be in top priority list. as for GH + Rhino binding i think there has to be an option, so that i could still update only GH before Rhino betas..
anyways BIG thank you for your work!!
All the best,
Atis

Reply
Beatriz de Abreu e Lima

November 25, 2013

If GH becomes part of Rhino 6.0 Mac users won´t need Windows anymore to run GH. That would be great. Nevertheless, it is impressive that the fact that Mac users are not able to run GH in the OSX hasn´t been reported as a problem. Thank you for sharing the list with us.

Reply
1. David Rutten
  
  November 26, 2013
  
  Eh, Rhino6 is not the same as Rhino for Mac. Even though they share the same codebase at a very very deep level, there’s a lot of code that is unique to each platform.
  
  The inability to run GH on the Mac has been reported as a problem, but it’s not something we can just fix. There’s a large amount of code that needs to be written and a large amount of Grasshopper code that needs to be rewritten to become platform independant. We’re making a start with this, but it will be a long time before we’ll have anything to show for it.
  
  Reply
  1. Basim Shamsuddin
    
    January 7, 2014
    
    I would be interested to know if multi-threading support running gh on windows7/8 via bootcamp on a mac (either rMBP or the new mac pro) will be supported? I can run rhino/gh perfectly ok on retina macbook pro this way, however the lack of multithreading leads to long processing times when computing solutions.
    
    Thanks for your efforts!
    Basim
    
    Reply
unoptimised

December 22, 2013

Props to you for taking all that so well – regardless of all the criticism, GH is still an incredible way to work. I do like the second-to-last comment, though. I believe you said somewhere that “I try never to write a code longer than a page” (or something to that effect…forgive me if I totally dreamt that up), and the number of available plug-ins and tools has started to get pretty overwhelming.

Reply
1. David Rutten
  
  December 23, 2013
  
  I try never to write functions that are longer than one screen. The only exception is if there’s a huge switch statement that needs to be handled.
  
  Reply
theGreenCabbage

March 13, 2014

Can’t wait to see and code (or even help) with GH2’s libraries.

My biggest frustration as a GH dev is finding resources (other than the very helpful David Rutten on the forums) to do something. An up-to-date (or even open source) SDK with up-to-date examples (again, perhaps even open source where David can review changes/merges/pulls) would take a lot of development burden off of you, but allow the community to pitch in as well.

Reply
Zayed

December 12, 2018

Hi,

Probably very late but I just stumbled upon the post.. I am not a programmer but I use grasshopper to do some stuff at work and so on.. Love it, great work, Big fan..

to the point, maybe these things could (or not) be improved in GH:

1- The timers, I saw a post about how the timer works on top of windows and I understand that, but maybe this is worth a shot, since then one can build something totally with grasshopper to control for example (stepper motors) accurately. Firefly did not serve the purpose with its Firmatas due to the same problem.

Visual Stuff:

2- Maybe the canvas can be expanded in the vertical direction as well as in the horizontal one. That is very handy when trying to organize a big definition. Moving all the components is not always easy.

3- When loading lines from rhino, to make the definition look neat instead of a long shaky pencil line, the scale and position differs of the inserted line and the one drawn in the canvas.. Do not but may be a ruler or cartesian co-ordinates for the canvas could solve that problem since then I will knnow I need a line approx. 500 cm and its position is whatever.

4-The geometry which turns green in Rhino viewport. That is very handy,, but when I for example have a surface , deconstruct it, pick one of the vertices with list item, put that point in a container.. The point will only turn green when the last component where it is stored is selected,, all the previous, no. That is bad when debugging a definition, I build something quite long, then want to go back a couple of steps to check what is wrong, then can’t keep track of where my geometry is. of course there are ways around it, like turning all the components invisible or only pick what is selected.. But sometimes, it is just hard,, maybe if it has a solution from the core, might be easier..

Sorry for the verbal explanation without photos, I have some photos but can’t load them in the comments.

Anyway, even if all this is not doable,, just wanna say, it is an awesome thing grasshopper, and this blog is cool.

thanks

Reply
Owen C

March 20, 2025

Thanks for poosting this

Reply