generative modeling for Rhino
here i have a bug, and take this opportunity to add some wishes
bug/error: working with integer component + expression.
it's a bit late for any high quality thinking, I'll get to your wishes tomorrow.
In the mean-time, the reason Int+1 fails is because there is also a function called Int(). I'm not sure if it's a good idea to allow variables and functions with the same name to co-exist. It might be, I'll do some tests to see if it results in ambiguous cases.
Another part of me thinks I should always use x as a variable for parameter expressions, like I do with sliders now. Makes it a lot easier to copy expressions and use funky names for parameters.
"Another part of me thinks I should always use x as a variable for parameter expressions, like I do with sliders now. Makes it a lot easier to copy expressions and use funky names for parameters."
Yes, but now would be weird to unlink the input/variables names (very usable the way it is) It may be easier to change the default name of the integer component (as sine, cosine, etc. that has x as a name, as you suggest)
thanks for the fast reply.
I can change the name of the Integer parameter, but it still doesn't allow you to name your parameters any way you like. You can't use spaces, can't start with a number, can't use special characters. Every time you rename a parameter you have to also adjust the expression. And every time you copy an expression from another parameter you might have to change the expression.
Using "x" everywhere seems to solve all this in a single stroke. Like with sliders, I'll have to keep support around for the old names, otherwise all files that use expressions no longer work, but that can be a hidden feature.
i agree, but i meant the possibility to add an output parameter to texts components.
Yes please! I've been working on a project with upwards of 1200 groups of object which need to be nested onto sheets and cut on a cnc (the objects need labels). We have been using a little c#/vb I found that someone hacked up which uses rhino commands from inside the script. Because of this and the number of objects we are dealing the whole thing runs VERY slow.
Also (if your fussing with the text component): The ability to select the font is very important. We require a single stroke font so that it is machinable on a cnc.
These changes would save people doing certain types of physical output allot of hassle, what do you think?
Also: it would be nice to be able to specify the type of justification (top-left, top-center, top-right, middle-left, middle-center, middle-right, bottom-left, bottom-center, bottom-right) - this would save me from writing a lot of repetitive GH code.
Also: what about a "text on surface command"
I hope i haven't blown it by asking for too much. :-)
Actually I changed my mind. This rescaling makes it easy to add parameters to the bottom of a list of parameters, but not to the top or in between. Instead I'd like to try to make it so that while you drag wires, there's always extra grips in between existing grips you can link to.
i've been thinking of that would be a problem when adding output lines; explode tree component would be one case. I know that the wires can be connected from right to left, but I think that widespread use is from left to right.
Is there any chance to do some symmetrical scaling?