# Does Rhino support non-planar quads in a mesh?

@stevebaer
@dale
@wim
I have been helping a forum user with reading their .obj file for the mesh of a suitcase. It has several challenges. The latest seems to be non-planar quads. Are these allowed in Rhino?

When I import the mesh, the non-planar quads mostly display OK and Rhino’s Mesh Wizard-> Check Mesh does not complain about the non-planar quads. Does this mean they are OK?

There are some issues that I worry about:
(1) How do you compute the face intersection between non-planar quads?
(2) How do you compute the area of a non-planar quad?

Regards,
Terry.

you can directly create such a mesh, e.g. draw a mesh box with 1 face per side, turn points on, and drag vertexes where you like

As for your questions, these are typically calculated on a triangulation of the quad, as triangles are always flat. If you want to be pedantic, the quad can be converted to a minimal NURBS surface (visualize a soap bubble in a non-planar quad) and you can get the “true” area and intersection. But for most use cases triangulation prior to area and intersection calculation works just fine.

Do you know what Rhino is doing to compute the face normal? The cross product of 2 adjacent sides and calling it good or does it average the results from the 4 corners?

Here is the ComputeFaceNormal function

And there is a duplicate implementation in `ON_Mesh`

This is the code I already use in my Python/C++ mesh import script. It uses the 20 and 31 diagonals to compute the face normal.

What happens if the quad is concave with the concave point on the 20 diagonal? Then the 31 diagonal is outside of the quad. Is there a better choice for the face normal in this case? A more general question is: Does Rhino support concave quads for computing face normals, area, face intersections and triangulating the mesh? When using Rhino to triangulate the suitcase mesh, I noticed its concave quads were split on the wrong diagonal because it appears that Rhino always splits a quad on its shortest diagonal which, for these quads, is the 31 diagonal that does not contain the concave vertex. This resulted in the 2 triangles having a bigger area than their quad and introduced face intersections due to overlap of the triangles. After splitting, Analyze → Mass Properties → Area then gives a bigger than actual area for the mesh as expected.

Thanks for the reply.

Regards,
Terry

The quad triangulation can be found on Github, see below. It is quite a complex routine. If you find that the spliting is not taking into account concave quads correctly, you may need to devise your own splitting routine, where concavity is detected correctly.
Another option is to look into polygon ear clipping routines that are available on the web, for example in VTK