Could someone tell me why the output of the contour block is not matching the data format style of its inputs? What logic is being used for structuring the output?
I always assumed that the order the things are inputted, the same order they are outputted. Hence the data restructuring above. After using this tree rework for many years, suddenly the order of the output is not the same as the input for a specific use case. Rebuilding the tree therefor mixes up the wrong data.
Unfortunately I can’t share this exact data this happens with, so I would need to figure out a different data set that generates the same issue. If someone could shine some light on the output structure logic that would be great!
Think: an object will be “sliced” many times (depends on your P, N and D inputs), and each slice/contour can result in many curves!
For example the central contour of a torus will result in 2 circles.
Using “Trim tree” can probably be more useful if you Simplify your data tree before… maybe.
Also, try to remove the parallel computing flag, and see if it works differently
I am quite familiar with tree datastructures, the actual difference of data tree structure output to input is my problem. All the inputs are the same tree structure; 31;3;… but the output structure is 3;… I do not see any logic to the tree output format, except my initial assumption that everything was computed sequentially and then remapping would solve it. But now, it appears that sequential data tree branch processing is not a given.
What basically is happening is:
Input:
31;3;1
A
31;3;2
B
31;3;3
C
Output
3;1
A
3;1
C
3;2
B
The contour output, when going from first to last branch, does not have the same order as the input list. Also the complete tree does not have the same data format.
Also this example is in Rhino 5, so turning on/off parallel computing is not applicable as far as I know.
Let me illustrate the weird behaviour of the Contour block with an example (see attached .gh).
Initially I have three geometry sets as an input, filling up the following branches 0;x;x, 1;x;x and 2;x;x.
When this tree is flattened, and I run through the items chronologically, the list starts with the bottom of the first geometry set, progresses through the first set, goes on to the second, and ends with the top surface of the third set. All is normal!
When this is inputted in the Contour block however, the output:
does not match the input datastructure at all, no hint anymore of the 1;x;x, 2;x;x and 3;x;x division
when flattened, is not chronologically built up anymore; i.e. first item is from the original 1;x;x set, second from the 2;x;x, … Maybe not exactly this order, but definitely not what you would expect.
As mentioned previously, I usually just rebuilt the tree matching the original structure as the output was always in the same order as the input. With this example you can see that it is not the case anymore. I am curious if anyone can elaborate on this behaviour and how to deal with it, since I want to maintain the original tree structure. Contour_ordering.gh (433.7 KB)
Thanks, it works! Sorry that I missed your solution in the previous reply, I misinterpreted your path in the Path Mapper. Have you found an explanation somewhere why the structure isn’t more straightforward from the get-go?
the thing is that the contour component outputs a tree that is grouped (branched) by section, so the input geometry data tree is just relevant for the order in which the contours are generated
if the geometry input of the contour component is just plain-flattened, then the output tree will just be A;B so a Trim tree would work exactly like a pathmapper with {N branching} → {N branching -1} = {A;B} → {A}
the initial geometry tree structure could anyway be reinstated the very same way
Thanks for this solution inno it is very helpful. I spent some time trying to do what you did without great success.
Here is a little extra quick code to this solution for it to work when there is several inputs in the N parameter (in the form of a flattened tree). I needed it and I’m sharing it here in case it’s helpfull for someone :
ps1 : it works for my data structure, I’m not promising anything for other scenarios
ps2 : the method may be slow if the BREPs are huge, in that case maybe try to replace the items of the BREP tree with something else like numbers before connecting the tree to the “duplicate” component.
