mesh.GetConnectedVertices problem

Hi all,

I seem to not be getting the right connected vertices ids from the GetConnectedVertices call via C#/Rhinocommon. It seems to work fine with a quad mesh I have, but not the triangular one. Some vertices are returning ids of themselves. Please find attached the GH file with mehses internalized. (18.6 KB)

Thanks a lot,


This was already reported some years ago

I have done some recent program with this function and I filter the results because of this flaw.

Hi Laurent, thanks for the response!
I filtered the result by simply saying something like <if(id != i)> for now,
but am wondering if there are other ways around this since it might be troublesome later on because I will actually be operating with the connected vertices.

As there is no fix now you have to take it into account.
@piac is there a fix planed for this bug ?

Here an example with TopologyVertices with no errors at first sight

List valence = new List();
DataTree v_vid = new DataTree();

for(int i = 0; i < m.TopologyVertices.Count; ++i){
  int[] vid_temp = m.TopologyVertices.ConnectedTopologyVertices(i);
  int [] vid_mes = new int[vid_temp.Length];
  for (int j = 0; j < vid_temp.Length; j++)
    vid_mes[j] = m.TopologyVertices.MeshVertexIndices(vid_temp[j])[0];

  foreach(int id in vid_mes){
    v_vid.Add(id, new GH_Path(m.TopologyVertices.MeshVertexIndices(i)));

for(int i = 0; i < m.Vertices.Count; ++i){

A = v_vid;
B = valence; (21.8 KB)

Hi Laurent, thanks so much!
The problem of using TopologyVertices is that the index might not be consistent throughout right?
For example, if I were to iteratively move vertices around, they might be re-sorted?

It seems like you are avoiding that problem by matching the indices back to the original mesh indices?

I fixed RH-29217 today and it should be available in 6 SR2.

@laurent_delrieu For now, you can change this line, in the original:

int[] vid_temp = m.Vertices.GetConnectedVertices(i);
var vid_temp = m.Vertices.GetConnectedVertices(i).Where(v => v != i);


Thanks for that and also for all the new functions in Rhinocommon. I was near to develop a dll including Catmull & Clark and I was happy to discover it is now in Rhinocommon :tada: I used them for that

1 Like

@piac @laurent_delrieu thanks both!
does that mean the fix will be available in a newer version of Rhino WIP as well, or only in 6 SR2?

In the general plan for all Rhino 6 fixes, this will be available:

  • in all service releases of Rhino 6 after or including 6 SR2
  • in new versions of Rhino WIP – in order to step onto this again you’ll need Rhino 6. This is so from the day Rhino 6 shipped

I see, thank you for the help!

RH-29217 is fixed in the latest Service Relase Candidate