It's the eternal discussion between splitting and lumping, specialization and generalization. I chose to make the components as small as possible (i.e. have a minimum amount of inputs/outputs), because screen real estate matters a great deal on the canvas. It's less important on the toolbars, because they have flyouts.
In a platform like Rhino the decision for splitting or lumping is purely an esthetic one: "which is easier to learn or understand". In Grasshopper it actually has an effect on features as well, if the CurveFrame components were merged into 1 rather than 3, you'd be able to alter the behaviour of the component using additional Grasshopper logic, in the current layout, this is much harder. On the other hand, by making the components more 'atomic', readability of a network is improved. The choice I made for the Gradient input (2 numbers instead of 1 interval) was influenced by the thought that people are more comfortable with numbers than intervals (especially when they are new to programming), and that probably intervals are rarer than numbers. Since it's possible to convert back and forth between intervals and number combos without hassle, I picked the most basic approach. Of course I /could/ add an option to the Gradient control which would switch input parameter types from 2 numbers to 1 interval. I don't mind adding options like those to special components, although I'm hesitant to add additional settings to regular Components. -- David Rutten Robert McNeel & Associates On Nov 7, 6:23 pm, visose <[EMAIL PROTECTED]> wrote: > - CurveFrame component > - CurveHozirontalFrame component > - CurvePerpendicularFrame component > > It reminds me of all the different rhino commands that are almost > alike. I remember people criticizing this. Maybe there should be a way > of adding more options to a component (like the lofting options) to be > able to reduce the number of components. > I think it's better to have a more hierarchical work flow that having > hundreds of "parallel" commands are your disposal. The tabbed > interface and sub-categories are a nice way of organizing (imo, rhino > should have something similar, the toolbars are not enough) but maybe > there should be one more step that reflects in the canvas too. > > The graphs could have inputs for domains (i just comment on this in > another thread), and why is the gradient upper/lower limits two > different inputs and not an interval? > ....I'm trying really hard to think of something else to complain > on ....i'll come back later. > > On Nov 7, 4:02 pm, David Rutten <[EMAIL PROTECTED]> wrote: > > > > > Greetings mere mortals, > > > a minor update to 0.5 is available: > > > Fixes: > > - Setting a Graph back to None did not cause an update, this is fixed. > > - Graph mapper objects with no graphs failed to read back in, this is > > fixed. > > - Transformations that do not maintain similarity now properly deform > > non-deformable geometry types (circles, arcs and boxes become Nurbs > > curves and BReps respectively), this is fixed. > > - Orient transformation had a bug which resulted in erroneous mappings > > for some input cases, this is fixed. > > > Changes: > > - EvaluateCurve component has an extra output for curve span length. > > - Curve divisions components have been moved into a separate category. > > > Additions: > > - CurveFrame component > > - CurveHozirontalFrame component > > - CurvePerpendicularFrame component > > > Download the new version > > from:http://download.rhino3d.com/download_rel.asp?rel=412 > > > Enjoy, > > David > > > -- > > David Rutten > > Robert McNeel & Associates- Hide quoted text - > > - Show quoted text -
