Rezeroing some meshes causes mesh to become non-watertight about trimesh HOT 2 CLOSED

Oh interesting, I think what is happening here is:

1. Mesh in question has some degenerate faces which are still 3 unique vertices (so not caught by the remove_degenerate_faces which just checks for 3 unique indices per face on load), but those vertices are colinear (up to way more than tol.zero, 1e-12)
2. The face normals are from the STL file input
3. Face normals are stored in the cache, which is cleared when vertices or faces are altered
4. When mesh.rezero is called it alters vertices, triggering a cache clear
5. is_watertight asks for faces, which checks to make sure face_normals are populated to ensure consistency in the shape of mesh.faces and mesh.face_normals
6. the generation of face_normals via cross products detects and removes the degenerate face
7. mesh is no longer topologically watertight

So it is totally a little janky to be inconsistent like this. A quick hack to ensure consistency is:

m = trimesh.load('rezero-test.stl')
m.face_normals = None #force the Trimesh object to regenerate/validate face normals
m.is_watertight

I also just added a bit to mesh.rezero that maintains face normals, as they're not going to be changed by a translation.

I'm not sure what the right way to deal with this is globally however. If we just threw out face normals from input files it would keep everything consistent, but in a lot of meshes generating the face normal from cross products is pretty expensive (though I just checked and it looked like it was ~15% of total load/process time). Another option is to add a strict flag:

m = trimesh.load('rezero-test.stl', strict=True)

Which would just throw away input normals, or at least validate them. I'm not in love with adding another esoteric boolean flag though, I'm definitely open to suggestions.

I've found trimesh.repair.broken_faces to be pretty useful for seeing whats happening for stuff like this btw.

from trimesh.

Upon reflection, those faces should really have been removed in initial processing. There is already a remove_degenerate_faces function called in there, however it was only covering the case where a face has two of the same vertex (aka [0,1,0]), not the case where there were three unique vertices that all happened to be colinear. I pushed a fix in d0685ac which is slower than the old function, but its like .015 -> .023s on my machine, which is probably worth it for being more robust.

from trimesh.