I sort of understand why it doesn’t (choosing the relevant lists could be less obvious in the case of a more complex tree), but heck ! In this case, it should be a no-brainer (or no-siliconer).
In this case, I understand that I need to make the tree of curves perfectly match the tree of indices, but that seems really cumbersome, and I don’t see immediately how to do that.
Theres’s a bunch of tree management components which I inherited from an unknown plugin (insert rant about components giving no clue as to where they came from), but none of them seems to do the job, including those in the “Human” plugin which mostly require at least one flat tree.
Along with the tree “Simplify” issue, this pushes me to think that Grasshopper caters for the fringy, unlikely trees and sacrifices ease of use for the obvious more common trees.
This forces to construct convoluted path herding machines for things which intuitively should be dead simple if not completely transparent.
Actually, I can use this in this case, because the “Guide” or “Mature” tree contains lists of indices which you could use at your advantage.
Further away in my definition, I ran into a similar case of tree matching, but where I did not have lists of indices, and needed to revert to my method.
I realize there was a bug in my Tree juggling definition as I wanted to use it to solve an issue with the “Topology” component.
In fact, this component is easy to use when you have only one Brep as an input, but as soon as you have more than one, you run into some serious tree trouble.
In fact, you need to “Clone” the branches of the face lists of your Brep to match the branches of Edege|Faces adjacency tree.
@osuire totally! an “Advanced Match Tree” should be native.
But in your case, you don’t need duplicate branches (heavy calculation in vain) anyway, this is how Propagate Ancestor from Treesloth works (pretty useful when you need advanced matching) and also this VB script DataMatch do that job.
I find that if things get too complicated when you have multiple items, but are okay one by one, to just use a looping plugin like Anemone. Its super simple to set up and breaks down tasks into manageable tasks.
I am not sure I set it up exactly like what you are looking for, but I think you get the idea.
Hmmm interesting idea, but the result here is not what I expect indeed.
I have used anemone and had trouble with it doing iterative grafting, rendering the output difficult to use, other than flattening everything, which would defeat the purpose here…
Sure, I was not going for actually solving your specific issue, but just showing that it is possible. It has helped me before in turning something that was really messy in terms of tree management and break it down into manageable loops. Sort of how you would do it in scripting, where you would use loops all the time.
I have found it especiallly useful in cases where you can have 1 or many of a thing, because usually the tree management for 1 item is different to if you have n of something, suddenly having to deal with multiple levels of grafted lists.
Between Anemone and TreeFrog I have so far managed to tame every task. Sometimes using tons of them in combination.
I know what you feel here
Strangely, I often managed to get the machine working with multiple items, and then if there is only one, it would fail miserably, which in theory makes no sense, and puts in light a problem with the way trees are implemented in GH.
Now that I have somewhat managed to understand tree management, I try to make use of them, although I’m constantly ficghting to keep them easy to understand.
That’s why I use the “Suirify” component everywhere, to get rid of all the extra branching the components keep adding against my will.
I use Anemone from time to time, but I didn’t think of using it like that. Thanks for the idea !
Thanks for your elegant solution.
No need to make tons of lists of surfaces indeed !
I’m still puzzled by the “Propagate ancestor” component.
The example given here doesn’t help so much because the “D” output is the same as the input.
The “P” output sort of does what I want though…
I would need more examples to understand it’s mechanisme.
I sometimes use the other Treesloth components though, as they are a bit more straightforward.
Yup, I know what you mean. Well if you use Merge with grafted lists of the same structure it works fine, then when there are only flat lists when you have 1 item, all of a sudden you notice that flat lists have indexes too that can be different and simplify wont make them the same. That’s usually how things fail. I think I learned recently that using Entwine will not lead to that behaviour. There was a whole thread on here regarding that.
In that example remains the same data structure because of the Ancestors, they have only 1 item in their tree, while in your file there are many faces per branch causing a graft in the update data.
(In my second example I used a trick to not duplicate in vain but the Update Data output is useless)