BUG: Transform produces invalid Mesh

GIGO

Another example is when you use robots plugin from Vicente Soler.

The same mesh working into rhino + GH version 6 (and 5) are not working right now.

BTW the mesh was not garbage. It was a mesh made of closed breps from inventor.

Hello
Meshes are not treated the same way in V7 so now there are lot invalid meshes that were not invalid mesh in previous version. There are some discussions to heal meshes. I used a little script to do that.

But in order for McNeel to resolve the problem please post a little script with a faulty mesh.

4 Likes

Yes,
I applied the C# component from the first post and healed my mesh.

Ok,
I will post the content asap.

The thing is that the same mesh is both valid and invalid before and after any cartesian transformation.

This mesh is an OBJ export straight out of Artec Studio imported into Rhino 7. The mesh is closed but seems to have a few normals messed up.

mesh_transform.gh (11.5 MB)

Same mesh, different orientations.
Both valid and invalid, but the mesh is the same.
This is a bug depending on cartesian transformations, and the fact that some other meshes are working correctly is not enough to say the opposite. Nice crocodile btw.

The main thing to say is that the orientation of a mesh can not determine wether it is valid or not, because it’s just a change of basis.

Thanks.

I’m working with meshes almost daily. Most of my meshes have imperfections.
But I never saw the problem you described.

How do you create the meshes?

Sometimes I use the “mesh brep” component (usually with a low number of triangles), other times I start picking a mesh from a library (robots library in the case of the robot above)…I almost never start from native meshes.

But I would like to point again that the problem is the combination of mesh + transformation.

I’d say that what is unexpected from my perspective is having a mesh that after rotation became invalid.

1 Like

I recently updated the robot libraries attempting to fix invalid meshes. You can check here if your library got fixed: Invalid Mesh · Discussion #105 · visose/Robots · GitHub

I think one issue is that mesh reduce can create very thin edges, and since Rhino 7 it seems to be more sensitive to this when checking for invalid meshes.

1 Like

Exactly

Why don’t you post examples with your meshes that fail?

1 Like

Hey Everyone,

If you have a mesh that is valid, and then you transform it and it becomes invalid, please post the original mesh along with whatever it takes for us to repeat the process of producing a bad mesh.

— Dale

1 Like

Has there been any further movement on this issue? In case no one else has posted a problematic mesh, I’m uploading one here. In my case this object (meshed from a closed solid Brep part in GH using a “smooth” setting node) only becomes invalid when translating in the X direction, both positive and negative. But Y and Z movement doesn’t affect it. Also interesting is that if I simply slide it along using a param node, then it becomes invalid, then valid, then invalid again seemingly at random. Crazy stuff!

Mark

InvalidMeshAfterTransform.gh (1.1 MB)

1 Like

Hey @mark.lamkin1 :slight_smile:

I checked out your mesh with Check command in Rhino, and origin “valid” mesh after check shows this:

But after transform check looks like this:

What is interesting is the fact, that looking at this you can see that origin “valid” mesh has no “non manifold” edges, but after moving it you have 2. You can actually visualize them with “ShowEdges” command in Rhino, there are really tiny, and they are here:
image

I like to check the meshes with Pufferfish, so I recommend it to you as well :slight_smile: For instance it shows me that both origin one and moved for some reason have some openings there, which is interesting:

Another interesting thing is, that after I take this origin mesh to Pufferfish “Rebuild Mesh” component, and use Weld Vertices with some small value - this problem with transformation dissapears. However it’s good to mention that this operation makes your mesh ugly, probably it flips some normals or something like this, so probably it’s not the best idea to use it.

Regarding the whole problem, that transform produces invalid Mesh, I think @Krzysztof has a good take on that - that the floating point number precision could be the reason for all of that. That would kind of explain how it is possible that mesh can become invalid just after transformation, because maybe some math operation inprecision can slighly deform the meshes - which causes all these things. But maybe there is something else, or there are some additional operation behind the scenes that cause that, can’t really say without access to the source code :wink:

2 Likes