algorithmic modeling for Rhino
We don't like to make promises, as we're very bad at estimating. Basically Grasshopper releases follow one of two patterns. There are slow releases that roll minor version number (0.6, 0.7, 0.8 etc.). These sometimes take weeks or even months. One of these is usually followed by a flurry of revisions (0.8.0001, 0.8.0002, 08.0003) where reported bugs are fixed.
Current version 0.8.0066 and was released on January 22, 2012 (yes, a long time ago).
The next version will be 0.9.0001 and will hopefully be released in late May or Early June. I pasted the release notes below, as they were on May 18th:
The main focus of 0.9+ is to improve cluster GUI and implementation.
I'm loving this:
"In Rhino5, the Zoom Extents command will now include Grasshopper geometry."
Thanks for all of this hardwork :) We will be patient knowing what is coming :D
Excellently... Truly revolutionary changes. It will be a pity that old add-ons will not to work in new release. Whether it is possible to start the old or new version GH at own choice?
It's not a guarantee that old components won't work, only if they relied on some bit that was changed. We'll just have to wait and see which ones work and which ones don't.
I am very excited like everyone else about the next release and about many of the new features. I know its early days yet but I am concerned about two of the 'Changes', especially:
Many 'live' and 'complete' projects that are set out in version 0.8.0066 will need to be updated in 0.9.0001, and many of our projects do implement changes to the data tree. However, this is only possible if we are able to access the 'older' GHA files in version 0.9.0001 in the first place. I don't want to sound panicked here but can you please shed light on this matter? How extensive are these changes? I have not had any problems in the past updating certain components etc when newer versions of GH were released, so is this transition less painful that I am making it out to be or will I be going through every project with a fine toothpick?
Thank you and keep up the excellent work
I would recommend you keep a Safe copy of the file in version 0.8.0066 and make a note of which version you should use in the "Rhino Notes" if things don't work out in 0.9.0001. Then if you need to revert back to 0.8.0066 at any time you simply have to re-install it*. As the installation of GH takes seconds there should be no real overhead.
Just the other day I had to re-instate version 0.8.0003 for a job from 2010.
*Note as commercial users it is advisable to keep a copy of every installation program of GH and keep tabs on which version you wrote the definition in. (Both in the Rhino File and the GH file)
Thanks for the reply. As of now every project is pretty much 0.8.0066 friendly and I do keep a record of GH versions - mine goes back to when it was 'Explicit History' :). I guess the thing to do it wait and see how 0.9.0001 will go and take it from there. Any project that will be 0.9.0001 friendly will stay that way. All others will need to either kept as 0.8.0066 or reconfigured to be 0.9.0001 friendly.
a. "Added Data Dam" you changed the name :D
b. "Added Partition List component" YESSSSSSSSSSSSS
c. "Replaced Containment component" thank you
d. "Convex Hull component will now solve for 2 points" :)
oh and these "Added Point Groups component for finding proximal clusters in point collections (Vector.Point dropdown).
Added Populate Geometry component for distributing points on different shapes (Vector.Grid dropdown)."
Some really exciting additions and fixes here. Very much looking forward to the release.
One question which arose as I was reading through the lengthy list. I see some components which are taking on the functionality of what were previously 'add-ons.' The ones I am referring to are:
Which, if I am not mistaken, are covered by Weaverbird. In this case, was this a decision that was made with the development of weaverbird in mind? Will the whole Weaverbird suite be included in the default component set in the future?
For this particular case, I think it makes sense to develop the mesh tools further, which Giulio and UTO have done via their add-ons. Will Giulio remove this functionality from a future version of Weaverbird to avoid redundancy?
That's a bit of a painful point actually. On the one hand I really want people like Giulio and Uto to develop components for Grasshopper. It provides a surplus value that is almost impossible to overstate. I want to have a productive relationship with 3rd party developers, because any effort I spend making life easier for them results in a large return on investment. I realise that if I start shipping components that were already available in 3rd party libraries it is a very effective way of poisoning this relationship. On the other hand I want to provide thorough baseline functionality in Grasshopper, so users won't have to go hunting around for functionality that ought to be part of the main product.
I have not found a good way to solve this conundrum. What I'm doing now is —what I consider to be— the least of all evils. I.e. I try to keep ignorant as much as possible about what the 3rd party developers are up to because:
a) I don't want them to give me ideas like "Hmm, I like this idea for a component, I'll take a crack at writing my own"
b) I want my development efforts to be guided by my interaction with users, not developers
c) and I want to keep plausible deniability —as horrendous a concept as that is— in those cases where I do infringe on someone else's turf.
In the cases you cited above, I was unaware that Weaverbird had very similar components. Giulio pointed this out to me after he learned what I was up to but we agreed that providing these components as part of the core package is good for everyone. Incidentally my MeshBlur works somewhat differently from Giulio's.
Thanks for the thorough reply!
In all seriousness, I think that adopting functionality from add-ons into the default GH component base is actually a great way to forge the relationship as long as there is a way to acknowledge the developer. If the component is mature enough, and used enough, and adds critical functionality, then I think it is great to bring it into the fold.
But if you are not actively keeping tabs on what others are developing then surely issues will arise where you will bring something into the GH component set that has already been at least attempted.
Processing and Arduino both have folded in mature third party libraries into the default installation.
Anyways, it is not a straightforward issue, but in any case I am glad there is a discussion happening. In the case of these specific components, I use them all of the time, so I am glad they will be included in the default install.
I'd just like to say that I'd be very happy for this to happen.
Those remove duplicate components were knocked up very quickly with little thought as to efficiency - just brute force comparing all points with each other. They worked fine for what I needed at the time, but I'm sure they can be improved upon.
I wouldn't want the possibility of a better GH standard version to be held back for the sake of not hurting my feelings.