i am trying to get all faces connected to a topological vertex, but in proper radial order, similar like i can query edges and vertices and control their radial order by pre-sorting using:

TopologyVertices.SortEdges()

So far i’ve tried to get ordered topology edges from the topology vertex first, then from the edges get face pairs using:

Next i’ve tried to get a flat list from the faces, flipping pairs dependant on the face orientation, excluding duplicates while keeping order. Then i’ve found that my order is sometimes clockwise and sometimes not. There must be an easier way or ?

You may want to SortEdges starting from each “center vertex” of a star which you are interested in. Otherwise you will have “intermingled” sequences of edges & connected vertices simply because a “global” sort cannot have all “stars” centered around all vertices.

Starting the sort from each vertex OTOH (SortEdges(int)) will sort every edge & connected vertex in a perfect star. This way of sorting will be slower though. On a big mesh it may be significantly slower.

Then i get the connected pairs of faces for each sorted edge. Then get the edges per connected face like this:

edges_per_face = [ (f, list(mesh.TopologyEdges.GetEdgesForFace(f))) for f in connected_faces]

Which gives me a list of tuples, first item in the tuple is the face index and second the edge indices for the face. Then i iterate over the connected edges, and sort the connected faces (two) per edge. If connected edges per face contains eg. edge[i] and edge[i+1], i know this is the face to append between 2 consecutive sorted edges. If not, i re-append the edges_per_face tuple and continue my search until i have the proper face for each consecutive sorted edge pair. The whole process gives me the faces in proper counter clockwise order (like i also get my topology edges), but there should be a simpler way. Filtering the right faces out from the pairs of faces per sorted topology edges is computationally intensive. If we can get connected topology vertices and connected edges in a sorted order, why not faces connected to a topology vertex ?

I don’t know if this (C# version) approach is of any use for you. This was the simplest I could come up with. It seems to work even if the “star” contains naked edges (two faces were deleted in the mesh shown here to ensure that naked edges are handled):

// CONNECTED EDGE INDICES
M.TopologyVertices.SortEdges(I);
int[] conn_ei = M.TopologyVertices.ConnectedEdges(I); // CEI
// CONNECTED FACE INDICES
var conn_fi = new List<int>();
for (int i = 0; i < conn_ei.Length; i++)
{
var face_ix = M.TopologyEdges.GetConnectedFaces(conn_ei[i])[0];
if (conn_fi.Contains(face_ix)) // face already collected, pick the other side
{
var faces = M.TopologyEdges.GetConnectedFaces(conn_ei[i]);
if (faces.Length > 1) // if not a naked edge, pick the other side [1]
face_ix = faces[1];
}
conn_fi.Add(face_ix); // CFI
}

Hm. Trickier than I thought… This seems to work, at least for the test cases I tried.

// Tries to add both sides (faces) of the edge while avoiding dupes.
// The j - loop implicitly handles naked edges by not trying to add
// more faces than an edge actually has (j = faces.Length).
var conn_fi = new List<int>();
for (int i = 0; i < conn_ei.Length; i++)
{
var faces = M.TopologyEdges.GetConnectedFaces(conn_ei[i]);
for (int j = faces.Length; j --> 0; ) // counter clockwise
{
if (!conn_fi.Contains(faces[j])) // avoid dupes
conn_fi.Add(faces[j]);
}
}

So it now avoids duplicates, but the face order is not counter clockwise (CCW) for all topology vertices. I think the only way is to iterate over edges in consecutive pairs, conn_ei[i] and conn_ei[i+1] and then get the connected faces for both as set, then do a set intersection to get the face between those edges. I have this already, but when naked edges come into play, it is hard to figure out what to keep. Therefore i asked for a simple way to get the connected faces in sorted order.

Hi Rolf, naked edges are handled in my case, before i iterate over the edges. So far this is what i have, it is slow with large meshes:

conn_edges = List[int](mesh.TopologyVertices.ConnectedEdges(t))
conn_edges.Add(conn_edges[0])
conn_faces = [mesh.TopologyEdges.GetConnectedFaces(i) for i in conn_edges]
ordered_faces = List[int]()
for i in xrange(len(conn_edges)-1):
pair0 = set(conn_faces[i])
pair1 = set(conn_faces[i+1])
intersection = pair0.intersection(pair1)
if not intersection: continue
ordered_faces.Add(list(intersection)[0])

I cannot post the meshes here, they are over 1 million faces. I’ve tested above code (which does other things before getting the ordered faces per topology vertex) on meshes with 80k faces and 100k vertices. It runs through in 6sec. If i add the code to get the ordered faces per vertex, it runs in 14sec.

OK, try this on your computer. I have internalized a car with 290881 vertices and 234672 faces, which takes ~720ms on my machine. You can un-comment the for-loop to manually verify the CCW winding (on the car the mesh is flipped inwards in many places, so verify winding against your own meshes).

Hi Rolf, i guess i need a faster cpu. I work with python (not gh) which may be slower than C#. Maybe i am interpreting things wrong but your last example does not seem to give the proper faces for an icosahedron mesh, which i have internalized.

If you uncomment the two lines with arrows (you’ll see the comments in the code), then that activates the TVI input. It should work. I tested moving the TVI 0…9 and it should work.

Uncommenting at the arrows will disable the for-loop and the I = tv; assignment , which was used to automate the stress-test of the bigger Audi-mesh.

/// UNCOMMENT "FOR..." TO USE ONLY INPUT PARAM "I"
// <-- HERE for (int tv = 0; tv < tv_count; tv++)
{
//I = tv; // <-- UNCOMMENT THIS ROW TO USE ONLY INPUT PARAM "I"

BTW: My CPU is an old i7 3930K @3.2GHz. A decade old carcass…

ah, you mean comment not uncomment. Your line was uncommented, if i comment this out, i see it updates the display properly.

Still i think, it should not require 3 nested loops per topology vertex to get the faces in CCW order. Did you try my single loop example too and is it faster using a set intersection thank yours ?

But I upload a new version which goes into “manual mode” when the TVI sliders is > -1 (it runs though all TopologyVertices if set to == -1, useful for performance-test on bigger meshes)

No, I didn’t look very carefully since I’m not really fluent in Python.

The reason I used the nested for-loops was to “short-circuit” the face-matching test as early as possible to break the loops (sometimes loops are more “predictable” for the CPU than multiple if-branches). Anyway, yes, generally speaking multiple nested loops is bad, but with the loops I test the faces on the “most likely sides” in respective j,k loop to speed it up a bit. OrderedFaceStar_IcoSphere_RE.gh (15.6 KB)

Edit: How many ms does it take for you to process the audi mesh with TVI-slider set to -1?