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

Replies to This Discussion

Permalink Reply by Fred Becquelin on May 3, 2013 at 8:02am

Is translation somewhere in your list? It's a major issue when teaching. I wouldn't mind giving a hand btw.

Permalink Reply by Ángel Linares on May 3, 2013 at 8:11am

I wouldn't mind neither...For me it is not a big issue (usually the technical profile of students makes easy to deal with "English interfaces"), but could be a good point to expand the use of GH.

Permalink Reply by David Rutten on May 3, 2013 at 9:57am

Localization (as it's known) hasn't been discussed yet. We will discuss it within the company but I'm neither for nor against it. If we do end up localizing GH then I want to make sure it's done properly so that partial language localizations can be added easily, by anyone.

Permalink Reply by David Rutten on May 18, 2013 at 2:03pm

So it's been discussed kinda sorta. Seems that localization is very low on the list. I will certainly investigate what it will take to make GH2 localizable, but there are no guarantees that any language other than English will be provided.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Mateusz Zwierzycki on May 18, 2013 at 2:43pm

Do you really think that localization is a good thing ? How many words do we need to understand what happens on the screen - 20 ? It will generate more problems rather than advantages, same as here....

http://www.grasshopper3d.com/forum/topics/grasshopper-for-rhino5-av...

EDIT : For instance - each time my student has Rhino localized (Polish), I'am useless cause commands are so different from English.

Permalink Reply by David Rutten on May 18, 2013 at 3:02pm

I know. I'm not a big fan of it either. However the fact remains that there are a lot of people whose grasp of English can be picked on a scale from poor to non-existent. Strings that could be localized can be grouped under:

Menu item text/tooltips
Tab, Panel, Component and Widget names/descriptions
Warning and Error messages
Documentation

Problem #1 is that a lot of the text you see in the GH interface is created at runtime, sometimes using algorithms that are based on English grammar and syntax rules.

Problem #2 is that descriptions and especially documentation is a lot of text. Translating all that into the dozen or so languages Rhino typically ships in will amount to thousands upon thousands of hours of work, and then of course the work will never be done while Grasshopper is being developed.

If we do ever get around to localization I want to make sure that the strings can be edited by anyone so the actual work can be crowdsourced and I'll also insist on it being possible to switch between languages without restarting.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Mateusz Zwierzycki on May 18, 2013 at 3:29pm

"...switch between languages without restarting."

That would be a nice solution. It would be even nicer to have all "language packs" installed automatically.

"...crowdsourced..."

How else do you imagine it ;) ?

This could be a translation project. It can (?) be done quite painless something like :

McNeel creates online database
user installs GH
when user press the translate shortcut he/she can translate clicked item and his/her translation goes to database
database is processed to obtain the "average translation" from all users for each item
GH gets the updated translations from time to time

I don't know is it really a reasonable (and real) idea... The whole "translate" widget (or however we call it) may cost you a lot of time to create.

EDIT : So in the beginning, localized version is always English... when ppl start to translate it, some items are displayed in for instance Spanish (choosed language), so user sees what is not yet translated and where can he/she contribute.

Permalink Reply by Ángel Linares on May 3, 2013 at 8:02am

Everything looks very promising and that control panel feature that reborn from ashes makes me thrill :P.

One of the stuffs that makes me feel a little bit lost is the free/not free statement, not just for me but for all the people I'm teaching and are adopting GH inside their workflow (with the investment in money and time that it supposes). After 5 years of development and now that we see the 1.0 landmark so close, IMHO, perhaps it is time to stablish a serious politic about this topic.

Thanks a lot for the sincere and detailed roadmap picture that you show us.

Permalink Reply by David Rutten on May 3, 2013 at 10:03am

I would love to have some certainty about this as well. Bob is ultimately the one who decides this.

In the meantime, all current Grasshopper versions are not time-limited and can be used for ever and ever on Rhino4 and Rhino5.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Ángel Linares on May 3, 2013 at 10:55am

Nice appreciation. Then it would be a good practice to keep every new release in safe place :P

Thanks for the answer. I understand that in this topic you are just "the messenger".

Permalink Reply by Rodrigo Medina on May 3, 2013 at 9:17am

Really looking forward all this improvements specially the multi-threading as a standard feature.

Permalink Reply by djordje on May 3, 2013 at 9:36am

I also think this suspicion on "free/not free" should be deeply reconsidered.
Getting something for free (as it is now) but at the same time having a non-free prerequisite(Rhino) in order for the the first one to work, is quite a good solution.
It literally tricks people into thinking of having something totally for free! Which is what large masses love - there is a huge difference between having something for free, and paying even tiny amount of money for it.

Just my two cents :)