Some Grasshopper2.0 Advice

Grasshopper2.0 is an amazing plugin for rhino, and I really like it.
I would like to give some advice to improve its usability.
Besides, apologize for my poor English.

Solution multi-thread

Finally, grasshopper became a multi-thread software.
But when I watching the source code, I’ve found the IDocumentObject ComputeAsync one by one.
So I think there would be some better way to make it faster.

All objects form a graph. So every object has a depth,
which means the longest way to an object who has no input.
So we can let objects who have the same depth run task at the same time.
It may make it fast.

This is my plugin named SolutionAsync to make Grasshopper1 become a multi-thread software.
I hope it can help.

Solution Async Change Level
Solution Async Without Chagne Level

Data Tree

For my opinion, the logic of data tree is the same as grasshopper1.
As far as I am concerned, this data type can’t manage High-Dimension Data.
Such as the (27.9 KB) file, we need to fix this problem in some unusual way.
In this part, Dynamo is better.

Some UX staff

  1. Dark mode should change the color of component tab and menu.

  2. Pop up window is too big in some case.
    When double-click on the Value Component, sub window is too big.
    Pop up input box like Grasshoper1 is better.

  3. Some Black Button on Parameter is unnecessary, because we can double-click on it.
    For example, Colour Swatch Param has a Black Button on it, but we can double-click on Colour Name to set color.

  4. Search Box always moves fast from left top corner to my mouse location.

  5. Data Access is not so clear.
    Mass Addition has a Twig tag, but List Length doesn’t.
    Besides, this tag is too big for me.

  6. Preview Settings have too many icons! In some choice like wire type, it can just show what is selected.
    And if you want to change the settings, just click it and the menu will show!

Wire Types

Bezier wire is popular, but we need more type of wires to make it beautiful.
The plugin called RichedWireTypes in grasshopper1 contains two more type of wires.
I really want these will be in Grasshoper2!

Preset Picker

It is a improvement for value list.
But adding an Preset Picker is not the most efficient way to change named value.
Menu list is better, just like what I said in Preview Settings.
Besides, It is good way to change persistent data just like Unreal Engine’s Blue Print! My plugin called Persistent Data Editor has some more efficient way to change persistent data.

I wish Grasshopper2.0 to be a milestone software in the human history.




All objects start solving at the same time, but will wait for objects they depend on to finish first.
I was actually not all that thrilled about this kind of optimisation because it introduced a fairly large amount of complexity to the code-base for (I feel) fairly marginal benefits.

This sort of distributed solver only finishes faster if two objects which do not depends on each other are computed simultaneously and they don’t both use all the available processing power. If they do, then running two components at the same time just means they both take twice as long to complete, giving you zero speed-up.

That is true. The topology of data trees hasn’t changed. It’s still an ordered list of path+twig pairs where a twig is a linear list of values.

The two major differences between GH1 and GH2 trees are:

  1. GH2 trees are immutable. This is not something a user would ever notice, but if you’re a developer it’s important to be aware of this.
  2. GH2 trees support meta data. Meta data does in fact allow you to append any additional structure to your values. You could encode 4-D array indices as meta-data and then reconstruct your 4D arrays at the other end.

Yup, agreed. There’s actually a lot of colours that would need to be hooked up to the current theme. Once that’s a bit more finished I’ll start work on a theme editor.

Technically correct, but I do like the consistency the black bar provides.

I see that too sometimes, especially when recording the screen. Logged here: RH-68146

It’s not an indicator, parameters with that icon allow you to change the access. For example the bounding box component can create bounding boxes per item, per twig, and per tree, depending on the state of the input.

Can you post a screen shot of that? I’m not familiar with Unreal programs.

Hi David! Thanks for your reply.

Yeah, I realized that change task order have almost zero speed-up.
The only benefit for speed is less tasks at the same time.

GH2 trees with meta-data is amazing. It can help for high-dimension data computing.
I didn’t find GH2 trees so useful before.

It turns out that this icon is used like this, I didn’t notice it before.
But I think Data Access should be shown more clearly on Param, because Data Access is very important for making grasshoper defination.
Description on the param is not enough for me.

In Unreal Engine, the color of wires represents data type in the wire. But I think it’s inappropriate for GH.
And it has some control to change the simple value like point, bool and number.
In my opinion, it is convenient for editing persistent data in item.

Unreal Engine has a Details Window for selected node to change values easily, which just like Rhino’s Property Panel.
I think it is good for looking at the data on document object in Grasshopper.

UE BluePrint Property

Thanks a lot.

1 Like

So this would be an always-on-screen panel which is populated by the selected components ‘menu’?


Just chiming in on the Unreal question: Yes, this is always-on and changes depending on which component is selected. Same as Rhino’s Properties panel.

Yes, it is always-on.

I found that the description window will be black if the number of values in param is too large.
Maybe the window is too wide. Version: 2.0.8127-wip.38163

1 Like

I tested a simple file. I found that GH2 is slower than GH1 in this sample file.
I’m guessing it’s due to too many tasks, which is 4 million. I think setting an upper limit on the number of tasks might help.


I do not create a new task for every iteration. The number of tasks per component is limited to twice the number of physical processors on your machine. Each task runs through the entire array of iterations with a fixed step-size. So for example Task 1 computes iterations 0, 6, 12, 18, … while Task 2 computes 1, 7, 13, 19, … and so on.

But clearly there’s a lot of room left for performance improvements. This file will help with testing, thanks.

1 Like

Can you post a screen shot of that? I’m not familiar with Unreal programs.

I warmly suggest you to do a little bit of research about blueprint and unreal engine since in my opinion it can lead to many interesting thoughts about the developement of GH2.