I am reporting both issues, as you say it looks like there is a conversion bug and the font size should work once the gh definition has been imported as a style.
We have been working about this issue. It is not a bug, it is working like this by design. Grasshopper definitions work with radians while Rhino files work with degrees, so that, when you import a Gh definition to create a Grasshopper Style, units are automatically recognized as radians and converted to degrees.
We are considering to add an option in the Gh style dialogue to choose which units you have used in the Gh definition. Would this work for you?
Hello!
Thanks! The Text component uses radians as input, right? That’s why I use a ‘Rad’ component in the script, to convert the input number to radians.
The input number itself is just a number (in this case an angle in degrees). Why should the number stored in this input parameter look different in the VA Element panel and in Grasshopper? In the Gh script, the number slider contained ‘30’. I saved this script and loaded it into a vaElement, and the number suddenly becomes ‘1718.87’. That does not make sense. It should display ‘30’, and the ‘Rad’ component does the conversion, right?
Edit: how does your vaElement+GH loading mechanism recognize this slider as an angle slider in the first place? Is it that smart?
When we designed the Grasshopper styles, we considered that Grasshopper components always use radians as the angle unit. We did the same: we created our VisualARQ components using radians, and we assume that all angle input params in GH are also in radians.
On the contrary, with length units, there is no default unit system in Grasshopper. It uses the same definition in the current document, so when you create a new style, we ask the user which length unit system is the definition.
1718.87 is the conversion from 30 radians (the value in the input slider) converted to degrees (30 * 180/𝜋).
We try to detect the value type from the name. If the name contains the string “angle”, we set it to angle by default. Unfortunately, it’s not easy to detect if it is in radians or in degrees.
As Alfonso commented, in VisualARQ 3, we’ll probably ask the user the unit system used for angles in the definition. It will be shared among all angle inputs. So it won’t be possible (at least in VA3) to have two angle inputs with different unit systems, just like currently it is not possible to have two different length inputs with different unit systems. All inputs in a definition should always be equal.
You can now “fix” your definition by chain the input slider to [-𝜋 to 𝜋] range and remove the angle conversation. (By “fix” I mean make it compatible with VA2).
Thanks, Enric! I understand, and the fix is easy. Anyway, I wonder why you do not just leave the conversion to the user and spare the guesswork? In other words, if the loading meachnism just takes the slider as is, it would work, no?
Because there are many definitions with radians as the input unit, and there are many VisualARQ users that just use styles and they don’t know what Grasshopper or radians are. They are used to “degrees”, and they want to see degrees in the parameter list.
You can also change the input from “angle” to “number”, and VisualARQ won’t do any conversion. But then, the “pick” icon in the parameter edit won’t be shown.
