ShapeDiver: What's the logic behind sliders' order?

Is there a logic in the order of the sliders that ShapeDiver is importing and visualizing? Reordering of the sliders in SD is very boring and long process, most of all if you have many sliders. Maybe ShapeDiver is ordering them from top to bottom of the coordinates in the GH canvas? or from left to right? or also from the moment in time that sliders was added? or also from capital letters. I don’t know!

I only found this topic: any news?

There is a logic, but it is unpredictable right now so later this year we will have more tools for you to be able to organize the menu easily. In the meantime, if you make use of the API, you can create your own User Interface and there the order of your parameters are completely under your control.

Okay, I think I have to get more into API for use ShapeDiver at its maximun capability.

Should we keep the topic open and wait for news? if not I will click “solved” button. :wink:

We can update you about this via the forum.

It would make great sense, IMHO, for ShapeDriver to organize inputs (sliders, value lists, toggles, etc.) by GH canvas groups. For example, if I post the following GH model to SD:

It would be nice to see inputs organized like this:


  • SLIDER: size
  • SLIDER: thickness

GROUP: Ellipse, Rectangle or Custom opening

  • VALUE LIST: (unnamed in this model but should be…)
  • VALUE LIST: (unnamed in this model but should be…)
  • SLIDER: ID_h
  • SLIDER: ID_v
  • SLIDER: rabbet
  • SLIDER: Radius

GROUP: hatch

  • SLIDER: bevel

GROUP: rabbet / “coaming”

  • SLIDER: rabbet width
  • SLIDER: fillet
  • SLIDER: inset
  • etc. (NOTE: some parameter values in the GH model are not surfaced as sliders)

A related issue, though perhaps deserving it’s own thread(?), is why sliders defined as REAL, not INTEGER, are presented by SD as INTEGER sliders? SD clearly knows better since the proper type is displayed when you hover over the slider names. Example:

We already have plans to allow grouping of parameters in the ShapeDiver interface. Our current strategy is to use a “ShapeDiverParameterGroup” component where one would have to connect all parameters for defining a specific group. However, your suggestion to use Grasshopper groups makes total sense and we will review its feasibility. Both options could be available with the following precedence rule:
ShapeDiverParameterGroup >> Parameters inside a Grasshopper group >> Position of the parameters on the canvas (lexicographical order on their (X,Y) position for example).

Does that make sense?

What do you mean that sliders are presented by ShapeDiver as INTEGER sliders? In the model you linked, I see only one integer slider (called ‘Size’), all the other ones have a floating point accuracy.

Can you give more precisions about this issue?

I see the floating point numbers too but when I move any slider, it gives only integer values.