Grasshopper

algorithmic modeling for Rhino

Add/remove component parameters depending on zoom level dynamically

Hello,

is there a way of adding/removing parameters dynamically depending on the canvas zoom level? I am trying to expose more parameters upon zooming in on a component.

Something along the lines

override OnPaintComponent(GH_Canvas ghC)

{

//somehow find my pManager

GH_Component.GH_InputParamManager pManager = this.pManager;

if (Grasshopper.CentralSettings.CanvasZuiZoomLevel < Grasshopper.GUI.Canvas.GH_Canvas.ZoomFadeHigh)
{

pManager.AddBooleanParameter("param", "P", "my new parameter", GH_ParamAccess.item);
}

if (Grasshopper.CentralSettings.CanvasZuiZoomLevel < Grasshopper.GUI.Canvas.GH_Canvas.ZoomFadeHigh)
{

pManager.RemoveBooleanParameter("param", "P", "my new parameter", GH_ParamAccess.item);
}

}

I think this works "manually" by implementing the IGH_VariableParameterComponent interface, but does it work dynamically? Has anyone had success doing that?

Thanks for any pointers!

Views: 1489

Replies to This Discussion

Although you can override the display as much as you like, you probably shouldn't be actually adding or removing parameters based on the view.

It doesn't sound easy though, and it does sound confusing. Users won't be expecting this behaviour unless you tell them explicitly it can be done...

Can you provide a quick sketch of what you want to achieve exactly?

--

David Rutten

david@mcneel.com

Hi David,

I've got a few components which just have too many inputs to look neat on the canvas.

Moreover, many of them are optional to the user and only required in special cases. 

Consider a custom finite element line with 

start point

end point

id

cross-section (optional)

local coordinate system  (optional)

some property  (optional)

some other property (optional) 

additional settings (optional)

etc 

Now in 99% of the cases, users will only specify the first 4 parameters and leave the others blank. I'm not a huge fan of to many inputs so to clean up the canvas/components, I thought about exposing the optional parameters only upon zooming in on the component.

So far I've sometimes added a secondary component with more inputs to specify a list of additional settings (similar to the "settings" panel that exists/existed in Kangaroo), but this I find rather messy.

Alternatively I guess I could quite happily live with exposing the additional parameters at the click of a button. This I can do with the ZUI as it is written? I still need to get my head round what's what in this happy world of the canvas' third dimension...

and voila a screenshot of the intended expansion functionality

Initially I thought zooming in would be nice to expose (or unhide) the optional parameters. But now I agree you might be right, an arrow button or similar would be nice to expose parameters which are often unused...

Of course this raises the questions as to what happens when input parameters are connected to something and the list is collapsed again - but maybe the ones with active connections are simply not collapsed back?

On the left the collapsed component, on the right the fully exposed version.

Attachments:

It would be fairly trivial to make the component 'unfold'. You'd still have to override the attributes, but I think most of the drawing and layout can be done by calling available methods.

Doing it through the menu allows you to get away without overriding attribute display, layout and mouse-handling. Perhaps that's a good place to start, then override the attributes later if you still want to.

I can upload an example of this probably later tonight.

--

David Rutten

david@mcneel.com

The attached code adds or removes parameters from a component menu. 

I didn't set a message yet, that should probably be done to signal to the user there is a menu option they should care about.

--

David Rutten

david@mcneel.com

Attachments:

Nice, thanks.

I've modified it such that it can deal with two open issues.

1. Inputs with sources are no longer removed when collapsing.

2. Inputs where a value had been set manually lost this value upon collapsing. This manually set value is now restored upon unfolding.

However, I've had to include a permanent list of parameters in the component, not sure if that's best practice. Wouldn't it be nicer to have a "Visible" flag with parameters where they would simply be omitted from the list (if certain permitting conditions are met), rather than registering/unregistering them entirely?

There is also an issue with the order of inputs changing when some are collapsed and some aren't. This could be fixed with a bit of brain though.

Sending a message could be done with GH_RuntimeMessage for now, but I might look into providing a little arrow button like I had in  my sketch when I have time.

Thanks a million, you have already brought me a whole lot further with this!

Attachments:

As a user I think multiple zoom levels would be extremely confusing. For complex options consider some of the other ways of dealing with this, some of which are a bit more  "grasshopper-style":

1. have a regular component and an "expanded" or "advanced" component with this extended functionality

2. have some of the custom optional parameters entered in a settings component (like mesh brep + custom mesh settings)

3. Embed some of these options (if they do not need to be dynamic inputs) as component menu items (like "maintain paths" in the tree branch component)

4. (not 100% sure this last one is possible but it should be...) use a component menu as in 3. to show/hide advanced inputs. As you say the problem of hiding inputs with connections is a bit tricky but I think the most intuitive behavior is to leave the ones with connections always visible as you describe.

lovely!

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service