Strange behavior with invalid mesh

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:
invalid mesh

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; …)

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.

1 Like

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

1 Like

Does your top IT guru like Ducatis?

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

Hmm, I wonder why that is happening.

Here’s a script with the same methods that Combine&Clean component uses in order.
Clean (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…

1 Like

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:


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 (15.0 KB)

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.

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…

2023-06-30 13_06_12-Window
fixing (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);
    return m;
  Mesh FixMesh02(Mesh M){
    Mesh m = new Mesh();
    m.CopyFrom(M);                                          //COPYFROM
    m.Vertices.CombineIdentical(true, true);
    return m;