How does Grasshopper solve the intersection of two data trees?

I've been working with Grasshopper for a while now, and I though I had fully understood the inner logic behind the connections of two data trees. It looks like I was wrong

I've found books on the subject, such as AAD (Algoriths Aided Design by Arturo Tedeschi) but they cover the most basic methods:

As far as I know Grasshopper works with the "Longest List" logic by default, but it seems to be working different when I look deeper into it.

This is my "proof":

I would've sworn the logic to follow was this:

Could somobody explain (ELI5 if possible) what's the actual logic Grasshopper following in the proof? I'd like to read out loud the way in which it is connecting the dots.

I'll attach the script with the curve internalized if anybody thinks this is a mistake of mine based on the "direction" of each curve

Thanks a lot!

Attachments:

The proof.png, 204 KB

Replies to This Discussion

Permalink Reply by David Rutten on June 21, 2017 at 2:31pm

The items in two lists and the lists in two trees are both matched in the same way, i.e. the "Longest List" way. The first list in tree A is matched with the first list in tree B, and so on until both trees run out of lists, with the last list being re-used as often as necessary. However component inputs come in three different types (item, list and tree) and this complicates matters somewhat with respect to regular item matching.

I can't visually decode the screenshot you posted, it's too low res for me to make out which components. If you could upload the gh file instead, that would help a lot.

Permalink Reply by Ian Gm on June 21, 2017 at 3:02pm

I though I had!

I can see why it works through the "Longest List" method, but having done this experiment I find myself completely lost in how it matches lists within trees

I'll attach the Grasshopper file of the "proof"

Attachments:

The proof.gh, 153 KB

Permalink Reply by David Stasiuk on June 21, 2017 at 3:47pm

What kind of behavior are you interested in getting from your data trees?

Permalink Reply by David Rutten on June 22, 2017 at 2:39am

In your file all you're seeing is list matching, no item matching, because you've grafted all your data so each list contains only a single item. List matching only cares about the order of the lists, not how much their associated paths look like each other. Thus, the result you're getting is the intended one, i.e. the first list on the left matches with the first list on the right, the second list on the left matches with the second list on the right, and so on. The seventh and eighth lists match with the sixth, because there's nothing else to match against:

If you didn't graft your data, you'd end up with a mixture of list and item matching:

This behaviour is complicated, but intended. The first list on the left {0} is matched with the first list on the right {0}. Then, within those lists, the first item in pink {0} is matched with the first item in teal {0}. Then the second item in pink {0} is matched with the second item in teal {0}. Finally the second item in pink{0} is matched against the third item in teal {0} because there is no third pink item.

Then, the second list on the left {1} is matched with the second list on the right {1}. Same story as above concerning item matching.

At this point is becomes messy, because there are still more pink lists, but we've run out of teal lists. Thus, the second teal list has to be used again twice more.

Permalink Reply by Ian Gm on June 22, 2017 at 2:49am

That's exactly what I was looking for! So the main rule I couldn't deduce was the fact that data matching isn't concerned with the list's direction (the claused number = {1}) but it's position within the tree!

Sorry if I wasn't clear at first; I'm glad you took the time to make a simple and well explained reply

Thanks a lot David

Permalink Reply by David Rutten on June 22, 2017 at 3:18am

No worries. I know this is a complicated topic.

RSS