select small disconnected components seg faults about pymeshlab

[alemuntoni]

Hi,
yes if you can provide an example model and the script you are running could be helpful, thanks.

[Cervidellus]

I am experiencing a similar issue that may be related. In my case it will crash with any of several select methods, including select_small_discoennected_components(). I've enclosed an example script I am trying to use to clean up a non-manifold mesh, as well as an example mesh that can replicate the problem. Depending on how I run the script (either a python interpreter, jupyter notebook, or from within vs code), it crashes on different methods, but always on a method that is selecting vertices, and not on the first time that method is called.
examplecrash.zip

[Cervidellus]

I was trying to find a more minimal example that reliably causes a crash. Here is an example where if I first call meshset.remove_zero_area_faces()
and then call
meshset.select_small_disconnected_component()

it reliably crashes. If I just call one or the other, everything is fine. My starting mesh is kind of a mess, but I guess the goal I have is to clean them up as best I can. If I perform the same two operations in the GUI version, I do not get an error (and the disconnected component is successfully selected). In the short term, I think what I will do is try and implement things in C++ for now, but happy to try and help more to fix this for the python api if I can. I've attached the minimal example below.
examplecrash2.zip

[Cervidellus]

I was able to determine a few minor things: One, I verified that my mesh produces the same seg fault error on a mac, similarly crashing the kernel. The second thing I was able to determine is that it does not produce the error on a much simpler example of a small disconnected component. I've attached that example below, which is just a simple sphere with a few vertices deleted to disconnect some faces. The other thing that I was able to determine is that it is not a problem specifically with the .obj importer, as I get the same results with a .ply version of the file.
testhole.zip

[Cervidellus]

I was able to distill things down to a single face that can cause a fail.. it turns out that one of the problems with my mesh are some faces that are represented as quads instead of tris where one of the vertices is a duplicate vertex. Here is an obj file as text with just one of those faces:

: # Blender v2.92.0 OBJ File: 'example_bisect.blend'
# www.blender.org
mtllib right_left_left_bottom_front_bottom_back_left_right_back_less11.mtl
o right_left_left_bottom_front_bottom_back_left_right_back_example.010
v 0.452538 0.671930 -0.731709
v 0.452538 0.671930 -0.729608
v 0.452538 0.671930 -0.732187
v 0.452538 0.671930 -0.732187
vn 0.0000 0.0000 1.0000
usemtl Default_OBJ
s off
f 4//1 1//1 2//1 3//1

I suspect that what is going on in the c++ gui version vs. python, is that in c++ vgclib::compacteveryvector is called when importing a mesh, and it is somehow failing to get called when loading the mesh in Python. calling mesh.compact() after loading the mesh seems to solve the problem for me. It would be nice to fix it so that pymeshlab has the same behavior as meshlab.. it could be fixed by either figuring out why it doesn't get called in pymeshlab (it seems like it should.. gets called in afterLoadOperations, so it should be?) to make a change to the importers in vgclib to call it there (this gets done, for example, in import_fbx, but not import_obj or import_ply). To me, making a change in pymeshlab might be the better option?

[alemuntoni]

Sorry for the late reply, and thanks for the detailed report!!

I checked, and the actual issue was in the filter, since it should check every time if there are deleted faces.
You can try pymeshlab with this fix just downloading and installing the wheel generated by github actions.
This fix will be available in the next pymeshlab release!