Thanks guys, I wasn't sure whether or not to include such arbitrary conversions. At the moment there is actually a fair amount of weirdness in the logic which is why I'm rewriting everything to be more structured. This will almost certainly affect some conversions.
For example, under some conditions, if you have a boolean it might get converted into an Interval (boolean goes to integer, integer goes to floating point, floating point goes to interval). This is clearly nonsense. I think I'll limit myself to only 'Box -> Point' auto-conversions since all boxes are defined by a plane and thus every box has 'a base point', even though it might not be inside the box. -- David Rutten [email protected] Robert McNeel & Associates On Jan 24, 10:47 am, visose <[email protected]> wrote: > I agree with Damien. It's not more logical to convert to 'mid point' > than 'end point', I can't think of a 'more logical' case for any of > those examples. I like it when the software responds logically and > doesn't make assumptions that could have been any sort of things. It > makes the software less intuitive and I tend to forget what it > actually did (was it mid point? end point?). Right now grasshopper > responds very "logically" to everything, I don't feel I have to second > guess the programmer. I like for example that a line converts directly > to a vector, that makes sense, there's only one conversion you'd > expect. > > The downside of not assuming anything is that it will take longer for > the user to achieve the most common tasks. The upside is that you > avoid the painful "workarounds" this causes when you want to create > something that is not exactly what the programmer intended (I'm > thinking of Revit, but any other complex enough software will do). > Grasshopper is far from that right now, though. > > On Jan 23, 7:33 pm, David Rutten <[email protected]> wrote: > > > Does it make sense to anyone to have default conversions for: > > > Curve -> Point (start point? mid point? end point? centre of > > bounding box?) > > Surface -> Point (centre of bounding box? centre of UV domain?) > > Brep -> Point (bounding box centre? Volume/Area centroid?) > > Mesh -> point (?) > > Box -> Point (... etc. etc.) > > Twisted Box -> Point > > Generic Geometry -> Point > > > And, if so, how would you expect it to work? > > > Thanks, > > David > > > -- > > David Rutten > > [email protected] > > Robert McNeel & Associates
