Flipping the normal does not flip the mesh normal

Hello all
I’m struggling with an issue.
I’m turning surfaces into meshes and reading the surface normal in a c# plugin. So far so good. If i use the “Flip” component on the surface the new mesh normal does not reflect the change, but stays the same as before the flip. If I bake the flipped surface and reference it I get the correct flipped mesh normal.
If I use a referenced surface and flip it in rhino with the flip command, the normal changes correctly to the opposite direction.

Pre flip

X - Y - Z
0.9510565 - 0.309017 - 0

Post flip

X - Y - Z
0.9510565 - 0.309017 - 0

I cast and read the mesh like so from IGH_GeometricGoo

Mesh m = new Mesh();
geometry.CastTo(out Surface s);
m.Append(Mesh.CreateFromSurface(s, meshParam.Value));
...
Debug.WriteLine(m.Normals[0].X.ToString() + " - " + m.Normals[0].Y.ToString() + " - " + m.Normals[0].Z.ToString());

If I want to get the right normal I have to rotate the surface 180 degrees instead of flipping it. Does anybody have an idea why I’m seeing this?

Regards Thomas

General case (BrepFaces).

  1. Get the div pts (obviously in a DataTree or in an Array [ ][ ]) using the Underlying Surface. If you deal with BrepFaces that Tree/Array must be nullable - for more than obvious reasons (a null pos should indicate that the pt is not contained - i.e. is outside - in the BrepFace).

  2. Declare a Mesh M as new Mesh();.

  3. Double Loop into divPts: Given a valid Quad (case BrepFaces: meaning that all pts are not null) get the Trimmed Surface piece Normal (say at 0.5,0.5 or at 0,0). Get a Mesh m from the Quad pts and get the Normal. Check the DotProduct of these 2 Vectors and if required flip m. (BTW: If Triangulation is required then get 2 Meshes m1, m2).

  4. Append m (or m1/m2) to M,

  5. Combine M Vertices (avoid calling the UnifyNormals Method).

BTW: you can skip the as described Normals part by obtaining one Vector from the Quad pts. In any case I would advise to use 2 passes (in order to avoid dating the same girl twice). For instance (spot the public bool Array that monitors pt/BrepFace relation):


Thank you so much for the detailed description! I will give it a try tonight.
Out of curiosity do you know why the simple mesh.nomals does not yield the flipped normal direction when in GH?

Let’s re-analize the Mesh from BrepFace case:

Assuming that your quad pts (or the triads if triangulation [spot the order below] is required) are picked always in the same order (derived from the Array [ ][ ] as above) like:

Then the Mesh M (where you Append the m Meshes) has always the Normals pointing to the “same direction” (so the UnifyNormals IS NOT the Method to use - by any means). Flipping the M means: all the Normals point to the other direction. Obviously the CombineIdentical Method is a must (that way the Mesh Vertices Count equals the Mesh Topology Vertices Count - per Mesh island, that is).

So IF the goal is a Mesh (the M) with Normals “as the Normals” in the donor US (i.e. Underlying Surface - Brep Face boundaries play no role on this) you should check the Mesh pieces (the m’s) VS the US Normals at creation time. Obviously prior the Array creation (the div pts, that is) you can use Methods that flip the US.

Tip: if in doupt ALWAYS prefer the analytic way to cut the mustard . For instance assume that you want to triangulate a quad mesh:


BTW: Write and use something like this (to viz/check the Normals):

Amazing @PeterFotiadis, thank you so much for your explanation and time. It makes sense to me now! :+1: :slight_smile: