Grasshopper

algorithmic modeling for Rhino

(Edit. David sez: Please append your (well explained) ideas/suggestions/wishes. I don't care much for what you want, I care why you want it.)

Perhaps this topic has been covered recently, but I don't see any active threads.  We're looking for a plugin project and I'd like to get some feedback from the power users before choosing something.

So...

What is missing from grasshopper?  

What would you like to connect to that you can't already connect to?

What kind of bottlenecks do you run into?

What secret wish do you have for Grasshopper that doesn't even seem possible?

What project have you been meaning to undertake but haven't had/won't have the time?

Just trying to brainstorm a few ideas here.  There are so many great and useful plugins out there, it's hard to discover the gaps anymore.   

Looking forward to your thoughts!

Cheers,

Marc

Views: 26628

Replies to This Discussion

Thanks i will try it out. I would still like to see it implemented in Grasshopper since it is a key function for parametric design.

All,

(comments from a low power user of this rather awesome program)

S,M,L suggestions, which may or may not have been mentioned elsewhere (apologies for duplicating if so)

1) Small:

Path mapper:

Could there be a generic number input (or several using the little 'plus' buttons) to allow a variable (or variables) to be used in the component (x,y etc similar to evaluate function). I've seen workarounds for this which bypass the PM altogether, but it would be so much neater to contain it all in one? Could make it all powerful?

2) Medium

Disconnection and navigation:

a) Disconnecting a/several component(s) using just a straight drag onto a blank section of canvas. (Right click disconnect is a bit clunky if more precise when dealing with multiples, obviously retain this).

b) 'Charging' - when connecting two components that are miles away from each other, the hold-down and drag-pan approach can be tedious. Could charge-hold a connection (maybe a mouse-click + modifier) then be free to navigate to the target and 'discharge' the connection into it. A useful global zoom All and single click zoom back in shortcut could help with this. (think Mac Desktop: mission control)

3) Hard:

Ability to click GH geom in the Rhino viewport and highlight the corresponding component in GH. Where GH geom is overlapping, employ similar 'list-pick' to rhino; perhaps use with  auto zoom/pan to relevant components in GH on highlight in list.

Keep up the good work

R

Hi Ralph,

all good suggestions, one question about picking. Do you want GH preview to act just like regular objects? I.e. picking always works, you can select GH preview geometry while inside a Rhino command, components get deselected when the user clicks somewhere else? Or is it more like a specific command you run first which then allows you to pick some objects?

David,

 

Speedy reply... At the risk of opening a wormcan on this, I was actually being quite narrow in my scope in terms of picking. In all honesty I use Rhino principally for GH.  So I was meaning that the GH model 'preview geometry' become always pickable, in order to aid navigation of the GH definition. 

 

so something like this maybe:

 

in Rhino window:

 

LMB on GH geom - highlights the geom (by highlighting and centering on the component that created it in the GH canvas)

If multiple geom is beneath selection point > open select from list similar to vanilla rhino > as scrolling through list, GH canvas highlights and centres each in turn. If no selection made initial GH canvas view reinstated.

RMB click on GH Geom > auto centre and highlight as above and display right click dialog as context menu in the Rhino viewport.

MMB click on GH Geom > middle button context menu appears in rhino viewport

 

It may run the risk of navigation being a little, well, intense... but could help perhaps when picking up an old definition or trying to navigate someone else's.

 

(One possible extension of this, which CATIA uses, is a 'swap visible space' command. This has its uses but can get pretty cluttered). With this you can navigate the hidden components of the model in the same way as you would the shown ones without relentlessly showing and hiding things). 

 

Coming from a hacked-around-with CATIA, it felt constricting that the visible GH geometry was a ghost. I still often struggle to find whereabouts in the vast acreage of my (doubtless excessively baroque) definition the GH objects visible in the Rhino viewport are located. I guess it is about completing the access loop from the GUI to the Geometry and back again. Currently it runs one way only. 

 

So in brief yes, picking always works, but I wasn't thinking about this in terms of Rhino commands. To date GH's interoperability (or lack of if this is the case) with native Rhino functions is not an area or limitation I have encountered. 

 

best,

 

R

note:

Illustration of the path mapper suggestion/request for workarounds here

R

Using and arranging sliders, boolean toggles etc. can be annoying from time to time.. Some kind of automatic "magnetic (alignment) field" in the GH interface would be awesome and help a lot and save time! The boolean toggle, button, value list etc. should also have the same height as the normal slider - why not!

I think what you are looking for already exists. If you select multiple components (any components), then you get the arrows on all sides. The top and bottom ones and left and right ones are the same.

Top and bottom ones are align left (arrow left), align right (arrow right), align centrally (middle button) and distribute vertically (the lines icon).

Left and right ones are align top (arrow up), align bottom (arrow down), align centrally (middle button) and distribute horizontally (the lines icon).

Nope that's not what i'm asking for... That's the existing time consuming solution.... Often when I/people have multiple sliders/boolean toggles/... they should almost always be grouped, it should be done automatically with some kind of "magnetic allinenment field." It should of course be possible to change/disable the "magnetic allinment field" - But thanks for the suggestion anyway..

Thomas, agreed. Being an anal retentive myself, I spend far too much time aligning and spacing and resizing objects to the canvas. The horizontal wire snap introduced in the last release is the first attempt at providing contextual layout tools, and it seems to prove the concept. I just need to hook it up so it works while dragging multiple objects, and it snaps to box alignments and spacing alignments too.

Awesome! The horizontal wire snap is a TIMESAVER! I personally think it should be possible to control/disable the snap sensitivity globally in preferences - GH settings. Please resize the toggles to fit with the sliders / between multiple component inputs.

So when working on large grasshopper projects I start using grouping and clustering a lot. Both are not on par with the UX of the rest of grasshopper and are just really annoying to use, but the only way to organise everything and keep some sanity.

Grouping:

1. Multiple levels of grouping! - nesting groups at the moment is just really messy and basically is so bad that it should be disabled to even be possible

2. Alignment and distribution for groups would be nice

3. Coloring of groups is just so bad, because you cant save swatches or something like "recent colors". I like to color all the groups and related groups should have the same color. Eyeballing the colors all the time just makes my "designers eye" bleed.

4. Editing multiple groups - one way to solve problem 3 would be to be able to edit more than one group at once. If I select 2 groups, right-click and set a color I would expect both to change color. At the moment only the last selected group is affected.

5. Group Notes - would be great to be able to add notes/comments to groups. Like a little pop-up thingy. Using Panels to store notes just seems like a workaround.

Clustering:

1. Cluster Input and Output Components are just so misleading. You can rename them, but it doesnt rename the the actual input and output, because the name is derived from what you connect it to. When connecting something with a different name, the cluster input/output visually changes name inside the cluster, but not in the cluster itself. That way you can end up not knowing what input is what, because they have different names. Always having to recreate inputs/outputs is really annoying. This is especially apparent, when creating a cluster from a bunch of components. All the inputs and outputs are just the single letters, very often times the same letter. I then have to go through and rename and recreate ALL the inputs and outputs, making it actually quicker to build the cluster up from scratch, rather then the automatic method.

2. When I select a bunch of components and they have multiple inputs, but they come from the same component outside the cluster, then it will create an input for each one, even though only one input would be needed, which then connects to all the relevant inputs inside the cluster. So you end up with multiple inputs that all have the same thing connected to it.

3. In cluster properties there is a "Name" and "Nickname" field, but I have yet to see anything but the Nickname anywhere. Why 2 different ones and where is the "Name" used?

I am aware these issues are only relevant when you are working on larger sketches. But you know, sometimes things just get quite big. This is what I am working on right now:

I don't like the cluster color.. I like the indication that i'm working inside a cluster but I think the blue color is a bit too much.. (again.. preferences - grasshopper settings!) Working with a huge project i have multiple clusters inside other clusters (inception style) I would be nice to have some kind of indication "the depth/level" i'm working.. Perhaps have some kind of "quick overview" shortcut or just a number indication in the corner of the canvas would do the trick. ;-) 

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service