Access to mesh data structure in rhinocommon

I am working on a mesh-unfolder (similar to pepakura) in rhinoPython
the code is here
a blog about the project is here

Anyway, it is becoming apparent that having access to the mesh data structure itself, not just the adjacency queries, would be extremely useful for making the code more efficient and readable. Is the rhinocommon Mesh() a half-edge or winged-edge mesh? If so is there a way to access those elements?

Also, it appears there is a missing query: topological edges for a given vertex. I am aware that there is a query for neighboring vertices to a given vertex, but I am not seeing an elegant way of using this to find the neighboring edges for that vertex (the solution I have works, but is rather clumsy; using a pair of vertices, it gets the sets of faces associated with each vertex, finding the intersection (A), and then another intersection with the edges for each face in A )

The RhinoCommon Mesh object has both the Vertices (array of Point3f) and Faces (array of MeshFace) collections and topological collections TopologyVertices and TopologyEdges. These support neighbor searches. For more info see

Just curious, what is half-edge or winged-edge mesh? I don’t know these terms :smile:

a good explanation of half-edge and winged-edge meshes is here
I am guessing that the RhinoCommon Mesh object contains one of these data structures or some similar vartiation so that neighbor searches are efficient. It would be really awesome if I could somehow get direct access to those structures.

1 Like

We don’t use those specific data structures, but that doesn’t mean we can’t support whatever topological searches you are interested in.

The mesh data is really large arrays of vertex locations, face indicies, normals,… The data was originally structured this way in order for efficient transfer of the array data to OpenGL.

I recently implemented a Half Edge Data Structure in F# from this code
I store the structs in Lists and use indices into those lists instead of pointers. keeping all those indices right while manipulating the mesh is quite error prone ( at least for me) so I would stick with the queries on the topological mesh that rhino provides, unless you are really running into performance issues and you are sure that they are related to those neighbourhood queries.

there is also a Half Edge data structure by Daniel Piker:

I would be interested to know what you need in this data structure that you can’t get from the RhinoCommon Mesh class

I use a custom mesh datastructure mainly becaus I want to represent Octogonal Faces.
I also have an additional level of hirachy in my mesh where i group several Faces into what I call assemblies. Lastly I base it on HalfEdge for efficient neigbourhood queries of nodes or faces.

for this project:

1 Like

Wow, cool picture. It makes me think of a sci-fi novel I read a while ago, Pandora’s Star by Peter F. Hamilton. He writes about a Dyson Sphere generator that in his description and in my mind looks a lot like the picture above :smile:

We will most likely be adding n-gon information to our mesh data structure in Rhino 6 which may be enough to support what you are working on. @piac and @dalelear , you may want to chat with Goswin while we think about n-gon support.


@stevebaer, @piac, @dalelear, @Goswin,
I would be interested to take part in the discussion regarding n-gon support for Rhino 6, as we support n-gon meshes in EvoluteTools. Any news yet?

Hopefully we’ll have a V6 WIP available soon. At that point we will have a prototype of the ngon support in V6 RhinoCommon. Remember that the initial ngon support can change if users don’t like or understand the way the SDK is structured.