Pain Points in Grasshopper

Replies to This Discussion

Permalink Reply by dim gimi on December 9, 2014 at 8:26am

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.

Permalink Reply by Ralph Parker on December 15, 2014 at 12:15pm

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

Permalink Reply by David Rutten on December 15, 2014 at 1:04pm

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?

Permalink Reply by Ralph Parker on December 15, 2014 at 3:10pm

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

Permalink Reply by Ralph Parker on December 16, 2014 at 10:53am

note:

Illustration of the path mapper suggestion/request for workarounds here

R

Permalink Reply by Thomas Perkov on December 19, 2014 at 6:38am

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!

Permalink Reply by Armin Seltz on December 19, 2014 at 7:39am

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).

Permalink Reply by Thomas Perkov on December 19, 2014 at 7:51am

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..

Permalink Reply by David Rutten on December 19, 2014 at 7:52am

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.

Permalink Reply by Thomas Perkov on December 19, 2014 at 8:03am

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.

Permalink Reply by Armin Seltz on December 19, 2014 at 8:01am

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:

Permalink Reply by Thomas Perkov on December 19, 2014 at 8:13am

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. ;-) 

• ‹ Previous
• 1
• …
• 14
• 15
• 16
• 17
• 18
• …
• 22
• Next ›
• Page