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:
Maybe the attached images explains themselves better
Tags:
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.
Also BrickBox allows you do that.
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.
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by