And here’s come the pain (no pain => no gain, mind).
Let’s talk about clash matters … meaning in fact strut to strut angles matters. Imagine a base vertex (i.e. a OEM mesh vertex) and the neighbor vertices (we always deal with indices NOT the Point3d thingy). Depending on the valence (from 2 to … you name it) is kinda like a star with center the vertex in question and rays to the neighbor vertices. VV connectivity means a branch of index i containing indices of the neighbor vertices.
Indices in VV connectivity NEED to be sorted (for calculating the strut clash angles [struts at base layer]).
But … each vertex is engulfed with faces as well. Now … the 1M question: do we need the face indices sorted in a similar way as the neighbor vertices indices? Yes we need that since the top layer indexing system derives from a VF base indexing system [ struts from a vertex to the neighbor W top layer nodes]. Problem is that I have no idea how to do that without code (forget sort points along curve: takes a million years to finish):
See results with and without face indices sorted (VF connectivity).
Note: this def is NOT suitable for you: the thingy does buisiness strictly via C# code.
For branch (0,0) the angle vector test goes:
(7-0, 41-0), (41-0, 8-0), (8-0, 386-0), (386-0, 3-0) …
For branch (0,0) the angle vector test goes (yields bananas anyway):
(7-0, 41-0), (41-0, 8-0), (8-0, 45-0), (45-0, 3-0) …
Moral: I’m not sure that you can even touch reality on truss matters without code. Not to mention that clash issues are just the tip of the iceberg (lots more are required).
Such a simple case eh?
And the freaky/ugly part of the story: the code that does all these sorted tasks: