Hi David, Your to do list looks great - can't wait. Last year in mid 2007, I started a project developing something very similar to GH, using Vision by http://mgltools.scripps.edu/. This is a Python based visual programming system - we connected Vision to the Rhinoscript COM api, and created a whole bunch of components matching the Rhinoscript command. This worked very well, and the result was similar to GH, except that the interface was nowhere near as nice. It was all a little clunky (it was only supposed to be a prototype). When I saw GH, I decided to lave that project on the backburner to see what might emerge.
In our experiments, we found that one of the most powerful features that this dataflow modelling approach has over others (such as feature trees), was the way that it handles lists (or arrays), so that for example you can send a list of points into a line component and get a list out. This is also true for Generative Components. Of course, we encountered the same problems as you - i.e. how do you deal with all the possibilities. Currently, in GH, I find the lists / data matching approach a bit frustrating, since all components that require a list as input (such as lofts, polylines and curves - all the really sueful ones) are excluded. What we did in our system was we used multi- dimensional lists, which allowed all components to support higher dimensional lists and data matching. For example, for the polyline component: * input ((0,1,2),(3,4,5),(6,7,8)) and you get 1 pline * input (((0,1,2),(3,4,5),(6,7,8)), ((0,1,2),(3,4,5),(6,7,8))) you get 2 plines, in a list, (pline1, pline2) * input ((((0,1,2),(3,4,5),(6,7,8)), ((0,1,2),(3,4,5),(6,7,8))), ((0,1,2),(3,4,5),(6,7,8))) you get 3 plines, like this ((pline1, pline2), pline3) For components that have more than one input, the data matching logic still works, but with many more possibilities. In terms of implementation is not really very complicated. Each function knows the expected dimension of each input, and if the dimension is higher, then it just unwraps it until it gets down to the right level and re-wraps the output. We added a bunch of other stuff to support this, such as nodes for list manipulation, including special data matching components that did various forms of list merging and interleaving (which is really what data matching is). So, I saw in your list of things to do: > 2) add hierarchial data storage Is this similar to the multi-dimensional lists? Sound like it might be... Patrick Janssen On Sep 25, 9:43 pm, David Rutten <[EMAIL PROTECTED]> wrote: > There's no official todo list, because I'd rather not commit to > anything official. The unofficial todo list is: > > 1) add script components (nearly done with VB.NET, C#.NET and Python) > 2) add hierarchial data storage > 3) rewrite cluster logic from ground up and make it actually useful > this time > 4) add components that carry around custom source code and which > compile on the fly, this will be a sort of uber-script component > 5) add some basic IO features that allow reading from and writing to > textfile, databases etc. > 6) add about 500 more components and a bunch of data types > > Then we'll probably start calling it Grasshopper 1.0 > Anything after that depends pretty much on user requests and feedback > we get. > > --- > > what do you mean by "What do you think about the develop of GH?"? > If "develop" is development then I'd say it's going slowly but > steadily. If "develop" refers to "developer" then I'd say he's just > one froody guy who really knows where his towel is. > > -- > David Rutten > Robert McNeel & Associates > > On Sep 25, 2:50 pm, "digitag&" <[EMAIL PROTECTED]> wrote: > > > There's an official "to do" list? > > What are the McNeel planning for GH? > > What do you think about the develop of GH? > > Sorry for the question.....I don't know if this is Off Topic! > > I think that GH has great potential and already now provide a great > > tool for generative design investigation. > > > DigitAG&
