Grasshopper 2

That “freeze or crash” only happens because the whole graph is recalculated all the time. In Houdini, if you work on a specific area, you simply set the blue active button to something closer instead of to the end. The rest is just ignored.
And of course you can also kill Houdini with silly stuff, but a bit of intelligence on the user side helps there too. :wink:

Oh, and in Houdini, you can always hit Escape to stop computing… Or set it to manual refresh only.

It’s not only the list vs. attributes, the whole thinking and GUI of GH is strongly on the elaborate, clicky, “looking nice but is slow” side.

Like in Houdini, if you select a node, all the parameters are directly visible in a separate parameter window. So you can directly see all the settings and values and change them. In GH it’s all hidden and you need to click that, hover that, click a dozen times there…

And the whole argument above about “it’s the users fault if things are slow” is really hard-core Stockholm Syndrome. If somebody has 64 cores and only one of them is used, that is not the users fault, that is inadequate programming in 2021.
That you can also optimise your own part of things simply is a totally different matter.
And yes, many of the GH nodes are really primitive or don’t give any useful feedback, so that doesn’t help things either.

I’m really thankful to have been on the other side of the fence for a while, gives a rather good perspective how green things can actually be :wink:




I think we all agree that UI design isn’t Mcneel’s strong suit…
Though I am hoping once Grasshopper 2 moves to Beta, any user UI considerations regarding speedups and reduced clicks will be taken into consideration. Sofar, the design mockups on David Rutten’s youtube channel are promising.

1 Like

Of course, but to be honest, even with these tools I’m not expecting many GH users to do much better. Simply because many GH User having almost 0 experience regarding surface modelling.

Rhinocommon offers a function to blend surfaces, but this pointless if you are missing the more important subset of matching surfaces. The latter is one of the most important feature in free-form surfacing. Without that, its almost impossible to create a continuous shape in a controlled manner.

So people give up, do bad workarounds or stick to meshes. None of these solution make sense if you usually do surface modelling tasks in Rhino (= what Rhino is supposed to be). Well, its definitely not the first time ever mentioned, but before taking care of fancy UI stuff or performance details, GH/Rhinocommon should actually improve in this direction.

There are almost no improvements over the last 10 years in this regard. Ideally Grasshopper/Rhinocommon should mirror what’s inside Rhino regarding modelling.
There are so many repetitive jobs waiting to be solved with Grasshopper, but it’s pointless to automate things if you cannot reach the same output as with manual modelling (or only with unacceptable high effort…)


So… you expect GH2 to pass the turing test?
When a user make a definition using dozens of solid boolean operations and expect it to work realtime… yes, it is 100% user mis-understanding of the whole situation.

Generally speaking, no.
Expecting a CAD to use 64 cores for non-rendering scenarios is, again, an user-side problem.

Grasshopper will still use Rhino math.
There are CADs that model nurbs taking advantage of 64 cores?

1 Like

Sorry but where did I say this? I was actually saying the opposite! But part of the truth is also to say, that often it is the user fault to run into performance issues.

I said that parallel computation is not the holy grail of high performance programming. It requires that the operation can be parallelized, which is often not possible. It’s that simple. Under ideal conditions you might utilize your 64 cores, most of the time you are not. Even if you can parallelize something, setting up a computation to be executed in parallel can cause a longer computation time as if not. In fact, modern programming is about non-blocking, concurrent programming. People talk about performance optimization but have no clue about it. That is my point! They create trillions of unnecessary data, and then they complain that they couldn’t use 64 cores to create their garbage.

This does not mean that Grasshopper and Rhino should not improve in this direction.


Indeed I know all this already. I use both Houdini and GH and like them both for their purposes. They are my two most used software.

My point was some major things will need to change to make Grasshopper more Houdinish (and I’m not sure it needs to be).

I don’t buy the whole stop the node thing. That is not what makes Houdini auto wiring work. It is because Houdini does not need to list match.

Like in Houdini, if you select a node, all the parameters are directly visible in a separate parameter window. So you can directly see all the settings and values and change them. In GH it’s all hidden and you need to click that, hover that, click a dozen times there…

Not exactly. I would say GH is easier in this aspect once you know what the abbreviations mean. (Although parameter referencing would be nice). In Gh parameters are controlled directly by the inputs (sliders, panels, toggles, etc.). Only thing you are hovering is to see input description (which is same as Houdini both on the node and in param viewer). Again, Gh is like VOPs where you have nodes (basically sliders) for constants and what not. And if you did a param editor set up like Houdini in Gh it would make lists very annoying to use I think.

So true. I just stumbled over this article which proves your point (about algorithms and more):

commodity CPUs … could outperform GPU-based training…
… performance could be improved with vectorization and memory optimization accelerators in modern CPUs.
“Hash table-based acceleration already outperforms GPU… if you aren’t fixated on matrix multiplications, you can leverage the power in modern CPUs and train AI models four to 15 times faster than the best specialized hardware alternative.”

Would be nice if it would apply also for geometry…

// Rolf


A practical request: it would be nice if you could store User-objects in subfolders within the main User-objects folder.

You can do this already. I have my user objects structured into their own folders.

Really, I just did that and none of the objects were showing up at all. Maybe that’s because Grasshopper was open then :wink:

No exp w/ Houdini, but by way of UE4, the ghCanvas could really use some super simple keyboard shortcuts [unless I’ve missed something so far, which is def possible]:
M+LMB = multiply
A+LMB = add
D… = divide
S… = subtract
E+LMB = extrude
single-click to search (instead of double)

Perhaps not “super simple”, but there’s a whole bunch of them:

1 Like

Sure. I’d consider those all as standard input procedure–type & search kind’a stuff. It’s helpful, (essential) but M+LMB for multiply would be much quicker! --Esp w/ add’l ghAddOns, “Multiply” can bring up all kinds of diff components, with the native basic Multiply being somewhere in the mix.

That’s similar to the node editor in Blender (especially when using Node wrangler), they use single hotkeys though, which means these commands are thus sent to Rhino instead. Only inputs with modifier/ FN keys and spacebar are not sent to Rhino. It would definitely be nice if you could opt which view is active by clicking on it once. That also saves many accidental keys being sent to Rhino.

1 Like

Yah, active windows is still a little glitchy in Rhino. For example, the Layer panel responds w/ mouse inside/outside (mostly) but the Construction Planes panel is sticky & I have to click back in the viewport to get to modeling again. I too have sent many random missives to Rhino command line from GH. I suppose polling mouse hover loc would be the way to keep it sorted.


@DavidRutten Any status update on Grasshopper 2? It’s been very quiet in recent months. Also, I assume (and seem to remember you saying) there won’t be any bug fixes/improvements done to GH1, right?

Sounds he is busy… I guess that’s good news :stuck_out_tongue:

I hope see something like this in Grasshopper, automatic connection when add a new component
and intelligent component which its inputs accept only the right data.


Hi Riccardo, what you say makes sense, but using booleans can be the most logical and direct thing to implement. Avoiding using booleans means enormously complicating the code (I also showed you something about it).

If I have a series of ribs (obtained by intersecting planes with an arrowed and twisted wing) and I want to create some lightening, for example, or extrapolate the movable surfaces, boolean operations are the most logical and direct thing, and here the user has little to do with it. In other cads, the operation is not so dramatic.

Obviously, if I can simplify I will do it, but it is not always the most convenient and fastest way, quite the contrary.

This is not true. We still fix bug and make improvements in GH1.