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_Tree.png 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
