MeshProof — repairs the mesh, then proves it works

There is no such thing as a broken mesh in general. An open surface is useless for a boolean and perfectly fine for an export. Overlapping UV islands ruin a bake and mean nothing when you subdivide. N-gons are harmless in an engine that triangulates anyway and are exactly where the wobbles come from when you smooth-shade.

So MeshProof asks first: what are you about to do? Then it looks for what stands in the way of that operation, repairs it, and — this is the part no other cleanup tool does — runs the operation again and shows you the result in numbers.

The proof, in each case

Boolean. Your object is copied, cut with a probe cutter, and the result is measured: closed or open, how many non-manifold edges, empty or not. The report reads like this: the cut result was open with four boundary edges, now it is closed with none.

Bake. The UV layout is rasterised and the texels covered by more than one face are counted. On a cube with every face stacked in the same square that number is 41 616; after a proper unwrap it is zero. You cannot see that in the UV editor on a dense model, and it is exactly why bakes come out with one detail printed over another.

Subdivide. A copy is subdivided and the places where neighbouring faces disagree about which way is out are counted — the dark creases and pinched spots people complain about.

Export. The mesh is measured as an exporter will see it, after your modifiers: loose geometry, degenerate faces, unapplied scale.

What it finds

Non-manifold edges and vertices, open boundaries, coincident vertices, faces with no area, edges with no length, interior faces, faces that disagree on which way is out, loose vertices and wire edges, n-gons, unapplied and negative object scale, UV islands that overlap or sit outside the square, meshes with no UV map at all. Each one is reported only when it matters for the operation you chose, at one of two weights: it will break this, or it will make the result wrong.

Repairs that report what they did

Merging coincident vertices, removing degenerate faces and edges, deleting loose geometry, recalculating normals, filling holes when you ask for it, triangulating n-gons when you ask, applying the object scale. Every step prints its own number — vertices ten to eight, boundary edges four to none — including when it changed nothing, because a button that silently does nothing gets pressed again.

It touches only what you selected

The proof runs on a temporary copy, which is removed together with everything that came with it. Neighbouring objects are measured before and after in testing and come back identical. Filling holes changes the shape, so it is off by default and has its own switch.

Checked both ways

On a healthy mesh it reports nothing at all. On a mesh with deliberately planted damage it names exactly that damage. The same model under different purposes gives different answers — that is the whole idea. One hundred and eighty-two checks, green on Blender 5.1 and 5.2 — plus a separate run on data linked from another file, where the add-on refuses to repair and says why.

Compatibility

Blender 4.2 and later on Windows, macOS and Linux.

License

GPL-3.0.

Render: flicker, dark faces, speckle

The loudest complaint in the whole set of questions people ask about Blender is a render that flickers where two surfaces meet, and faces that come out darker than their neighbours. Choose Render and the add-on counts exactly what causes it: faces standing in the same place as another face, faces built on the same vertices, faces pointing the wrong way, faces with no area, and n-gons that are not flat.

The first four are repaired and the repair is proved by counting them again on the mesh the renderer actually receives, after your modifiers. On a test surface of 144 coplanar faces — the case that fools a naive check — it finds zero, which is what makes the number mean anything. With three faces laid on top of each other it finds three, and after the repair there are none. Sixteen pairs of faces pointing the wrong way become zero.

N-gons that are not flat are reported and left alone. Cutting them into triangles changes the model, and that is your decision, not the add-on's — so it says so in the verdict instead of doing it quietly.

There is no test render, on purpose. A test render would only prove something about one camera angle: flicker between two surfaces appears and disappears as the camera moves. What is measured instead is the condition that causes it, which holds for every angle, every engine and every frame.