Inconsistent Quad Meshes in Rhino 6 (related to n-gons)

Hello all,

Sadly I have only come across this issue a week after your visit to London, but no matter!

Problem: Inconsistencies with how a quad mesh is represented in Rhino 6.
Software: Rhino 6.2.18065.11031; Grasshopper 1.0.0004

Steps to reproduce:

  1. Create a flat, planar single quad mesh face on the XY plane in Rhino (clicking by hand)
  2. Under Properties -> Details… you can see it has 4 vertices and 1 face
  3. Reference the mesh into Grasshopper. The referenced mesh also has “(V:4 F:1)”
  4. The Mesh Edges component in GH also only recognises 4 edges (as per this discussion)

This is all terrific and expected.

  1. Move one of the vertices of the mesh up or down (Z direction), to create a twisted quad mesh.
  2. Under Properties -> Details… you can see it still has 4 vertices and 1 face
  3. The referenced mesh in GH also still has “(V:4 F:1)”
  4. The Mesh Edges component in GH also only recognises 4 edges

This is all also terrific and expected.

  1. Create a new quad mesh in Rhino that is not planar (clicking by hand)
  2. Under Properties -> Details… you can see that this quad mesh has 4 vertices and 2 faces
  3. Reference this quad mesh into Grasshopper. This time the referenced mesh has “(V:4 F:2)”
  4. The Mesh Edges component in GH still only recognises 4 edges as before

The fact that this quad mesh has two faces is not expected and thus not so terrific.

I can see how the argument for only ever having triangle meshes (and thus n-gons are merely composed of triangles beneath the surface) is a reasonable one, but I kinda like having quad meshes as a possibility.
More importantly, I think it’s critical that quad meshes are represented in a consistent manner, and not dependent on the circumstances of their creation. Thoughts?

Hello - Thanks - I see the discrepancy… I’ll add this to the heap for the developers. I don’t have a good idea why Rhino sees these differently but I’m sure somebody does.


Hi Richard,

What Rhino is reporting is accurate. The reason for the difference is indeed the way in which your examples were created. The first took an already existing, planar mesh and modified a vertex location. Rhino does nothing but move the location of the vertex in this case. It was not necessary to create an ngon since the mesh consisted of a single face. In your second example the polyline used to generate the mesh is non-planar so it creates triangles. Rhino will make triangles in non-planar and/or trimmed surface situations. 3dFace in V6 always creates an ngon, even if the vertexes are nowhere close to planar. This is by design and was done for the sake of the SubD work that was started in V6.


I should add that Rhino does not, generally speaking, automatically create ngons. The exceptions I can think of are 3dFace, file import that contains ngons (obj is a notable example), and AddNgonsToMesh (the sole purpose of this command is to create ngons).

Hi Tim,

I understand that what Rhino is reporting is accurate, my point is that I think the way Rhino 6 behaves should be changed. I think it’s confusing that quad meshes can be represented in two different ways:

4 vertices, 1 face

4 vertices, 2 faces

I think quad mesh faces should have a consistent data structure, irrespective of how they were created, or how they were altered after creation.

I am in the architecture world, and quad panels are very useful things to have as a “type”. It is even more useful to be able to determine how far from planar they are. This worked fine with Grasshopper in Rhino 5, but has been broken in Rhino 6. Now, if I want to find the planarity of a quad mesh face I have to deconstruct and reconstruct it.

Is there a reasonable argument as to why quad meshes should be represented in an inconsistent manner? If a quad mesh face, planar or not, can be represented by a single face, why is it not * always * represented by a single mesh face?

Hi Richard - would this problem go away for you if the 3dFace command did not make Ngons out of quads at all, as in V5? Is that one command the problem or does it come up elsewhere?


Good question. I’m not sure if other commands cause a problem, but certainly, from my perspective if the 3dFace command did not make Ngons out of quads at all, just as in V5, then that would resolve the issue nicely.

That would mean that quad meshes, regardless of how they were made, will only ever have 1 face; never 2. That would ensure consistency, and seems much more sensible to me.


Hi Rich - - it looks like we’ll be able to tune up 3dFace not to make nGons below 5 verts.



1 Like

I’ve noticed one more thing with nGon meshes: when viewing them in wireframe mode, clicking on one of the hidden edges of a sub-face of the nGon selects the mesh. I find this quite disconcerting, as there is no edge that appears in the viewport, but Rhino recognises that its internal representation of the mesh has an edge there, hence it selects the mesh.

Can this be changed? I think more appropriate behaviour is to only select a mesh if you click on a visible edge of the mesh, rather than the internal nGon subdivisions. I think anyone who didn’t know there were internal edges for nGons would be very confused by the outcome. I know I was for a while!