After reading your response and doing some light research into Data trees, I realize that I was completely off in what I was thinking they were. Data trees brings a whole new level of complexity to Grasshopper, and its just a matter of finding a way to capture their value. The Node/Data relationship is an important one that I completely missed. Its important to understand that each node doesn't contain data, but is merely a path to access data. With data being only at the end of a given path.
At the moment I would argue for keeping the trees as simple as possible. You mentioned removing the "trunk" as a means of simplification, and that would be something I would get behind. It would make navigating, manipulating and data matching the tree much easier. At this point, I think simplification is also needed simply because the ability to harness the capabilities of complex trees is not available yet. I completely get your tree diagram, but I ask myself "Why exactly would I need a tree that complex?" and "How would I use a tree that complex?". At this immediate point in GH the answer to the first question is extremely vague which isn't helped by the answer to the second question being "Can I?". Since we're still dealing with essentially singular operations within each component, I'm really not sure where THAT much complexity fits in. I need more than flat data, but I don't need a tree that Monkey wouldn't get bored climbing. -Damien On Mar 20, 7:18 am, David Rutten <[email protected]> wrote: > Hi Damien, > > good questions and observations, I'll handle them one at a time. > > > 1. Are paths considered, or are they planned to be, 1 dimensional, 2 > > dimensional, or N-dimensional? > > > 2. Could paths be nested within other paths, or a jagged path > > structure? > > This is actually the same question. Data Trees are N-Dimensional > structures. I uploaded an image that represents a reasonably complex, > but well structured > tree:http://groups.google.com/group/grasshopper3d/web/Grasshopper_Data_Tre... > > In Grasshopper 0.5 and before all data inside a parameter in a single > list. Because there was only ever one list, it did not need an index. > But since it's now possible to have multiple lists of data, there > needs to be a way to identify each individual list. Although a simple > index (a single integer) would have been sufficient to be able to > store any number of lists, I decided against this because I wanted > each list to know its entire heritage. > > So, in the image mentioned above, there is a single master branch (you > could call this a trunk, but since it's possible to have multiple > master branches I decided not to use that word) at path {0}. It > contains no data, but it does have 3 sub-branches. Each of these sub- > branches inherit the index of the parent branch {0} and add their own > sub-index (0, 1 and 2 respectively). It would be wrong to call this an > "index", because that implies just a single number. I prefer to use > "path", since it resembles a folder-structure on the disk. > > Each of these sub-branches are again host to 2 sub-sub-branches and > they again contain no data themselves. And the same is true for the > sub-sub-branches. Once we reach nesting level 4 though, we start to > encounter some data. Every sub-sub-sub-branch is a terminus branch, > meaning it doesn't subdivide any further. Instead, all the level 4 > branches contain a list of data items (lists are drawn as dark > sausages, data items are bright circles). > > Each data item is thus part of one (and only one) branch in the tree, > and each item has an index that specifies its location within the > branch. Each branch has a path that specifies its location within the > tree. > > I don't actually bother storing empty branches like {0}, {0;1} and > {0:2:0} because their existence can be inferred from the terminus > branches (or 'twigs' if you prefer). That is why the Param Viewer > object only lists those branch paths that actually participate in Data > Matching. > > --------------------------------------------- > > As I mentioned before, the example image represents a well-structured > tree, albeit a somewhat complicated one. For example, since all twigs > share the same first path specifier (zero) this doesn't actually add > any information. This tree could be 'pruned', by removing the {0} > master branch and turn {0;0}, {0;1} and {0;2} into master branches, > which would change their paths to {0}, {1} and {2} respectively. This > operation would strip the first number in every path in this tree, > thus simplifying it. > > I do not have a good definition of "well structured" yet. Initially it > was my idea to make it impossible for a branch to contain both data > items AND sub-branches. However, since I switched to a new internal > storage system for trees, this has become possible. Similarly, I > initially planned to automatically strip empty branches if a Component > had the nerve to create them in the first place. However, I now > realise that having support for empty branches is a vital element of > being able to perform logical operations on trees. If you intersect a > line with a Brep for example, it's useful to know that there were no > intersection points for this particular ray. If this data were > stripped from the tree, then you could no longer be sure if result at > index {5} corresponded with the ray at index {5}. > > -------------------------------------------- > > In short, you're not the only one who's new to Data Trees. I barely > have an idea about how it should work myself. This is an understanding > I hope to gain over the upcoming weeks/months. As I learn how people > use trees and how they expect them to behave, I'll be able to fine- > tune the automatic behaviour. This will be a painful period for > everyone involved since changes in data-logic might very well render > old files faulty (just as happened with the 0.5 -> 0.6 transition, but > probably on a smaller scale). > > -- > David Rutten > [email protected] > Robert McNeel & Associates
