For confirmation and generalisation.
In this simple situation, the line component is matching points placed into 2 trees A and B.
A possesses the following branches:
{0;0;1}
{0;0;3}
B possesses the following branches:
{0;0;0}
{0;0;1}
The line component matches the first branch from tree A with the first branch from tree B. And the second branch from tree A with second branch from B regarless of the fact that the first branch of A has the same path as the second branch from B.
Can this be generalized ?
In other words, that matching at the branch level depends ONLY on the order in which the branches appears in the list of tree paths.
In other words, that matching at the branch level depends ONLY on the order in which the branches appears in the list of tree paths.
If the parameter accesses are not tree type, you can expect the branches to be related in order and not by path. It depends on the implementation, but I think the usual thing is not to worry about paths if the accesses are not of the tree type.
Just for clarification.
By that I understand that, if the components performing the matching are not of the type found in Set->Tree (or the merging of 2 outputs into a volatile parameter) then the path is ignored and it is the order in which the branches appears in the list of tree paths that determines the matching.
This is correct. Data is matched item-by-item and branch-by-branch in order, unless this default behaviour is specifically overridden by the component. If you have a component operating on two inputs, both of which provide four branches (\{0;0\},\{0;1\},\{1;0\},\{1;1\}) and (\{0;0\},\{1;1\},\{2;2\},\{3;3\}) then they will be matched like so:
What are the thoughts in GH2 about this?
My biggest wish would be to choose between true path matching and simple matching.
I rely heavily on data trees, and each integer has a specific meaning (building ID, floor ID, beam ID). The data trees are there, and are one of the biggest strengths of grasshopper, but I wish the matching would require less work-arounds by simply matching branches with the same paths.
I’m having your same problem, using data tree to manage coordinates of the elements { floor ; position X on grid ; position Y on grid ; ecc.. }.
I’m using some component of the Treesloth plugin to match correctly the trees before certain operations
This is a decent solution, but it’s very location specific. I would love GH2 to have this fundamentally different. In my opinion it should be default or at least a setting on component level that they can do a true path match.
{0} 20
{2} 30
+
{1} 40
{2} 50
Show be
{0} 20
{1} 40
{2} 30+50 = 80
(After discussions with @antoinemaes I’m not sure that the following is necessary. But a rigid direct path match as above is IMO the desired behaviour)
Equally
{0} 20
{2} 30
+
{2;0} 50
{2;1} 60
{3:0} 70
{3;1} 80
should be
{0} 20 (could argue {0;0} 20)
{2;0} 30 + 50
{2;1} 30 + 60
{3;0} 70
{3;1} 80
