Data Tree Management

Replies to This Discussion

Permalink Reply by David Rutten on October 9, 2010 at 3:48am

Well, it is working the way it is supposed to be working. I'm just not sure if the way it's supposed to be working is the best way.

The problem is that when data is supplied to a component, it is simply handled in a sequential fashion. There is no smarts in there that will try and figure out which branch in data-tree A best matches which branch in data-tree B.

In this specific case, you're providing two data trees with radically different topologies. One has three branches of the {A;B} kind, the other has nine branches of the {A;B;C} kind. So the first branch in tree A is matched up with the first branch in tree B. Then the second branch in A is matched up with the second in in B, and so on and so forth. After three of these, tree A runs out of branches so it keeps on recycling the last one.

What you need to do is either complexify the first tree so it has nine branches of the {A;B;C} persuasion, or simplify the second tree. I chose to simplify as it's easier:

One of the things I can do to make this easier is to add more data matching algorithms. The ones that are in there now have not been updated since data-trees came onto the scene so they are fairly antiquated. Another thing I could do is supply more components that do these kinds of tree modifications automatically, or perhaps add additional features to the Path Mapper or something. If you have a suggestion I'd love to hear it.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

• ▶ Reply

Permalink Reply by Evert Amador on October 9, 2010 at 6:49am

Hi David,

I'm not very good to with the path mapper so for me a component which took 2 or more data trees with different matching algorithms options to choose from would be very handy.

Cheers

Evert

• ▶ Reply

Permalink Reply by Michael McCune on October 9, 2010 at 10:31am

Personally I run into this a lot. A lot of the time I just simplify, but for this instance I want to keep going deeper. I think that it would be great to have an option for each branch to apply itself to all associated limbs.

For instance: if we were to draw a line from each those points in the direction of the vector (list of 10), but for each circle (list of 10) have a different line length.
This would mean that the Tree Matching would work well if we can supply a length in this level:
{0;0}
{0;1}
{0;2}
and have it propagate through to all of these levels:
{0;0;0}
{0;0;1}
{0;0;2}
{0;0;3}....
{0;1;0}
{0;1;1}
{0;1;2}
{0;1;3}........

It would really make sense visually when you look at the "draw tree" of the param viewer.

If we go one more level deep it would be even better not to have to complicate nor loose your data structure (for access). So if each of those lines in C were to be divided and then a line drawn from those points outward, it would be on D. You could then supply information at the A level (globally), the B level (per base circle), the C level (per copied cirlce), or the D level (per line).

Honestly a lot of projects don't require this complicated of a data structure, but for the ones that do it would really help. I fell that having all the branches in a data tree is very useful, the single branches are the only ones that i usually delete with the path mapper.

• ▶ Reply

Permalink Reply by Michael McCune on October 20, 2010 at 9:46pm

In this example, a vector is created between two points - a center point (extracted from early in the stream with a very "immature" data tree) and multiple division points of a circle (extracted from a more "mature" data tree). So in this case, even if you bring geometry up to the level of another data tree OR simplify a mature data tree, you still have to Duplicate Data.

Possible Data Tree Matching solution:
If you use the Path mapper and bring the center points up to a level of maturity (i.e. D) that matches the division points, but leaves out the last level (i.e. E), it would be great if the center points would be passed into each "branch/limb" of D. In other words, the center point of the first circle would be coppied into each E branch. Once inside the E branch the center point would be applied to each item in the list naturally.

If we go further and add two source crvs, it creates 2 branches in the B level. If for some reason we wanted to create a vector from ALL the points that exist in the first branch of level B to ONE point, and ALL the points that exist in the second branch of level B with ANOTHER point. It would be great to only have to supply the "A" input of the vector component two points with the data strucuture of
{0;0}(1)
{0;1}(1)

and

hundreds of points inside multiple branches of branches with the data structure of:
{0;0;C;D;E}(i)
{0;1;C;D;E}(i)

*C,D,&E represent multiple branches

and the Vector create itself appropriately. Does this make any sense the way I wrote it?

Attachments:

• Data Tree Management.ghx, 386 KB

• ▶ Reply

Permalink Reply by Michael McCune on November 4, 2010 at 2:03pm

Hey David,

Not keep hanging on the same topic, but I ran into the same issue with data tree matching where simplifying and losing the data structure would be disastrous. Is this a cumbersome algorithm to add to the data tree matching. It makes perfect sense to me. See image below where i have 6 surfaces (B) and varying # of lines on each srf (G) and each line is divided to get 9 pts (H). All i want to do is find the closest pt on the original srfs in order to get the surface parameters without loosing the data structure.

• ▶ Reply