I’ve used the CONTOUR component multiple times, and each time I’ve encountered the same issue. I’m trying to understand if there’s a way to solve it.
When the component receives a data tree as input, it returns an output tree structured with a seemingly random logic that varies from case to case.
I’ve seen that this issue has been brought up multiple times in different places (the latest post here: Data Structure: contour changes data tree), but the answer has always been the same: manipulate the output data tree using the PATH MAPPER component or other case-specific solutions.
Has anyone found a stable solution that doesn’t require a custom approach for each specific case?
Or is the lack of a generalized solution due to the existence of new plugins or script components (Python, C#, etc.) that already handle this correctly?
Alternatively, is it simply that this issue is no longer considered relevant, and users prefer to solve it on a case-by-case basis when needed?
well, I don’t think the output data structure is random, it might follow a set of convoluted rules, but I believe that the same input data structure will always yeld the same output data structure
I believe a set of components (most probably tree stats + replace path) can be setup around it in such a way the real output is more in-line with the expected output
do you have an example with complex data structure inputs on which experiment?
[edit: without considering that contour is just a linear array of planes intersecting some geometries, so you can also easily create your own Contour]
I said random but this is what I actually mean, you are right. I still cannot break down those rules
That’s exactly my point, I’m wondering if it’s possible to build something reusable without spending lots of time studying the structures for every case
I also tried this but it resulted to be much more heavy in terms of computational time
Your algorithm is very interesting, and after examining it for a while, I think I’ve understood the logic behind CONTOUR a bit better: the second-to-last index of the data tree is the key to restructuring the output. However, since the values of this index appear in a random order, simply trimming by 1 is not enough. Instead, the operation described in your first REPLACE PATH is necessary to automatically reorder them as well.
After that, the resulting data tree is similar to the input one, so applying the second REPLACE PATH (which is essentially a MATCH TREE operation) is sufficient.
Your response was really enlightening, and I sincerely appreciate it. While analyzing your solution, I came up with a variation for the second REPLACE PATH, which I believe should work even in cases where, due to a large CONTOUR distance, some breps might not return any sections (resulting in a data tree with fewer branches). If you have the chance, test it and let me know your thoughts!
your definition works well and the filtering function to highlight on which Shape Contour Curves were created is a nice addition
the only silly point I could make, because the whole definition/filtering will work if and only if each branch being contoured contains just one single Shape, I would maybe suggest to explicit a Graft component instead of relying just on the right-click graft option, which might get lost with copy-pasting or other accidental movements
I’ve never used the explicit components for GRAFT/etc, and I’ve always just used the right-click option. But that’s actually a good idea, I’ll start considering it from now on. Thanks for the suggestion!
