algorithmic modeling for Rhino

I can't find any firm information about the development of GH2 - when it began, what state it's in now, approximately when it might be released. In fact, the only information that I know about it is that bugs in GH1 likely won't be addressed until GH2 is released.

So, does anyone know anything about when we migth see GH2, what its features are, etc.?

Views: 6936

Replies to This Discussion

It will be released some sunny day, don't know where, don't know when.

GH2 is a total rewrite. We've switched from Visual Basic to C# for the core product (GH1 was a mixture of VB and C#, GH2 will be C# only).

We've switched UI toolkits from winforms to Eto (which has much better cross platform support) so GH2 will run on both Mac and Windows. The developer of Eto now works part-time at McNeel so I'm pretty confident any problems that come up can be solved the proper way.

We're working on complete documentation. Glossaries, explanations of core-concepts, example files for all components, etc. etc. All fully editable and extensible by third party content providers, be they plugin developers, teachers, translators, or whatever.

This time around I'm designing the SDK with multi-threading in mind, so a lot of types have become immutable. I'm also adding multi-threading wherever it makes sense in the core classes.

This time around I'm adhering to .NET guidelines for the SDK.

There will also be much deeper and better support for data trees (they were introduced only halfway through GH1 development). The same goes for data conversion.

There is support for user data on each and every data type. So you can assign custom data to curves, numbers, breps, whatever and it will piggy back along as that data flows through the network. This user data will also serve as the basis for custom settings. For example you could assign the user data "BakeLayer = Building A" to some geometry and when that geometry gets baked, GH will figure out in what layer it is supposed to end up. Or you can assign "DisplayColor = Orange" and that geometry will appear orange in the viewports.

Expressions have been extended to be any chunk of VB or C# code (support for python will probably be added at some point). They can be far more intricate (but they don't have to be) and they will be run as compiled code, rather than interpreted code. Expressions also have ways to access data that is defined elsewhere in the document. So if there's a slider somewhere called "Thickness" then an expression in a number input parameter could look like "Min(x * 2, Thickness)".


I am doing or have done the above. I'm hoping to get around to the items below.


The interface will be simplified. I'm planning to remove a lot of options and settings and replace them with smarter code. If that ultimately fails options and settings can always be brought back.

There will be a lot more zoom aware UI, so if you want details about some component or parameter, you'll no longer have to dig through a gazillion menu items, you just zoom in on that object.

There will be better tools to document, debug and manage large files. This is a huge area of R&D but it is one of the major weaknesses of GH1 in my opinion.

Solutions will be multi-threaded, and hopefully also run in the background.

As part of a general effort within McNeel, I'm hopeful there will be a reliable way to explore, install, and uninstall plugins for Grasshopper directly from the Grasshopper interface. No need to go to some webpage, no need to register, no need to log in, no need to enter captchas or having a new password emailed to you because you can't remember the old one. It's ridiculous how difficult this appears to be in 2015, but we now have someone at McNeel who's really good at this stuff and I'm pretty confident they'll make it awesome.

There'll be a lot more types of data to work with (sub-d geometry, extrusions, polylines, spheres, graphs, bitmaps, better support for fields, ...). The aim here is both to reduce memory overhead by providing light-weight types and to provide more functionality.

There will be more ways to organise and display data, both on the canvas and in the viewports. Better bar graphs, better pie charts, better and more everything.

The default preview materials will be grey and yellow, not red and green.


As you can see there's a lot of work to be done, for sure the first alpha release will be as soon as possible, but I've been focusing on core classes only so far. There's no working prototype, there's no working UI, there's no document class yet that actually runs solutions. We're a long way from the first alpha.

Right now I'm mostly acquainting myself with Eto (YouTube video if you want to know what that means) and I'm working on data type conversions and preview materials. 


Can't wait for this sunny day to arrive. David, thank you again for your effort : it's really inspiring. 

Oh wow, that sounds very exciting indeed! Can't wait for that sunny day either. 

I am unsure of the size of the team working on GH, but it sounds like you're doing an incredible job and certainly not lacking ambition for the next major release of GH.

If there is ever a situation where a community effort would help, I am sure there is many of us here who are more than willing to help (documentation for example, translation, etc.).

Are you planning to also update the website for the new version of GH? As a graphic/webdesigner I would say there are definitely improvements to be made to give it a more contemporary, clean and organised look (just as the GH UI is). Maybe even a proper Logo/Icon for Grasshopper?

In any case, keep it up! :)

No team really. Giulio is very involved with the Python side of things, Daniel is busy with Kangaroo, Steve, Dan and Marlin are doing the Mac port, Curtis is in charge of the UI SDK, Alain has been co-opted to help out with the documentation system, but none of them are working directly on Grasshopper.

We haven't decided to what extend Grasshopper should become open-source, but I try not to close any doors too early. The documentation for example is designed to be highly crowd-source-able and translatable, because I don't want the required effort to open something up be a reason not to do so.


Is only you who is in charge of gh development? That can not be healthy dude!
Even sometimes I feel my next version of Peacock is very heavy to lift because much work remains... Step by step walks to anywhere, but yours... Gh is not too monster to one person? Now I understand why McNeel take so long to launch versions, the team must be very small!!
As Amir said, if you need help with anything, here I am!!

I think opening the documentation will be incredibly helpful for a lot of people who are starting out. Consolidating the many resources and making them more accessible on the website (through better design) will come a long way in getting more people using GH. The Forum is great and used a lot, but could be better still (something similar to stackoverflow). The home page of Grasshopper is too crowded and the depth of content of the site is not easily recognisable. I have been coming to this website so many times, checked so many pages and still keep finding new bits and functionality.

Also the icon/logo thing is a bit of a surprise. I find it hard to fathom why GH is so hidden it doesn't even have its own toolbar button until you create one and has no icon of its own, even though there are so many really nice icons inside GH.

Anyways, seeing its mainly you I draw my hat even further and will stop complaining ;) After dabbling in so many creative and technical fields I have finally found my true passion in parametric design and am forever greatful for the tools you provide us with.

I am looking forward to the future, especially being able to finally do 100% of my work on the Mac and not keep Windows just for Grasshopper.

Like Daniel is saying I am very surprised by the lack of staff working on a tool that is clearly one of the ways into the future of architecture, design and science. Is that something that you support or maybe even asked for to keep the team that small? I would have thought McNeel could afford some more people, especially with GH becoming an ever increasing selling point for Rhino.

Perhaps now that GH is a more integral part of Rhino we'll add a toolbar button or menu item specifically for it.

The trouble with finding out about plugins; what exists? what doesn't exist? is this under development? etc. are questions that I feel should be answerable through Grasshopper itself. In fact Will Pearson is working on a system which should make it a lot easier to upload, update, find, download and track paraphernalia for Grasshopper and Rhino.

I think it quite likely that at least the standard components will end up on GitHub as a public project, and that is where the long term development effort really lies, both in new features and bug fixes. 

good job

Hey David,

Moving to a pure C# environment sounds like a good idea and all these new and streamlined features are awesome.

Have you at McNeil thought about opensourcing some of the smaller components of the Rhino ecosystem such as GH?

This sort of initiative would benefit all parties and expedite innovation by attracting community support amongst other advantages.



I'm sure this would be hugely popular in the community, and also help compete against Dynamo, which is being developed as open source.





© 2022   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service