Imagine someone was rebuilding Grasshopper today, no legacy constraints, just a clean slate and everything 2025/2026 tech could offer.
What are the things that absolutely need to stay, because they make Grasshopper Grasshopper? And what are the parts that feel outdated, clunky, or just get in your way these days?
Curious what people here consider untouchable classics vs. long-overdue rethinks. (Also feel free to mention any plugins or features that you now consider essential.)
Have you heard of Grasshopper 2?
Yeah, I’ve seen that, it’s been cooking for quite a while! Just curious what people would imagine in a real reboot. What would you change if you could dream big?
Grasshopper 2 is a complete rewrite, what would make it more of a “real reboot”?
I posted the same thing on Reddit, seems like the community has a few big things they want to see, currently not included int the rewrite as far as I know.
@Jan-niklas - you might encourage the Reddit community to post their wishes here.
– Dale
Draw full names!
I always dreamt of a better integration into Rhino workflow-wise. While the added Rhino tab in Grasshopper already provides some great functionality in version 8, I think it could still be way smoother and less convoluted.
The whole idea of importing geometry into and “baking” geometry from Grasshopper is pretty dated in my opinion.
It could potential be great to have a fast mode for setting geometry, where you would select geometry in Rhino, call Grasshopper, and it would put everything selected on the canvas. There could be an interstitial menu to select grouping modes and stuff.
And Grasshopper in a viewport inside Rhino, much like the node editors in many other CG applications would be cool. The floating Grasshopper window could be made optional and vis versa.
I get that the whole graph/tree-based data processing logic inside Rhino is meant to make loops unnecessary to a degree, but it would still be great to have a dedicated system for looping over data.
Yes, there is Anemone, but I think it could be done better, maybe loops being able to process only clusters, like scoped logic in code. Or looping over external Grasshopper files to run their contents.
Another thing that could be useful and similar to what I mentioned above, would be headless Grasshopper scripts to be used in Rhino. You could have different snippets and map them to commands and/or buttons to transform them into Rhino functionality. Just imagine having a Grasshopper script that produces parametric doors and you could call DoorGenerator in Rhino select a plane/point, a width and height and it would simply put in a door, without even opening Grasshopper.
As a Grasshopper user I cannot align my text Right or Center.
Yet I must gaze upon the greyed-out option.
This is the law of the panels.
I, for one, would like to assign User Text attributes to subobjects like surface edges, polycurve segments and points.
And my hole os that for GH2, model objects will be the norm, so any model curve that is trimmed, extended or exploded will be propagated to its resultant objects (i.e. metadata is preserved after geometric changes).
Just enable multiline, set your alignment, and switch back. You have to be smarter than the computer.
Other ideas include embedding/ linking a Grasshopper definition to geometry. Then if you select the geometry you get access to exposed parameters, similar to the Remote Control Panel that could then be used to drive said geometry.
History could be made akin to Alias’ Query edit, which then allows you to visualise an object’s history as though it was modelled using Grasshopper nodes. This would allow for changing the way an object was created by changing input parameters in its history chain.
Embed it on Rhino and make buttons for those commands on Rhino, slowly but surely getting forward to make Rhino a real competitor for other mechanical cads. No need to ever see again that interface, just use it with Rhino toolbar buttons…draw a parametric line.
The canvas precision should also be increased, too often all my components shift around when they are a bit further out from the origin. And something like Snapping Gecko should be built in.
The biggest hurdle for me using Grasshopper is that commands that always work in Rhino often fail in GH using the exact same parameters. This forces people to take huge detours. The reason for this is that lots of the commands in GH are actually very old versions of their in-Rhino counterparts. If GH is coded in such a way that it makes it impossible to use updated/improved Rhino commands that’s a pretty huge limitation. Even in ancient AutoLISP I can use the latest and greatest AutoCAD commands.
The next biggest hurdle is that so much stuff has names that just don’t click. I’m constantly looking up stuff. And constantly looking up stuff relating to McNeel can sometimes be slow. Better in-app help I guess or a single go-to source that answers any and all questions.
I see it extremely clearly: Not a lot of stuff has been created with GH. A few standouts/outliers have created some really good plugins but only a few and this after over a decade.
I’ve said it before, but considering the hoops people jump through to make GUI’s for Grasshopper/the amount of third party plugins that attempt to provide what ought be native functionality (IMO), abandoning the Remote Control Panel feels like a substantial fumble (that hopefully will be rectified in GH2🤞).
This is already available, either via Grasshopper Player or compiling your GH code into a YAK plugin using the script compiler/script editor.
Cheers
DK
I would rethink the concept of datatrees. (probably 2/3 of the problems posted in grasshopper category in this forum are related to issues based on the combination of data and (array / nested list) logic).
introduce some kind of custom combined data, structures / dictionaries.
polygonal wires by default.
allow to color and name wires.
There are so many programming paradigms and patterns that can not be implemented in Grasshopper - look at those and offer stuff to overcome this limitations.
a very simple first step would be, that clusters allow a fixed signature (item, list, tree acess and typing) - see this topic
@Jan-niklas what s the background of your question ?
I think from my experience, these are some potential improvements:
allow esc to cancel computation of current solution
