Finding parameter names on Shapediver

Is there a way to find out the exact parameter names on Shapediver?

If I go to “Edit Model” I can change the names of the labels, but I don’t see what the actual parameter is called. If I want to use updateAsync in the API I need to reference the actual name of the parameter.

If I hover over the label in Shapediver it is giving me some rather unneccessary info like “empty Goo parameter” or “this parameter is currently inactive” (it isn’t)



Since on shapediver for some reason you use CSS to convert everything to uppercase letters, you can’t even tell how the name was spelled in GH. Btw: from a UX perspective making labels uppercase is not good and totally unneccessary. It just makes it harder to read things.

It would be nice if the tooltip for example could show the actual parameter name. That way I don’t have to open GH just to find out what it was and how it was spelled.

Or is there an easier way?

Perfectly illustrating why changing the case of the parameter names is not good:

After taking the screenshots I was wondering why my model wasn’t working as before. After a while I realised that the parameter name IS actually what you enter on Shapediver and that without me knowing it had changed the parameter from “Size” to “SIZE”.

That now meant all my javascript was broken. Rather surprisingly if you have any of the parameter names spelled wrong in updateAsync it doesn’t update any of them.

So please take off the ridicolous “text-transform: uppercase” from the Shapediver platform if parameter names are case sensitive and simply clicking to edit a name will then actually update the parameter to be uppercase, even though before it wasn’t uppercase but was displayed in uppercase.

You can see now why that is a really bad idea.

It gets worse:

If I change the parameter name to “Size” and save the model the actual parameter name is now “SIZE” and updateAsync no longer works when I target “Size”.

In the model viewer on Shapediver if I inspect the name is now changed to “SIZE”.

It appears that as soon as you edit a parameter name it will always save it with the uppercase version meaning it will break all your javascript implementations that try to update that parameter. If you don’t click to edit a name it will keep the case that came from GH.

On Shapediver it should only be the Label that you change, but never the actual parameter name.

Even without the uppercase Bug that is a terrible idea, especially since that is not explained anywhere.

When editing the model I enter “Size” and press Save Model:

When I am in the viewer you can now see it has actually saved the parameter name as “SIZE” though:

If I go back to edit the model the parameter name is now uppercase.

@mathieu1 I think this is a pretty serious bug, could you take a look at it please.

I would recommend for now to always use only uppercase parameter names then at least it wont break in your javascript.

Thanks for the thorough investigation of this topic. I couldn’t agree more regarding the styling issue and the fact that it forces uppercase names for the edited parameters. We will definitely improve this point.

At the moment, the tooltips just pull the additional information that Grasshopper sends for the parameters. Our plan is to let users define in Grasshopper meaningful information about them, but this is not implemented yet.

The whole renaming process can be improved, however there is already a way to handle parameter changes in the API. Bear with me, because I am aware it is not the most straightforward and again, this will be improved. But it should allow you to implement a robust connection to the parameters, with safety checks for parameters with updated names:

As long as a parameter has not been edited in the ShapeDiver Edit mode, it will only contain a name property, which contains the name defined in Grasshopper. If the name is updated, the property will reflect the change, but an additional _name property is added to the parameter which will always contain the initial Grasshopper-defined name. To make this more convenient, we will always include a _name property in the future, because at the moment you will have to check if it exists and use name instead if it doesn’t.