Hi Patrick, yes, the hierarchial data storage is essentially a tree of data lists. It's not all that difficult to create/transfer these, but - as you pointed out - the hard bit is trying to combine multiple trees. Especially if they have a different topology, this becomes nearly impossible. I am not content with having a single extra dimension (i.e. two dimensional trees), even though that would solve 95% of all problems. It is my goal to have something in place that works using default settings in the bulk of cases, no matter how deep the data nesting. This, along with better cluster objects is the hardest bit of coding in my near future.
Can we see your project? Did you think about visual representations of If...Then and Loop structures? -- David Rutten Robert McNeel & Associates On Sep 26, 9:12 am, Patrick <[EMAIL PROTECTED]> wrote: > 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 byhttp://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&- Hide quoted text - > > - Show quoted text -
