I have two tree structures. The first has two branches with two surfaces each, stacked one on top of the other. The second structure has two branches with three surfaces each; these branches contain the surfaces found in the branches of the first structure.
The goal of the routine is to identify which layer the six surfaces belong to, based on the larger ‘container’ surfaces. To achieve this, I am attempting to get the centroids of each small surface and then use a Surface Closest Point operation against the large surfaces. If the distance value is zero, it means the point belongs to that surface and should inherit its layer.
However, I am struggling with the cross-referencing (data matching) because I am not getting coherent results.
I would advice to go that way (proximity/containment) if and only if all the surfaces in play all come from separate Rhino entities that were referenced in GH: if they come from geometrical/trimming operations/data trees that were flattened at a certain point, then there is for sure a much better solution to this problem by just re-establishing and working with the relative data trees
(like if you have a deck of cards for which you know the initial order and the mixing algorithm, and then you want to recognise the cards with computer vision instead of reversing the exact mixing algorithm and working by card indexing)
in your case, if you want to go the proximity way, I would use Pull Point (I distanced the Surfaces a bit just to show the referencing arrows)
keep in mind that this won’t work if one of the data trees had {0} and {1} inverted, as this is a branch-to-branch operation, meaning that proximity of surfaces in {0} is searched only in the relative branch {0} and proximity of {1} is searched only in the relative branch {1}
Thank you very much @leopoldomonzani and @inno ! The script works perfectly. The problem is that when I apply it to other projects with referenced surfaces, the Point on Curve (o Point Curves) component doesn’t accept those surfaces in the ‘curves’ input. I don’t understand why this is happening, since in both cases they are Rhino geometries.
can you share a file? when you plug a surface type into a curve type it automatically tries to extract its border, what does it say in the error message?
Thank you so much for your reply. The geometry part is perfect, just as you recommended, but I think the issue lies with the tree structure. I’ve attached an image because I’m terrible at explaining things! My goal is,for each main branch, to figure out which of the sub-surfaces (A or B) (from the larger parts AB) the smaller surfaces (1,2,3,4,5) belong to.
Thanks a million for your help, it’s almost there. Now, what I need is more of an opinion. The front geometry surrounding the magenta area, which is on the same plane, should have the same index. Currently, one appears in green and the other in blue because they are two different surfaces. How do you think I could make it understand that these surfaces share the same index? Maybe by checking if they share a common edge? That doesn’t seem very robust to me. Perhaps by checking if they are on the same plane and share a common edge… Thanks a lot.
I think using layers could make the process more robust. My idea is to use a double filtering method: first by layer membership and then by a Pull Point routine. However, the Pull Point logic is currently failing , and I’m struggling to implement this dual-stage filter correctly.
even if in this particular case it doesn’t really make a difference because it ends up with just one single big-searching-surface per branch, so the final output is always just that one
but if you apply that to a slightly more complex scenario, with multiple searching-geometries for each branch:
