Grasshopper 0.9.0006 available for download

Replies to This Discussion

Permalink Reply by Jeliszej Korcsak on August 12, 2012 at 7:14am

This sounded reasonable to me. I tried unchecking all events, just to see if stuff quickens up, but unfortunatelly placing even a simple panel component takes like 4-5 seconds. I tried restarting Rhino (just to be sure settings changes take effect) but still the same problem.
Opened a new file, it works pretty quickly, but I guess it's just because it's much lesser information to save, when there's only a panel on the canvas...
Soo.. all in all, please inform me if anyone has an idea, r experienced stuff like this!
Ty

Permalink Reply by David Rutten on August 12, 2012 at 12:34pm

It's probably not autosave, but if it is, disabling autosave should fix it. It could be some other problem. Can you send me a file that has this delay whenever you add a new component?

Either email it to me directly or make a new topic in the Bug forum.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jeliszej Korcsak on August 13, 2012 at 1:23am

I have sent you a direct mail with the file, and described everything in it. If you need more information just ask! Thank you very much for your time!

Permalink Reply by Jeliszej Korcsak on August 13, 2012 at 9:52am

Some new info on the subject: the larger the GH file the longer the occuring delay is.

Permalink Reply by Stanislas Petit on August 14, 2012 at 4:08am

Hi everybody!

I am into troubles with Grasshopper 0.9.0006 installation.
I run Rhino 4.9(registered) and latest Rhino 5 : (5.1.20808.315, 08/08/2012)
on Windows Vista-Home-Premium 32-bits SP2.
Here are some screenshots of the Grasshopper's outputs after install.Same the 3 times I've retried : install 0.9.0006 / revert to 0.8.0066 that is still running ok ...

I've visited related places of the forum to get hints and it seems I am the only one to experiment the trouble!

at :problem-loading-grasshopper-with-rhino5-and-updating-script
or : grasshopper-0-9-0005-available-for-download
and from :  grasshopper-0-9-0006-available-for-download,  zipped downloaded gha's, no more duplicates found, but nothing that could resolve the failure of 0.9.0006 loading itself...

at : loading-error-unable-to-load-dll-rhcommon-c I run with  latest vcredist_x86.EXE ...

I am so exited to discover all those great improvements like vector fields stuff ...

Thanks for help !

Permalink Reply by Danny Boyes on August 14, 2012 at 4:28am

Hi Stanislas,

The First two images are related to the fact that you have a duplicate gha somewhere other than the normal Grasshopper folders. Mine were located in my Downloads folder. Once I zipped the duplicate gha's (you can just delete them) Grasshopper will load without these messages. Do a windows explorer search for "*.gha" to find them all.

The Last message is the Global_Proc.get_settings error, which I have at work on Rhino 5. I'm able to use Rhino 4 without any issues. At home the same version of Grasshopper and Rhino 5 runs without issue. I reported this early on in the testing phase of 0.9.0001 but there hasn't been a a solution that I have seen.

Permalink Reply by Stanislas Petit on August 14, 2012 at 8:39am

Thanks for the answer Danny.

I'm ok with duplicated gha's.

I am wondering about the inquired paths here ...

I feel like : a link to installation path cannot set up properly during install "under certain conditions", still being set at it's relative path value in David's machine...
It sounds like compiler option related ... or what ?

I hope David will find time to fix it : I really got used to Rhino 5 UI ! And here is the future (even for a 'poor system' owner!)

Best, Stan.

Permalink Reply by Jon Sargent on August 16, 2012 at 5:31pm

Hmm, interesting.  0.9 is poking it's nose in new places for gha files.  Does anyone know the exact breadth of this search?

-Jon

Permalink Reply by Marie Prunault on August 14, 2012 at 2:24pm

No one faced this yet?:

Some issue with data trees on the new Grasshopper.

I've made some basic examples, hope it shows the problem :

Check what happens in the param viewers:

 

pic1. Grasshopper 0.8.#...

   In parameter viewers, we see the number inside the branches remains while going through components (a list of 4 branches of points like {1},{3},{4},{7) put into a polyline component returns an output of polylines with branches {1},{3},{4},{7}).

This was easy to handle, straightforward.

pic2. Grasshopper 0.9.#...

   passing through certain components the input branches {1},{3},{4},{7} get "reset" as follow:

{1} becomes {0}, {3} becomes {1}, {4} becomes {2}, {7} becomes {3} etc...

So far the way around this that I know is to replace branches afterwards, but in a real-life GH definition it soon gets extremely fastidious. Not talking about fixing older GH files that get messed up when opened with GH 0.9.#...

Must be a smarter way I'm missing on.

Is there somewhere a setting to get back to the more user friendly GH0.8 way. And some solid reason behind this change?

Thanks.

Permalink Reply by Ángel Linares on August 14, 2012 at 2:35pm

David said in 0.9.0005 version post:

Here follows a (not exhaustive) list of changes since 0.8.0066.

Important Changes:

• Data Trees are now constructed differently in some cases, this may break files that depend on specific data tree layouts.

Permalink Reply by Mateusz Zwierzycki on August 14, 2012 at 3:05pm

yea, but i cant find any reason for crv component to change input paths... ;/

Permalink Reply by Ángel Linares on August 14, 2012 at 3:26pm

But is as simple as using Merge Tree component before curve. I supose that David remove "tree playing" inside some components and the component only read the order of trees to simplify the process...but I don't know it safely...it could be a bug. David, we need you! 

And only to point it out (because I think that it could help), this is the tree guide that David give us while testing the pre-release version:

Data Matching has changed because (A) there was a bug under certain conditions and (B) I wanted to  make it more economical with regards to data path growth. The new logic is roughly as follows:  

First a master input parameter is identified. At the moment, it is the parameter with the longest  path length. The amount of paths doesn't matter. Input parameters that have Tree access are never  Master parameters (unless absolutely no other parameter is available) and List parameters have lower  priority than Item parameters. In future versions it will probably become possible to assign a custom  input as master. This however is an expert user function and I want to post-pone adding it as long  as possible in order for the default behaviour to be tested and improved.  

If all input parameters are list parameters, output paths are no longer grown. I.e. The Reverse List  component should output the exact same data tree structure as it gets.  

The master parameter might not be the parameter with the most branches. It is therefore possible  that we run out of defined paths before the component is done computing. If this happens, the last  index of the last available path in the master parameter is incremented on each iteration:  

Input  A = {0;0} {0;1} {0;2} 
Input  B = {0;1;0} 
Output C = {0;1;0} {0;1;1} {0;1;2}  

A has a maximum path length of 2, B has a maximum path length of 3, B is therefore the Master  parameter. However we need three unique output paths since A provides three paths, so {0;1;1} and  {0;1;2} are made up on the spot.  

It is also no longer possible to apply 'Shortest List' and 'Cross Reference' options to components.  Old components that had these options set still work like they did before, but that should be considered legacy support. Instead, there are now three components in the Sets tab, List panel called 'Cross Reference', 'Short List', 'Long List' that basically provide the old functionality with a lot of additional flexibility and options.

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• 8
• 9
• …
• 11
• Next ›
• Page