Improving optional/settings parameter provision

[philipbelesky]

It is possible for Grasshopper components to offer toggles in their right-click 'contextual' menus. While in general it's useful for parameters to be explicit as inputs, I think there's a case to be made that the different options for coloring the mesh made by Sandworm would be better placed within a menu rather than a parameter with a magic number. Doing so would be easier to interact with and I don't think there is an obvious use case for the color style to be parametrically controlled. Implementation is pretty simple and described here.

If implemented, the baseline options could include:

• Elevation height map coloring (i.e. default behaviour)
• No coloring at all

Additional options that could be presented as toggles within that same list:

• Variations on the elevation heat map, i.e. black/white or Provide pre-defined colormaps #19
• An elevation map without the 'water' level
• Slope and aspect analysis (Implement slope analysis on the mesh #13)
• Contours, potentially. This could also be a separate toggle (i.e. could be used in conjunction with any of the above options)

This implementation wouldn't provide a means to more explicitly control any parameters in the above options. Some currently-hardcoded parameters (like max depth/height) wouldn't apply to all of them either. A dedicated 'color options' component, as used by Ladybug and the like, could potentially be used for this kind of flexibility if/when the defaults need to be more explicitly controlled. The other option might just be to have separate components for each flavour of analysis and then directly expose relevant configuration options as parameters.

[mariuszhermansdorfer]

Some loose thoughts on UI.
While right-click switching between different analysis modes, we'd potentially have some redundant sliders hooked up to the main component. How about introducing intermediary 'options' components, which would allow users to control the input parameters?

We'd set everything to be optional and provide reasonable defaults to just plug & play.
If a user wants to have more control over, say, the contour line interval, she'd then plug the 'Analysis Options' component into SW. It could look like this:

It would be nice to allow users to add/remove these via the VariableParameterComponent Interface. I.e. if someone only cares about slope analysis, they can remove all the other options by clicking on the minus sign to reduce visual clutter.

Something to think about while setting up #23

[philipbelesky]

The sketch of the different setting types makes sense. One thing to note is that I'm pretty sure its possible to dynamically add/remove input parameters to a definition via its internal logic.

So it could work that the 'main' component starts of with a very minimal set of 'core' options (e.g. sensor height and columns) along with inputs for the specialised settings components. Then, if an analysis mode is selected that requires basic customisation, any necessary input parameters could be revealed (e.g. water level or contour interval). Alternately, if one of the specialised settings components is wired up, any redundant input options could be removed from the core component itself. That might sound a little unintuitive, but could be worth trying out as a possible best-of-both-worlds.

[mariuszhermansdorfer]

I was thinking about automatic adding/removal of input parameters. How would you solve the case of switching between analysis methods?
Say, we start with simple elevation banding, then add contours -> a new input parameter for contour interval appears. We wire a slider to it.

Then we switch to slope analysis and turn off contours. A new set of input parameters for min max slopes should appear and the contour interval input param would be destroyed.

Now we're done with slope analysis and want to switch back to elevation banding and contour display - we need to re-wire the interval input.

I think automatic creation of input params is a very good idea. They shouldn't be automatically removed, though. Rather, we should allow users to keep them wired as long as they are switching between different analysis modi, and remove manually via the zoomable interface (clicking on the small minus when no longer needed).

Thoughts?

[philipbelesky]

Hmm, I guess in that case a rule along the lines of 'never remove optional input parameters unless they have no inputs' could work, as you suggest. That, at least, keeps the first-run experience clean as complexity is only ever built up over time. Definitely in need of a prototype though — I'm not sure, for example, how that kind of dynamic parameter persists between opening/closing a definition.

[mariuszhermansdorfer]

Sounds good. Would you explore this further as part of your experiments?

[mariuszhermansdorfer]

Took a quick stab at user-defined color ramps. Works all right, but I'm pretty sure the code behind it could be cleaner. The amount of sliders is growing :)
https://youtu.be/0cUL_63J7xs

To do:

1. Investigate why transparency is not working
2. Prepare a few thought-through pre-defined color ramps, so that users can just switch between these.

branch available here

[philipbelesky]

Just a heads up that I've relabelled this issue to track the broader aim of having a series of config/settings components (rather than the specific goal of the right-click menus).

[mariuszhermansdorfer]

Closing this since the majority of the above discussed ideas have been addressed in separate issues/PRs.