Given the case, the intersection ‘amount’ per triangle is larger relative to a facet versus the others - as I now mark below, where a single triangle meets two facets but with the area marked green intersecting a facet more than the area marked red intersecting the adjacent facet:
Hoping that explains it well enough - where I need your help is on how to sort said triangles according to the facet they intersect with the most. How would you go about it?
*One thought is going ‘by plane’ (facet plane) using an endpoint at one edge of each triangle gusset.
I’m attaching a simplified part of the file: buckypuzzle.gh (227.0 KB)
not sure I have understood the problem correctly… what I got is to identify which triangle belongs to which facet, considering that for a triangle to belong to a facet its longest bottom-edge should lie on the facet itself (so we can just plainly ignore its shortest in case a triangle has more than one bottom edge)
if that is right, I would do something like this, I believe the only external component is create tree from elefront… but anything that creates branches based on a list of integers to indicate which branch the items should be assigned to should work?
it measures the closest distance-point between the center point of the longest bottom-edge of each triangle, and each facet, so for each triangle you get a list of distances among which only ones says 0 (well… it says “very little” )
then with item index you retrieve the index of that distance (which is equal to the index of the facet it belongs to) and assign each triangle to that branch
Ok @inno, thank you once more - you’ve taught me some tricks lately and I’m grateful! I have checked what you’ve done and it is what I was after.
Right, I couldn’t have worded it like you did, thank you - I’m curious about this and now I must go through the {new} challenge of figuring it out without elefront (nothing against the plug-in, just need to make sure I achieve it natively as well). A quick first look into things points at using ReplacePaths, smilar to what’s discussed here I think?
Let me know where I can send you money for a beer or a coffee!
Especially for making you work as I’ve taken another approach! I wish I could give you multiple ‘solution’ checkmarks still for your work and teachings.
Long story short:
Studying the system made me realize a more effective way to order these parts based on which direction they face as opposed to how much they intersect – this means that if the triangle “faces” the facet, then it belongs to that facet; and to solve that I use Plane Coordinates.
While the previous goal sounded smarter relative to intersections, I believe this new goal will facilitate the assembly process in the shop relative to labels and perception versus human error.
@Inno, sorry to bug you again with this unfinishable zombie project but I’m confused - can you give me some pointers with a new issue? I could have asked on the other related thread but I would have annoyed more people with the notifications.
Long-story short, now I have two parts (triangles) per brep edge:
Each part has a number (label) based on the order of these brep edges - if the edge number is “1”, then the two parts adjacent to it are labeled “1”, for edge “2”, parts are labeled “2”, and so on:
The issue is that now I need to re-associate these labeled parts to the brep face they are on so that the brep faces can also have the corresponding label on them - this means that on each brep face you would see number labels next to the face edges, but each number label is also on the other brep face adjacent to the edge. LoL, it’s a tongue-breaker and my brain is equally broken. I feel like I have it but I don’t, it’s a brep topology issue which I know you’re good at. Let me know if I need to explain this better, though I’m not sure I can - just grabbing screenshots is difficult because everything else gets in the way…
The association of labels on each face, per edge, would look something like this:
Does this make any sense?
There are only 18 faces, so I should end up with 18 groups of labels, but these labels correspond to the adjacent brep edge, not to the face index.
pull each point to each face, with faces grafted, in such a way you can use the Distance list to filter what’s actually on that face (Distance < 0.001) and what is not
you get a list of True / False where True are items actually lying on the Brep Face, and use Member index to retrieve their index from the original list
I put new text tag just to cross-check the points numbers were correct despite the new sorting, and all looks right
the stupid polyline thing also helps a lot to visually see what is in each branch (each polyline should hover on one Brep Face)
as things are now, the Path of each list of points indicates the index of the Brep Face on which the points are, like:
It is!! 'Bears all the weight (literally) and all instructions to assemble the rest of the sculpture - I look forward to sharing that when it’s completed, so crazy!
)
- I’m curious about this and now I must go through the {new} challenge of figuring it out without elefront (nothing against the plug-in, just need to make sure I achieve it natively as well). A quick first look into things points at using ReplacePaths, smilar to what’s discussed 
