Mesh shading wrong

[Terry_Chappell]

I have a mesh with 26 very non-planar faces arranged into a cone shape. I have extracted 1 mesh face in order to more clearly show its shape:

I then used the vertex coordinates of this face to create a new mesh with this one face. But now the shading is placed on the sides rather than the top of the face:

I copied over the surface normal from the original mesh to try and prevent this.

In the original mesh, the 0-1-2 and 0-3-2 triangles are shaded. In the 1-face mesh, the 1-0-3 and 1-2-3 triangles are shaded.

Here is the .3dm file for the above:
Mesh with wrong shading.3dm (91.6 KB)

How can this be fixed so the 1-face mesh is shaded the same way as in the original mesh? What makes the shader think the 1-mesh face is different?

I thought this would be an easier way to show the non-planarity of the non-planar mesh faces by coloring this new face. And indeed the stand alone mesh face colors up very nicely since there are no adjacent faces bleeding their colors into this one.

I also tried adding a colored nurbs surface over the mesh face but it gets shaded/colored in the same undesired way. The mesh faces in this example cannot easily be modeled with a nurbs surface due to the sharp bend at the 0,2 vertices so that may be part of the problem.

I could triangulate this non-planar quad and color the 2 pieces but I am at a loss as to how to identify cases like this. This is not a good choice for nearly flat faces as it injects a distracting line at the shared boundary and creates different shading on the 2 triangles.

@dale any idea how to fix this?

Regards,
Terry.

[dale (Dale Fugier)]

Hi @Terry_Chappell,

Does increasing the degree (to 3 for example) help?

– Dale

[Tom_P]

the mesh looks correct here
Version 8 (8.8.24149.15002, 2024-05-28)
mac os x 13.5.1, Intel

but what about
_trinagulateMesh
optional
_SwapMeshEdge
to exactly create the interpretation of the Quad you expect ?

from left to right
input
triangulateMesh
triangulateMesh + SwapMeshEdge

[Terry_Chappell]

You meant to say right to left but I get the idea.

The bigger problem is identifying these cases as most cases of non-planar faces in my meshes work fine with either adding a colored nurbs surface or creating a single mesh face placed over the original mesh face.

But both approaches have issues with bleed thru of the original mesh. I offset the added colored mesh face by 0.01 (the minimum non-planarity being colored) in the direction of the face normal but that is not enough to fix this problem:

Notice the grey patches of the original mesh bleeding thru in the green-colored faces.
More offsetting makes this go away but then the added faces pick up a floating appearance.

Thanks for looking at this.

Regards,
Terry.

[Terry_Chappell]

I changed the line where the quad face is specified from:

mesh->SetQuad(0,1,2,3,0);

to:

mesh->SetQuad(0,0,1,2,3);

and got the desired result (shown with 1 face lifted above others to make shading clear):

This view shows the colored mesh faces created to go over the original mesh. Now the faces are shaded on the desired surfaces.

I misread the ON_Mesh::SetQuad documentation and thought that the last number was for the face number and the 1st four numbers were for the vertex indices. But it appears that the 1st number is for the face number and the last four are for the indices. When I export the 1 face raised above the other 25, I get this for the .obj file:

Rhino

mtllib SetQuadOrder00123good.mtl
usemtl diffuse_0_0_0_255
v -11.4406166 1.66679096 -1.43222165
v -11.4406166 1.66679096 -1.86324763
v -11.4406166 1.76994205 -1.44474649
v 8.47197628 2.33757687 -0.585174561
f 1 2 3 4

which has the same face line that I see when I export the extracted face in the original mesh:

Rhino

mtllib Mesh_2 Original 1 face.mtl
usemtl diffuse_0_0_0_255
v -11.4013786 1.71583617 -1.76200521
v -11.4013786 1.71583617 -2.19303107
v -11.4013786 1.81898725 -1.77453005
v 8.51121426 2.38662219 -0.91495806
f 1 2 3 4

(ignore the minor differences in the vertex coordinates).

The Rhino C++ API documentation for the SetQuad function is a bit sparse:

and asking Copilot:

What is the 5th parameter in Rhino ON_Mesh::SetQuad function in C++ API?

just makes it worse :

I tried asking:

Example of using Rhino ON_Mesh::SetQuad function in C++ API?

and got thrown even further down the rabbit hole :

Maybe I should take my marbles and play with someone other than Copilot.

Or maybe there is another, later version of the API documentation than what I am looking at:
Rhino C++ API: ON_Mesh Class Reference (rhino3d.com)

Since my goal is to match the original mesh, using the SetQuad function should work fine as long as I get the face/vertex ordering correct. Fixing the vertex ordering to match the original mesh also fixed the bleed thru problem:

Here there is no offset of the added mesh faces and yet there is no bleed thru. Perfect!

So very happy now .

Regards,
Terry.