Grasshopper

algorithmic modeling for Rhino

Hi David, would it be possible to add built-in parameter components in clusters? I mean, giving the user the ability to chose between the current input-hooks UI and one which includes button-styled parameter components, like in the attached "Cluster2" image?

I'd like to see this feature for two reasons:

  1. I use to make user objects out of clusters to have them ready to drag on the canvas from the toolbar, it would be nice not having to reconnect every input of the cluster to a new component each time I add one. Yes, I can always copy and paste a previously made fully connected cluster and set new parameters, but even if I align components carefully and group the whole thing before copy/paste I end up with slightly misaligned items in the pasted group. The misalignment spreads and increases across the siblings as I continue duplicating groups, so at a certain point I have to re-align the components within the groups.
  2. Wouldn't it be easier to single click on a button to set a parameter, say a curve, instead of right clicking the component (or the cluster's hook), scrolling to the action you want to perform and then click again to select it? The rmb context menu could still be available though.

Maybe the attached images explains themselves better

Views: 1742

Replies to This Discussion

That same pattern occurs quite a lot with scripting components. I've been thinking that perhaps it makes sense to be able to "dock" the basic inputs params (i.e. boolean toggle, button, slider, value list, panel etc.). I'm not sure how this would work, but it does seem like something that could be useful across the board.

But this only allows you to use this cluster for a single value of certain inputs. That can be quite limiting factor.

I was thinking of a possible new feature of the cluster input component, you right-click on it inside the cluster and select a "type hint" like you do on scripting components; this turns the current hook in a button, a slider, value list etc.

My english is poor, so I'm not sure I understand what you mean when you say it could be a limiting factor, but I think it could be quite useful for clusters performing a specific task like the one in the picture which actually just bakes cross section curves for blend surfaces.

I mean that if you replace a number input with an in-place slider, you can only supply a single number, rather than a list of numbers. Of course the solution would be simple; allow people to switch from slider input to regular input, or; if wires are connected to the input then the slider disappears automatically. 

Such a feature would be lovely to have on regular components as well, not just clusters.

Something like this became possible over the years?

Actually Samuels second picture would be exactly what I need right now.
Or is there a way to deconstruct clusters? than i could make a cluster with all the sliders and toggles, save it as user object and when its back in the canvas i'd probably deconstruct it.

I haven't tried BrickBox but I watched the video and it doesn't look like the same thing at all.  I want UI controls on the surface of a password-protected cluster because the UI is an integral part of the proprietary algorithm.

The idea is to provide useful functionality to people who have no clue about Grasshopper and never will because they are "users", not developers.  A lot of this mess could be contained entirely in a single cluster if not for the requirment that UI components must be wired externally:

I have long wished for the ability to build UI controls into a cluster.  Ideally, UI components internal to a cluster would have a special "export" property that makes them accessible externally, as in the 2nd image.

Of course, it would then be nice to arrange the UI "external" UI components on the surface of the cluster.

I don't remember specific examples at the moment, but have encountered cases where it's extremely awkward to build a proprietary cluster with UI controls embedded in the algorithm.  I worked around it by splitting the code into two clusters but it was far from a satisfactory solution.

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service