Hello everyone, I am currently developing a “mesh walking” program that segments mesh faces in a radial pattern from any point on a triangular mesh. The number of segments is based on the degree of connectivity at each point.
NEVER involve Vectors (or anything in fact) if Connectivity is available: Use Recursion (using a public DataTree of Type int - that way you can monitor easily the steps, animate some slider related with Loops etc etc) and Mesh VV Connectivity. Even if you insist using Vectors (and sorting) … these should been “extracted” from VV. In general the best way to deal with this is to define a Class with suitable Properties (Parent V Idx, V idx, V Connectivity for instance) and sample items of that Type in your Recursion Tree (kind of History, so to speak).
PS: For the Vector thing: foreach V Idx get the adjacent (valid) Vertices Indices (as int [ ]). Using the previous Vector (that resulted V) sample for each candidate the Vector/Vector angle (in a double [ ]). Then do a sync Array Sort (double as Master, int as Slave) and get the first item in the sorted int array: that’s your next Vertex Index. Store the index in the Tree where path’s first dim is the current Loop value. For a given Loop retrieve current search vertices indices from the Loop-1 path.
PS: If you want to deal with the general case (Meshes/Graphs where clothed V valence != 6) you should mastermind some more elaborated rules.
PS: For each Recursive Loop … obviously a public bool[ ] var, named say: visted/sampled/whatever … is paramount: never date the same girl twice.
See a similar (sligthly different rule than yours: each Vertex is visited once) Recursive expansion
Thanks for the reply.
I take your advice and simplify my code which now major in “Mesh VV Connectivity”.
It’s true that with Vertices index, it is possible to generate vectors , segments , point afterward.
I am now working on “identifing where the walk should stop” . By identifying the mesh naked edges.
Do the VV, EV Conn as follows (see the naked bool [ ] as well). PS: If you want a TextDot “visual” result like in the mp4 above … you’ll need the EV (or rather better the VE: way faster if your Graph is BIG) as well.
Now … the VV Conn as shown is based on MeshTopologyVertices (MTV) Indexing [I always do VV that way] … while the available naked RC Method is based on MeshVertices (MV) Indexing (these have nothing in common).
But there’s a handy “map” MTV > MT RC Method around.
Note: whitout a CombineIdentical pass is it possible a MTV index to “point” to more than one MV index - since MTV is Vertices on a per Mesh basis while MV is Vertices on a per MeshFace basis:
Note: for the general case (any valid and manifold Mesh/Graph) you’ll need some checks/options more: for instance what happens if Parent is clothed and Child is naked? Should the candidate Vertex qualify as valid or not? And what if Parent is naked? Should the search continue ?
Note: is rather waaaaay better to define a suitable Class (PIDX is Parent’s idx), do the “radial” expansion using the custom Type (and/or a Tree - but you can skip that if your C# is destined way outside the R/GH Universe) and then unbox the List/history Tree accordingly.
Note: add the 1M option: do either a full V search (as shown in the mp4) OR a “radial” search (as shown in the captured image above: your initial goal). It’s just a matter of an If clause more: but what this @#@$@ question may be? Answers: the Lord, District 666, North Pole.
Create an array of bools to store whether each topology vertex is naked.
Build up topology with Mesh.TopologyEdges
Iterate through each TopologyEdge and count connected faces with .GetConnectedFaces
Each edge that have an amount of connected faces<2, get the 2 connected topology vertices index and set their value to “true”.
You can do this only for the vertices/edges you “walk over”, but I feel it’s a cleaner code this way… and you can multithread this.
Or, you can get the naked polylines once at start (Mesh.GetNakedEdges) and only check if your walking gone at zero distance with one of the polylines…
Why bother doing the bazooka/mosquito thing? It’s just a few milliseconds using the slowest CPU imaginable (either in radial or all expansion mode). In fact the most time is consumed for finding the E idx (given the V index pair) for the yellow TextDots.