Crash When Entering Edit Mode

[Midnight Arrow]

Tested on v1.6.1.0947.

Attempting to enter edit mode on the refrigerator from Polish’s “Sweet Wood Kitchen” causes an immediate crash to desktop. This behavior has been going on for months, but I did not have an account here when I first noticed it.

[Thomas Larsson]

I opened a ticket at the Blender bug tracker: https://developer.blender.org/T97435

[Alessandro Padovani]

added a comment

[Thomas Larsson]

The crash is related to Auto Smooth. There are three ways to avoid it:

1. Disable Auto Smooth in the global settings before importing.
2. Disable Auto Smooth in the mesh context.
3. Change to flat shading.

‌

‌

[Midnight Arrow]

I see. Can we get a warning if an imported object has bad geometry?

[Thomas Larsson]

Unfortunately I don’t know what makes this geometry bad. Perhaps somebody else has an idea.

[Alessandro Padovani]

There’s the example by Pratik where you check the mesh after importing, then according to Robert you should reject if it’s not validated. But personally I still believe it’s something that they should fix in the geometry editor and they fail to understand the issue, or don’t want to.

We could validate then show a warning that blender may crash in edit mode, with a yes/no by the user to keep the mesh anyway, or possibly disable autosmooth in this case in an attempt to avoid the issue. I mean the fridge works fine for animation and rendering, you just have to don’t enter edit mode or disable autosmooth first.

Please note that autosmooth is essential to get the same shading as iray so disabling it may cause artifatcs when rendering, as part of the object appearing rounded or flat where it shouldn’t be. Especially for hard surfaces.

import bpy
for obj in bpy.data.objects:
    if obj.type == "MESH" and obj.data is not None:
        if obj.data.validate():
            print(f"Error found: object {obj.name} had invalid mesh data!")

‌

[Alessandro Padovani]

I can confirm that disabling autosmooth works fine. I can also re-enable autosmooth after entering edit mode to preserve the correct shading. In edit mode tried various tools to fix the mesh, as recalculate normals, delete loose and degenerate dissolve, but didn’t find anything odd and the bug stills there. With autosmooth disabled all the tools work fine though and blender doesn’t crash.

steps:

1. disable autosmooth
2. enter edit mode
3. exit edit mode
4. enable autosmooth

‌

[Midnight Arrow]

If you go to Select by Trait → Interior Faces the whole right door lights up for some strange reason. Even weirder if you move the door away from the main body and Select Linked Faces it also selects the main body even though they’re not physically connected. But strangely it doesn’t do that for vertex selection or edge selection.

There must be something wrong with the face indices, I think. Something somewhere is getting assigned an index that’s already in use, so when you run an operation like Select Linked Faces it thinks it’s connected to another part of the mesh even though it isn’t.

Separating the right door from the main body allows you to enter edit mode on both with no issues even with autosmooth enabled. Probably because it rebuilds the face indices and removes the error.

[Alessandro Padovani]

Ok thank to Midnight I got a way to fix the mesh, basically you separate by loose parts then join back. This could be an automatic fix to try when we detect a non validated mesh, but I guess morphs will not work anymore this way. Stills good for static objects without morphs.

Please note that non-manifold geometry shouldn’t crash blender, the geometry editor is supposed to handle it.

This is also interesting: https://sinestesia.co/blog/tutorials/non-manifold-meshes-and-how-to-fix-them/

steps:

1. disable autosmooth
2. enter edit mode then mesh > separate > by loose parts
3. enter object mode then object > join
4. enable autosmooth

‌

‌

[Alessandro Padovani]

UPDATE. SOLUTION.

According to Philipp it is enough to call the validate() function above to fix the mesh. That is, it both checks and fixes. So this must always be done for imported meshes. May be we can still display a warning if validate() reports something wrong, so the user is aware that the mesh was fixed.

May be this is also a fix for #950 though that seems to happen only for specific cards/drivers.

import bpy
for obj in bpy.data.objects:
    if obj.type == "MESH" and obj.data is not None:
        if obj.data.validate():
            print(f"Error found: object {obj.name} had invalid mesh data!")

https://docs.blender.org/api/3.2/bpy.types.Mesh.html#bpy.types.Mesh.validate

[Midnight Arrow]

Will that change the vertex indices though? Because that will ruin any morphs unless the import also reshuffles them too.

[Alessandro Padovani]

Yes I fear that's unavoidable if the geometry is broken and needs to be fixed. That’s why we may show a warning to the user in this case.

[Thomas Larsson]

Meshes are now validated. Materials should be ok because validation takes place after material numbers have been assigned, but morphs will probably not work. This might be a minor problem, because hopefully invalid meshes are unusual, and props and environments usually don’t have morphs.

[Alessandro Padovani]

Commit 9ad11f4 works great.

I see there’s a message in the console when the mesh is fixed. In my opinion it would be better to show a warning in a window, same as we get when multires can’t work for example. Because I fear most users (including me) don’t look at the console after every import to check if something went wrong. But this is minor.

As for me we can mark as resolved.

‌

[Midnight Arrow]

I also think there should be a popup warning instead of just a console warning, so I’ll leave this open until Thomas says if he’s going to implement one.

[Thomas Larsson]

Popup implemented in last commit.

[Midnight Arrow]

Altight, I'll close it then.

[Alessandro Padovani]

As for commit 5c962ab, I may be a pita but have a couple notes.

1. The mesh name in the warning is not the same as the scene. For example for the fridge it’s “Fridge-1“ in the warning vs “SWK Fridge.001“ in the scene. This way in a scene with many objects possibly with similar names the user may be confused.
2. The warning itself is not too much explanatory. The user will have to look at the docs to understand what’s going on. Instead of “invalid meshes found“ it could be “invalid meshes found and fixed, importing morphs may not work“.

‌