Pain Points in Grasshopper

Replies to This Discussion

Permalink Reply by Nick Tyrer on June 10, 2014 at 9:28am

Duncan,

If you double click on the canvas, and instead of for example typing 'slider', you can type a value and it will give you a slider with that as the value. Or with a " in front of the value to put it in a panel. This is by far the fastest way to enter any value you want.

Alternatively if you want specific present values can you use 'point on curve'

Permalink Reply by Duncan W on June 11, 2014 at 5:44am

Well I don't always want to have to specify a number or slider. GH should do this automatically. For example with List Item, a slider should automatically be set for i with respective bounds, and should be available maybe via hovering over the i on the component. The same would be useful for Tree Item, which ideally would not be limited to trees with just one branch. I guess if you create more intricate text input you can control several branches with sliders on Tree Item, but really, it's just painful, as the topic title says.

Permalink Reply by Steve Moody on June 10, 2014 at 6:58pm

I'll second the request for better naming consistency, I know that this has been an ongoing process of renaming stuff through the last few updates, but there are still some strange inconsistencies.  I'd also be very happy to see a better search algorithm - I like that I can type "con pl" to get the Construct Plane node, but it is not always so intuitive. Lastly with names, I prefer to work with the images displayed on the node but my office works with the text labels, and it has always bugged me how many of the smaller components get so much bigger to fit the text, seems like the component should stay the same size and the text scales to fit.

I'd also like to second the request for a better way to stop the solver while its calculating. I can't count how many times I've accidentally connected a node in the wrong spot or with the wrong data structure and ended up trying to calculate 1000000 solutions instead of 100 and being to forced to wait or kill the the program.

The formatting options and margin editing tools that appear on panels when you zoom in are useful but are also extremely annoying when you're trying to resize or move the panel and you cant actually grab it or see what's in the panel.  Perhaps an additional step like a button in the corner or just hovering over the panel for a second before that stuff pops up would be a good solution.

I'd love to see some better preview options.  I usually end up having to bake things or put them through the geo pipeline just to actually see them.  Trying to see curved surfaces and things made up of many smaller pieces of geo is nearly impossible without baking. Even just thickening the edges of surfaces like rhino's shaded view and making them a contrasting color would help a lot, though some better shading would be awesome too.

Last one for now is making the panels a little more efficient. I often deal with very large text files in grasshopper, both reading and writing, and the panels are surprisingly slow displaying that text, to the point where it freezes up for long periods of time. This also applies to the preview that pops up when hovering the mouse above a parameter on a node.

Thanks for listening and continuing to do such amazing work on this software!

Permalink Reply by Moonbeast on June 10, 2014 at 7:59pm

Ability to open grasshopper definition in locked mode from rhino, grasshopper_lock in command line

Permalink Reply by Ola Jaensson on June 11, 2014 at 9:12am

A few more mixed wishes for GH:

1. Expression input on math operator components. Maybe superfluous, but I'd use it twenty times a day to simplify simple things.
2. Solving of input expressions before type-hint based conversions take place. It would make a lot of those bulky point decompositions go away, when you only want the Z part.
3. Global variables. Could be a right-click choice on a nicknamed parameter, then the nick could be used in input values/lists/expressions. Could make any definition into a perfect mess, but very useful in the right definition. Hidden wires are good, but usually more of a workaround.
4. Boolean operators working on integers and strings (that could be interpreted as binary numbers). I don't plan to make a native GH C64 emulator, but you always need binary numbers and ways to work with them.
5. If no completely input-controllable sliders, at least an index selector, with a right-click choice of reaction to trees and wrapping (one slider for all (longest/shortest list) or a changing genome-like list of sliders)
6. A user adjustable/ignorable warning level when you're about to make a connection that will result in a zillion combinations (because you missed a graft perhaps?), with the choice of abort, continue and save before connecting.
7. Does the GH solver and UI live in different threads or the same? Could they be separated, so that the UI could kill a computation gone bad?
8. A report of plugins used in definition, with highlighting of the individual components (I'm always losing track of what I'm using where).
9. Spreadsheet/2d list panel. Like the text panel, but showing resizable columns too. Editable. Would be very useful in debugging data trees, even if the final definition will draw its input from Excel or somewhere else.
10. Associative arrays. Maybe the sets are being developed in that direction?
11. A new seed value each time you place a random/shuffle etc component. Repetitive randomness is usually not expected, especially not by new users.

 

Not very plugin related wishes, but this thread seems to be the general GH wishing well at the moment.

 

Thanks for a great tool, David!

And thank you, all plugin developers!

 

/ola

Permalink Reply by Danny Boyes on June 13, 2014 at 4:28am

This would be my pain point suggestion.

I know you've talked about doing something in GH2 about plug-ins and missing components. SO if you haven't had much detailed thought about it then this could be an idea for the mix.

Either have a context menu facility that draws the place holder or have it triggered upon loading a file without the required plug-in installed.

EDIT: I don't wish to have an automated plug-in installer just the knowledge of where to get it if its relevant.

Permalink Reply by David Rutten on June 13, 2014 at 6:22am

What would be wrong with an automated plugin installer?

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on June 13, 2014 at 7:03am

I see a security risk in that approach. At least you are able to make a very conscious choice to go and get a plug-in and see that others are using it and why They are using it. If it was automatic someone in the organisation might blindly click away and end up with "heaven forbid"  some malware. I usually open someone's file see the errors and think ok I don't actually need that to get this working. Only if there is no other way to get the gist of a definition will I instal the plug-in ,not because of a security risk but because I'm too lazy to then get rid of it. And the bar keeps growing

Permalink Reply by David Rutten on June 13, 2014 at 5:07pm

My ideal solution would be that GH detects you're trying to open a file which contains components you don't have, at which point it asks you:

"Hey, you need to install 'Kangaroo' to open this file correctly.
 - No thanks, please open the file partially.
 - Yes please, but only install Kangaroo for this session.
 - Yes please, install Kangaroo permanently."

where option two doesn't even allow you to create new Kangaroo components and it won't show the icons on the tabs.

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on June 16, 2014 at 2:56am

Yeah I can see that would work.

Permalink Reply by Brian Harms on August 8, 2014 at 2:59pm

This would be amazing.

There have been so many times that I've tried to share files with other people (friends, students, coworkers) that require other plugins. What I try to do is capture all the functionality of those foreign components in some of my own so distribution is less of a hassle. But many times the components made by others in their plugins do their jobs much better than the quick ones I whip up just so people don't have to go hunt down lunchbox, firefly, kangaroo, etc. for the one or two components of theirs that I used.

I would love this (for myself as well!)

Permalink Reply by Arend on July 8, 2014 at 2:25am

I think the risk of a plugin is much smaller than the 50 yard security gap that is created by password obfuscated components that still execute C#. I'd like a paranoid mode for grasshopper in that sense:

1. I wouldn't want to execute arbitrary C# code from a definition I can't check.

2. In analogue to the lock solution, a 'lock C#' button would be useful.

In terms of use cases:

- when doing education I typically open a lot of files that I've not created myself.

- what is preventing someone from posting malicious scripts in the forum?

Attachments:

• C# In Password Protected block.gh, 16 KB

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• 8
• 9
• …
• 22
• Next ›
• Page