Strange behavior with invalid mesh

[maje90 (Riccardo Majewski)]

Hi all!

I have a sort of big definition, I’m trying to pinpoint the bug by removing part of the code but for now I can’t find the logic. Here a gif:

I’m using 2 geometry pipeline before this part of the code. With swap hidden/visible rhino command they re-trigger all the definition.
It seems Combine&Clean always fails and returns an Invalid mesh when swapping, but reconnecting might resolve the problem.
What I’m seeing is that I’m also able to make the invalid mesh “flow backward” ! (see the gif)

I have no idea what is going on.

Any tips? Anyone encountered something similar?

(The c# is a simple n = m.Vertices.Count; …)

[PeterFotiadis (Pfotiad0)]

Asked my top IT guru: he said that you maybe date the wrong girl (use TopologyVertices - and combine vertices [better safe than sorry]). He also said something about a Mesh VS droplets of water … but I have no idea what he’s talking about.

[DanielPiker]

Here’s a way to at least check what it is about the mesh that is invalid, using the IsValidWithLog method :
invalid_log.gh (7.3 KB)

[w.radaczynski]

Does your top IT guru like Ducatis?

[maje90 (Riccardo Majewski)]

"ON_Mesh.m_dV[] and m_V[] are not synchronized."

[DanielPiker]

Hmm, I wonder why that is happening.

Here’s a script with the same methods that Combine&Clean component uses in order.
Clean methods.gh (9.8 KB)

Can you use it to see at what point the mesh becomes invalid?
(or post the mesh and I’ll look)

It’s something to do with single vs double precision vertices…

[maje90 (Riccardo Majewski)]

Thank you for the help.
Combine&Clean is innocent… behave the same as a simple mesh parameter but act as a dam for the “data reflux”.
With your insights I found it.
I have another script component that was doing:

m.Vertices.Clear();
m.Vertices.AddVertices(pts);

And this caused the mesh to become invalid.
The strange part is that the mesh object (now invalid) also affect the past(on the left) copies of itself on the GH canvas (but stops at components that recompute/edit the mesh… sort of).

Using double precision vertices didn’t solve it, but doing a whole new copy of the mesh did.

---

strange invalid mesh bug.gh (15.0 KB)

[DanielPiker]

Thanks for sharing this.
Glad your issue is sorted now.

I still don’t understand why replacing the vertices with points like that is causing the double/single precision verts to get out of sync though. It does seem like maybe a bug.

[maje90 (Riccardo Majewski)]

@DanielPiker

same methods that Combine&Clean component uses in order.
Clean methods.gh (9.8 KB)

Looking also at other methods, like here Fixing Invalid Mesh in Grasshopper - #2 by laurent_delrieu
… what is the smallest set of operations to simply “fix” a mesh? (without doing excessive and useless methods that burns CPU time…)

Also, it seems that Mesh.Append(Mesh) works while Mesh.CopyFrom(Mesh) fails (sometime)… i wonder why…

---

fixing mesh.gh (1.1 MB)

 private void RunScript(Mesh m, ref object A, ref object B)
  {
    A = FixMesh01(m);
    B = FixMesh02(m);
  }
  // <Custom additional code> 
  Mesh FixMesh01(Mesh M){
    Mesh m = new Mesh();
    m.Append(M);                                          //APPEND
    m.Vertices.CombineIdentical(true, true);
    m.Vertices.CullUnused();
    m.Weld(Math.PI);
    m.FaceNormals.ComputeFaceNormals();
    m.Normals.ComputeNormals();
    return m;
  }
  Mesh FixMesh02(Mesh M){
    Mesh m = new Mesh();
    m.CopyFrom(M);                                          //COPYFROM
    m.Vertices.CombineIdentical(true, true);
    m.Vertices.CullUnused();
    m.Weld(Math.PI);
    m.FaceNormals.ComputeFaceNormals();
    m.Normals.ComputeNormals();
    return m;
  }