I like the idea of 'atomic' but i would call the new components like CurveHozirontalFrame or CurvePerpendicularFrame 'molecules', since you can do the same with a couple of other more basic components (same applies to some older components). Just some thoughts (don't take them too seriously), maybe they could be like pre-made clusters that you can explode and get the more basic components. This cluster-components would be a lot less optimized, i guess, but it would allow non programmers to create their own custom components...
I had no idea the interval was programming related, but i liked the idea of have as minimum inputs as possible. Instead of having two inputs for Max/Min all the time, just handle it in another component. It relates to the 'hierarchical vs parallel' interface i was describing above. On Nov 8, 4:40 pm, David Rutten <[EMAIL PROTECTED]> wrote: > 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 -
