Grasshopper

algorithmic modeling for Rhino

When will Grasshopper 1.0 be finished? What happens next?

Grasshopper has been in wip-development for over 5 years and we're nearing the 1.0 mark. At some point within the next few months we'll decide that we've written all the features needed to go into beta and we'll stop adding new stuff. At this point the Grasshopper version will be rolled to 1.0 Beta 1 and we'll keep on fixing serious bugs, resulting in Grasshopper 1.0 Beta 2 etc. etc. until the product is stable enough to be treated as a commercially viable product.

This does not mean Grasshopper will no longer be free. Robert McNeel & Associates (who develop and own the copyrights to Grasshopper) haven't decided yet whether or not to sell Grasshopper or whether to keep it as a free plug-in for Rhino customers.

As soon as Grasshopper 1.0 goes into beta, all development (apart from the odd bug-fix) stops and we start typing on Grasshopper 2.0. It will probably be a few months until the first 2.0 WIP version is released but basically the whole process starts over.

What are we looking to accomplish for 1.0 and which things are planned for 2.0 and beyond? The only major feature still missing in 1.0 is the Remote Control Panel. This feature was removed at some point and has been partially rewritten since then. Once it's finished, we consider the 1.0 feature set to be complete.

To be honest we've made very few concrete plans yet concerning 2.0, however it's clear that some things need to be at least seriously considered and researched. Here follows a list in no particular order:

  • Documentation System. This is one of the things we know we're going to do as we've already started. The Grasshopper help system will need to be rewritten and a lot of help topics need to be typed up. We have a pretty good idea what it is we want to accomplish with the new help and how we're going to go about it.
  • Vocabulary. Along with new documentation we'll critically analyse the current terminology and vocabulary of Grasshopper. We'll probably come up with glossaries and style sheets. We want to use words that are —at best— self documenting and —at worst— non ambiguous.
  • SDK and core library cleanup/improvement. Grasshopper was the first large scale product I ever developed and a lot of mistakes were made in the SDK design. A lot of functions and classes have been marked obsolete over time and many operations are not properly bottlenecked. I also want to add a lot more events so it's easier for code to keep close tabs on what's going on at any given moment.
  • GUI platform. At the moment Grasshopper is pure .NET winforms using GDI+ for all the interface drawing. There are certain performance issues with using large GDI+ surfaces and certain limitations on what we can and cannot draw. We will be investigating other graphics pipelines such as WPF, OpenGL, DirectX, OpenTK and whatever else seems promising.
  • Multi-threading. It is clear that some components are embarrassingly parallel, and since almost every single laptop and desktop has at least 4 cores these days it would be a shame not to use them. We will investigate what it takes to implement multi-threading as a standard feature.
  • Large file support. Grasshopper becomes awkward to use when a document contains more than a hundred or so components. We need to both improve the interface to provide methods for layering or grouping sub-algorithms and also add ways to reduce memory and computational overhead.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Views: 6905

Replies to This Discussion

Just because GH is free doesn't mean we're not making any money off of it. Basically, the increase in Rhino sales is what funds GH development. Due to the indirect nature of this approach we don't actually know what percentage of our income is due to GH, but so far we haven't had problems making a living from selling software.

We treat GH as "part" of Rhino, just like RhinoScript. 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

That's a agenda! But I'm missing one thing. It is the feature to break the linear dataflow in order to have procedural data flow or data flow between different documents - in one word: the loop in gh. I think it was mentioned that it could be possibly connected to the clusters. Could you give us an update on this topic and on the future of clusters Mr. Rutten?

I'm still hoping this feature will come because it would open up a hole world of experiments..  

Improved Clusters! Future i say :)

Large file support sounds interesting... we are working on an architectural project which is completly built in GH. even creating plans is solved within GH.  But we reached a complexity where we need to separate the definition because it is very slow. Therefore the new implemenation of clusters was very usefull in version 0.9. It would be great to improve the cluster to get a strong reference system to work on large projects and in a team....

Anyway, the last five years of GH changed our lifes... :-)

Remembers me at the time when I was also creating a full parametric building using Grasshopper (I think it was version 0.6.0019) without the Undo and the Disable function.

In the end it took seconds when I was adding a new component to the viewport and when the difinition was finished I wasn't able to change the start parameters because the computer always freezes.  T_T

Considering GH is a WIP that hasn't even hit beta yet, I think what you've accomplished, where the product is being used, and the culture that surrounds it are all impressive achievements. So pat on the back to you there David and team.

I just used GH for a projection mapping project last night alongside a bunch of film majors using max/touch designer and they were all floored by the stuff grasshopper is capable of. I think we are all very interested on what's next for the platform.

In my opinion points 1 and 2 are tied to if it's going to be a commercial product or not. Understandably, things that are free usually have little support documentation, and things that are sold pretty much need to have proper documentation. 

I agree with some of the comments bellow that multi-threading is important, but I see you are more than aware of this. 

Congrats on finishing (or almost) such outstanding work!

I wonder a few things.

"At some point within the next few months we'll decide that we've written all the features needed to go into beta and we'll stop adding new stuff."


Does this mean that user/forum popular component requests will not be so much into consideration. aka "the wish". I think grasshopper has the huge advantage that it listens to its consumer base. Would hate to see that go. 

Also, will there be eventually some point where all rhino commands will be accessible through grasshopper. For example flowalongsurface and stuff like that. As well as when rhino itself adds new functions will they be streamlined down to grasshopper? Maybe some component that can call a rhino command not available in gh directly. Like you input the command into the component?

David has made the sdk availbale as well as providing a scripting component. You have all the tools you need to customize as you wish
Well, not all rhino commands exist in the sdk ;), I know how to use it.

If a request makes sense then we'll put it in whatever version is currently being actively developed.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

If you've ever dealt with Rhino Developer support, then you would not worry about the end of the wishlist.  The support culture around developers and users at McNeel is top notch.  There are several request I've made for the SDK and if reasonable, they add it within a few updates.  This also works for general functionality request. 

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service