The Anemone “Fast loop end” component take ages to complete although it has very little data to process.
It even takes up over 5 seconds with NO data at all being passed.
Is this an un-avoidable drawback of using loops in GH or is there a better looping plugin that I should consider ?
Hello, you have posted this question 2 month ago. If you still do not provide a file, there is no chance in helping you, because nobody can tell you anything with missing information. I bet the develloper has tested this enough to make sure it works. I rather believe its a matter of what happends at each iteration. Furthermore „fast“ does not mean anything.It just means that the hack to bring in loops, is optimised in a way that it works faster then the default loop component. To actually test if its a matter of Anemone simply download hoopsnake. If the result is similar its a matter of your script, not anemone. Looping is fundamental so the process itself shouldn‘t be the problem. You may be the victim of an higgs-bugson or more likely: you have no bug, but you assuming it must be a bug due to not fully understanding whats going. A general drawback of using plugins of plugins with code snippets from here and there, is that you very often simply don‘t know whats going wrong. Therefore I believe there is a certain justification to take the pain and recode as much as feasibe, at least for those important tasks.
Hi TomTom,
A looping system which loops when there is no data to loop is fishy don’t you think ?
Ironicaly, this whole looping business and the C# (provided by David) is just a workaround to achieve my need of listing tangent faces (remember ?).
You had made a promising component that would really make my life easier 
Well … I don’t have Anemone (nor any add-on to be honest other than K2) but from the image posted you put a C# in an Anemone loop???
Anyway since I can’t understand what you mean by tangent brep faces (you mean adjacent brep faces per brep face?) if indeed you are after FF (brepFace to brepFace) connectivity matters (plus any imaginable filtering provided that you can explicitly describe it) I could provide a C# that does that as a measure of performance.
Read that in a hurry but … tangentially connected faces ?? What this means?
Let’s make a break:
A Brep (like a Mesh) is a mini DataBase where indices of 3 classes of objects (vertices, edges and faces) are sampled in connectivity things (let’s call’m data trees). These things tell you what face is connected (i.e adjacent, i.e. some face that shares the same edge) to some other, what edges belong to a given face etc etc. There’s 9 possible connectivity combos since we have 3 classes of things. Methods (i.e. mini programs) can inform you with regard some connectivity matters, for the rest you must do your homework.
In general inquiring connectivity trees via code is a piece of cake (or an impossible task) provided that you speak some language. But if not … you can use native components as well (up to a point).
Queries can have a very broad meaning: find planar (or not) faces that have 7 adjacent faces … where their area is > x and < y … where edges are > x and < y … where edges are not curvy … where the dihedral (maybe bisector is a better term) plane ancle is … where etc etc.
So given all that … are you after connectivity matters in general? (and maybe in particular IF you can list the queries desired).
I need a tree giving lists of faces connected along an edge and also sharing the same normal vector along that edge.
I don’t deal with freaky faces for which the normal vector changes along an edge for example.
The part I give as an example shows this : it is your everyday sheet metal part.
I used the BREP Topology component and normal vector comparisons to get a tree giving for each face, the list of all the faces with adhere to my criteria (including the face itself) :
But then I encountered a roadblock because I need to “concatenate” those lists to get “chains” of faces which are connected according to the above criteria.
David gave me a C# component that “almost” worked : indeed, I had to place it in a loop to make it go through all the trees, and this is causing great trouble in the execution.
Therefor, I started looking into graph theory to produce the doggone list, as I started explaining here.
Sorry if my description of the problem wasn’t clear enough. It just seemed to me such a trivial task at the beginning because unrolling sheet metal is really basic stuff.
Assuming that we are talking for planar faces (sheet metal stuff etc etc) the first part of the query is the easiest of things. For the other … well … you mean faces that are coplanar ??? (meaning that the normals are parallel or anti parallel). Because share the same normal ALONG an edge it doesn’t make any sense.
And all that for unrolling eh? (if you had a proper MCAD app on hand all that are already in the menu [Rhino is the very wrong thing to use for classic sheet metal work, but anyway]).
In any case I have several C# things that do similar stuff (made just for fun since I never work with R). That said … unrolling is easy on first sight and not so … in some cases. So provide the most tricky Brep imaginable and some sketch that outlines the desired/ideal unroll result. But again … well … without feature driven modelling identifying a sheet fillet …
Peter, I model my sheet metal parts realistically with the bends, therefore what I said actually makes sense.
Once I have the lists of “tangentially connected faces”, illustrated above, I can sort them based on area.
Here, the “extrados” is the red set of faces ; the “Intrados” will be the blue set of faces, and are respectively the largest and the second largest in area.
Then it becomes easy to offset one of them according to bending tables and flatten that to get an accurate flat version.
I know that other CADs out there have built in tools for that, but for now, we are stuck with Rhino.
I always admire the brave (a parametric feature driven MCAD app [+ a proper sheet metal advisor add-on] could do that in seconds).
Anyway I’ll post soon a C# that does that (I’m not in the practice right now + tomorrow is a day far and away from it … so expect the thing this w/e ).
Thanks Peter 
I completly forgot. I’ll continue on that one
Hi Peter, TomTom,
I found my own solution to the problem.
You will probably come up with a more straightforward solution, but you might be interested by my geometric approach.
