Sorting points

1. From mesh I take the property get connected faces to vertex.

2. Then I calculate centers points of mesh faces.

But the order of those faces are not ordered to create a proper polyline.

Is there any method or approach how to order those faces centers in order to create anti-clock wise polygon?

Replies to This Discussion

Permalink Reply by peter fotiadis on June 7, 2017 at 9:30am

Added an option to exclude naked vertices and thus all the shift indices paraphernalia - not ready yet.

Compare results:

Permalink Reply by peter fotiadis on June 8, 2017 at 12:38am

Update:

Found a couple of minutes to add some other stuff/options. Almost ready.

Compare times. (no // stuff used, mind).

By angle sort (not that bad ... but why bother?):

By sort along curve (slower than any Harley Davidson... only for masochists). In this the Method for dealing correctly with boundary faces is not implemented (but why bother? this is junk food only used for indicating the obvious).

By indices Lists intersections (faster than my Panigale):

Some partners of mine in the practice (top C# dogs) are impressed:

Permalink Reply by John on June 11, 2017 at 3:47am

Looks nice, what do colors represent?

Would it be possible to see the code for connectivity freaky stuff?

Permalink Reply by peter fotiadis on June 12, 2017 at 1:19am

Get the public version of the whole approach (it doesn't work with Lists (meaning: no meshes with disjoint pieces etc etc) , provides some of the 9 possible connectivity trees, does not check input meshes ... and has some other limitations as well (for instance: no // processing)):

The internal version:

Attachments:

Mesh_connectivity_V1.3dm, 245 KB
Mesh_connectivity_V1A_Public.gh, 135 KB

Permalink Reply by peter fotiadis on June 12, 2017 at 1:33am

PS: For mesh aficionados (I hate meshes) who may want to fully exploit the 9 connectivity trees via their own code:

The EV (and thus VE) connectivity trees are occasionally wrong because ... these lines of code yield bananas (occasionally, that is):

Why? Who knows? And who cares? (not me anyway). Quite propably David, Giulio or Daniel are aware of that "bug",

For instance the V(as ball)E(as tubes) works OK for this mesh:

While is 100% faulty for that mesh:

Permalink Reply by peter fotiadis on June 12, 2017 at 12:33pm

Yikes + Yikes:

A vertex index in mesh.Vertices is not the same in mesh.TopologyVertices. The former is required in order to get the naked status and the latter ... in order to make the VE/EV connectivity correctly.

See attached.

Attachments:

Mesh_MTV_VS_MV_vertexIndices.gh, 137 KB

Permalink Reply by peter fotiadis on June 13, 2017 at 1:18am

And this ... well ... does what you want and is 10 times simpler ... but doesn't teach you anything about the black art of intersecting Lists (critical in line graphs).

PS: add some stuff with regard disjointed mesh pieces.

Attachments: