Tree sorting, by curve, then by type

[Mark_Keukens]

wow that’s a super clean definition , thank you Volker!

If I can just pick your brains for a bit more;
I combined yours and Inno’s scripts and did a trial where different types share the same grid size. I saw you used the grid sizes as keys in the K/V search.

Three questions arose:

1. I assumed that using duplicate grids would force me to use the types as keys again, but this doesnt seems to be case (which still puzzles me a little).

2. I also noticed I’m not always directly getting an output from member index which matches the original tree as was the case in Inno’s script. Luckily I could put the newly learned tricks from that script - (de)construct path - to fix the structure. Just wondering here what could cause the tree structure to be different then expected.

3. I’m planning to do some geometry manipulation (clash detection with other geometry etc.), in this case I would need to apply the filters attained from the geometry tree to the distr/crv tree, correct? Like @inno mentioned here:

@inno

for what is worth, the way I got used to handle data trees, I would keep the initial data tree “as it is” (meaning just {a;b} paths) and keep a parallel data tree with very same {a;b} structure containing just the corresponding ABCD letters

if you want to create some filters, do those for the ABCD tree, then apply them to the original one, but do not alter the original one through branching by properties

and would you call this technique “parallel trees” ?

forumquestion_tree sorting_vr_02_mke.gh (52.6 KB)

Thank you again,

Best regards,

Mark