Grasshopper

algorithmic modeling for Rhino

I know that questions are wrong and don't speed up things, but I am simply curious and trying to find that out for weeks now:

Have we already been told whether Grasshopper V2 will work with Rhino V5 and whether it will still be free?

Views: 3800

Replies to This Discussion

Drop and give me 50!

Questions are natural, not wrong. We just don't know the answers all that often when the questions involve the future. However there are some certainties now that we didn't have a year ago and they are thus:

  1. Grasshopper 1.0 will be included (for free) in Rhino 6.
  2. Development has stopped for GH1, but we'll still try to fix bugs, in fact many bugs have been fixed since the last release for Rhino5. If you're part of the Rhino WIP cycle or otherwise when you buy Rhino6, you'll get access to the most recent GH1 version.
  3. Grasshopper 2.0 will be a public, free beta while it's under development. It's not clear whether or not we'll include GH2 in the Rhino WIP releases, or whether it'll remain a separate download/install.
  4. GH2 will work on both Rhino for Windows and Mac.
  5. GH2 will replace GH1 once it's ready, so at some point Rhino (version 7? version 8?) will ship with GH2 instead of GH1.
  6. The price of Rhino will not be affected either by inclusion of GH1 or GH2, though of course it is possible the price will at some point change for other reasons.

Nice!
David, if you allow me the question, instead of asking about the future,
given your experience in the development of GH1, what percentage you consider that is already developed of GH2? at least in a basic way? In what part are you?

It's very difficult to say. GH1 was written guerilla style and had to appear to be working very quickly. I think it only took me about two weeks to have a proof-of-concept up and running. Then I spend three years trying to hammer that code into something usable.

With GH2 I decided to take the complete opposite approach. I've spend 2/3 years now (on and off) working on core code that I know I'll need eventually. I'm trying to make sure that all the core classes are performant, secure and thread-safe whenever possible. There's a huge amount of code already written, but none of it is actually being used by other code (I do write a large amount of unit tests, sometimes it takes more time to write tests for code than the code itself).

I started with some very early UI experiments half a year ago, just to make sure the new UI framework was indeed fully cross-platform:

More recently I've started working on actual UI and it turns out that the code already written is doing a great job. It also turns out I need to write a lot more core code and I do need to re-think some of it (especially the interpolation pipeline for animated UI elements is still too complicated to use).

In terms of lines of code written I think I'm somewhere at the 10~20% mark, but so far almost all lines were particularly difficult ones. Hopefully it won't take a similar amount of time to write the next 10~20%, or the 10~20% after that.

Ohh, I honestly thought the percentage would be higher, but it sure that this approach will accelerate much in the following levels of development. I have a lot of curiosity to see the next transformation of your Explicit History.

Nostalgia? I'm sure you will again capture those feelings of creating something awesome :)
I think I can say on behalf of all who love this software, thanks very much and hope you enjoy making it grow!

All spoilers of GH2 are great and exciting. I'm desiring to know more.

Have a great year David! :D

This is not exactly a wish list item but the behavior of the datamining software Rapiderminer VPI is very interesting: when you drop a component over a wire it is automatically connected (if that possible,ie no ambiguity in the data type). Something of this kind would be a nice feature of Grasshopper :) ... most probably a very hard one to implement (for sure I'm not an expert...).

Good work and good luck for Grasshopper v2.

It would certainly be difficult to reliably pick the connection scenario the user wants, sometimes because there are several competing ones, sometimes because the user wants an ambiguous connection. A potential solution I'd like to try though is to display ghost connections whenever a new component is added. These ghosts can then be actualised simply by clicking on them. This is not however the same thing as my scheme does not deal with deleting existing connections.

Maybe it could work for the simplest components such as parameter components ... It could also be possible to add nodes to the wires and fork them (without adding a parameter, like adding a new internal vertice to a curve/polyline or the plus minus signs in the inputs of some componentes)... but I digress, sorry.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service