Grasshopper

algorithmic modeling for Rhino

Dear testers,

Grasshopper 0.7.0014 is available for download.

This release fixes a number of serious bugs with file reading and scripting components. If you've been using an earlier 0.7 beta, please upgrade to this version. 

Grasshopper 0.7 undoubtedly still contains many bugs and should not be used for important work/files as it is less reliable than 0.6.X

--
David Rutten
david@mcneel.com
London, UK

Views: 9748

Replies to This Discussion

Mmmm...I need to try galápagos :D
Thanks David.
Small bug:
It seems the new version has some issues with polylines built with arches.
Components as Explode or Fillet, don’t work.

Thanks again for your amazing work!

Carles

Thanks for dropping G-Money on us!
Is the link to the gh sdk help something new for the 0.7 release? First time I saw it today and it is extremely helpful.
Yes,

0.7 is the first version that has an officially documented SDK. The help file is still lacking many topics and a lot of classes/methods haven't been documented yet, but this is something I'll slowly rectify over the upcoming months.

--
David Rutten
david@mcneel.com
London, UK
Thanks so much David! Galapagos is absolutely fantastic, I can't wait to put it to use, and the new exposure and occlusion components are a great addition. I just did a quick test calculating approximate direct+diffuse shading on a mesh with the exposure component, the animation is here: http://vimeo.com/11829735

The improvements to this tool with each release never cease to amaze and inspire me. I already can't imagine working without it.
A little error opening a definition from 0.6.

I've "emailed" you the definition.

Best Regards.
Attachments:
Great Work David! Galapagos is amazing.
It seems like "Divide Distance" has a bug in this release. It doesn't matter which geometry I'm feeding in, it just gives me the Start Point of the curve.
Thanks
Thanks, fixed.

--
David Rutten
david@mcneel.com
London, UK
2 things
-Could it be possible to have a whislist page?
-in this whislist i would add something like: "Big O notation measurement tool to add to the debugging tools
thanks a lot anyway for the realease!!
The wishlist is on my iPod. Safe and sound.

How would a 'Big O' debug tool work?

--
David Rutten
david@mcneel.com
London, UK
I have never seen such thing.. gaphically. May be it cannot exist, or it's for a very long-term whishlist..
But I wonder if a cluster of nodes could express their time "complexity":

Inside of each node(standard, not custom for the moment), I can imagine there's a precise notation: O(n), O(n^2)..that we don't know because we do not read the code of each node (better this way)
As we keep on adding nodes and nodes..the overall complexity might be averaging or tending to something..

The point is to be aware of which parts of the patch are highly time consuming when increasing the resolution of their feed.
I guess there are nodes that when we double the points, they consume the double of time, and others that consume the time exponentially.

I was thinking that a solution similar to the smart "profiler", would be amazing for a first step. But I guess a more clustered solution would be even more understandable (maybe analyzing the "group selection")

I 'm not sure if the big O notation is something you would only be able to know from the node property or it can be quickly found by an aproximation. >> (like the fps check)

anyway, maybe it's not so useful.
but I recently crashed repeatidly GH and while I was waiting I just thought of it (and where was the limit of increasing those f***ing points) and how to be aware of super exponential time consuming nodes..

thanks!

enrique

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service