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.
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
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.
Sorry, my bad. I think I saw a few issues that were set to be done for GH2, which probably threw me off.
I can see that there are different tags for the targeted version of Rhino and a few are for 7.x a lot for 8.x and then a few of the major bugs for Grasshopper 2.
Does that mean we wont even see GH2 in Rhino 8?
We don’t have a strict policy on release targets in our youtrack database. People use this mostly to set their own personal priority list and these targets change over time. I wouldn’t put a whole lot of faith in anything with a target higher than 7.x as we aren’t good at predicting the future.
Fair enough, that makes sense.
Nevertheless it would be great to hear some official statement from McNeel regarding the roadmap for GH2 (I think there is none at the moment) - or shall we assume that it might never really come to fruition or at least not in a next few years ? Don’t want to sound bitter or anything it’s just GH1 feels more and more dated and constrained and some of the thing (like code editors on Mac version for example are looking like a quick’n’dirty fixes rather than fully developed tools)
There are two separate topics here
GH2 will be released as a work in progress build running on Rhino 8 at some point in the future. Features for GH2 will be added and improved during this WIP period just like how Rhino has a WIP period.
GH1 will also continue to be improved upon during Rhino 8 development. Code editors in general are being rewritten in Rhino 8. The new code editors will be integrated into GH1, GH2, and Rhino.
ok, thanks for the update, good to know there is some work still going on in terms of some underdeveloped aspects of GH1, thanks !
It would be awesome to have grasshopper 2 and the next versions of Rhino working with Iron Python 3.4. To be honest, it is quite a pain to connect another python interpreter or to adapt libraries back to Python2.
Do you have any contact at the .Net foundation with any idea to help ?
Please let it be possible to save say a group of components / a definition to the toolbar to use later. Rhino already lets users customize the toolbar with their own buttons, would be nice to see this in grasshopper as well. Means the definitions I use regularly don’t need to be created from scratch the whole time and can instead be saved to & pulled in from the toolbar.
Please - the option to change parameters on a node and choose SET AS DEFAULT. It’s crazy the amount of times I need to change the same thing over and over because I always use a node in a certain way.
I don’t even mind if it changes color or has a little icon to indicate it has a new default status.
You can already do exactly that. Place a component, change the values, File > Save user object, choose a tab for it, you can also create new ones, done. Now you place that component it has the values you set in there all the time.
For the question above: either cluster things together and then save as user object or use the Metahopper plugin that lets you save a collection of components. Just select a bunch of components then go to MetaHopper > Save Snippet… and then its the same as save user object, but for many components.
For this I regularly use snippets from metahopper. It allows you to save grouped components forming a ‘function’. You can call this back anytime by typing in the saved name of the snippet.
But yes, it would be nice to have it baked into grasshopper directly