Check Breps and Meshes

Hello all,

We’ve got imported objects which are creating some bad geometries - these objects are all coming out as Closed and Valid but we need to catch these so they can be remodelled before they cause issues later on. I see that once I try to mesh these geometries I get at least some errors that I can start catching, but overall I’m wondering if there is a better workflow to catch these - these are all coming from separate files and ideally we need to be able to generate a spreadsheet that alerts us to where the erroneous files are.

I’m wondering if:

  1. Is there some mysterious command to catch these while they are still Breps?
  2. I can see that there is a Mesh.Check() method but I can’t seem to call it on any of my meshes or statically? (pretty generic errors of no definition or method)
  3. The created mesh is coming back as Closed and Valid from this, I see there is MeshFaces.GetZeroAreaFaces() and MeshFaces.GetClashingFacePairs() which I’m guessing could pick up intersecting faces and degenerate faces, but it feels a bit cumbersome - is there a better way?
    Also is there then a way to catch the differing MeshNormals, I see there is a Mesh.UnifyNormals() method, but if it fails to reorder the vertices or otherwise fails, how do I actually catch the different face directions? (again, I don’t actually need to repair the mesh here, I just need to flag it up so it can be fixed in the original brep file, is there a reliable way to find out which meshes are broken?)
    private void RunScript(Brep x, object y, ref object A, ref object B)
      Mesh[] msh = Mesh.CreateFromBrep(x, MeshingParameters.FastRenderMesh);
      Mesh rtnMesh = new Mesh();
      for(int i = 0; i < msh.Length; i++)
      Print(rtnMesh.IsValid.ToString() + rtnMesh.IsClosed.ToString()); 
      //this comes back as Valid and Solid despite the clear issues in the file
      A = rtnMesh;

Many thanks,


Hi Sash - by ‘creating’, you mean only in the context of generating meshes right? Can you post an example of one of these breps?


It’s an imported Step File - if I try to save it as a STEP file again it seems to become a “bad” & open object - the 3dm seems to retain the visual issues but apparently is valid and closed.

Thanks a lot,


Hi Sash - the object is valid but has very large edge & vertex tolerances - well outside the usual file tolerance -

Edge Tolerances: 0.000 to 0.316
median = 0.000 average = 0.033
Vertex Tolerances: 0.000 to 0.314
median = 0.000 average = 0.039

but this file opens with very loose, .1, tolerances. I’d say the problem lies there - it is a sloppy step file.


Hi Pascal,

Yup, it’s travelled through quite a few softwares before getting to us - the problem is that there’s a few thousand more where this one came from - how could I catch which ones have similar issues?

This is why I need to make a spreadsheet of identifying the erroneous files - though we can sort of predict based on their geometry where the errors will happen, it would be good if we had a preliminary pass done computationally so that the worst offenders were caught without having to click through them all.

This is where I was hoping to do some checks with the c# component to evaluate the part and a python script to export it to a spreadsheet (among with some other data along the way) and meshing it seemed to give me the most information to work with (as I say, they won’t need to be meshes, I’m just trying to troubleshoot them)


Hi Sash - OK, I see - so getting some of these is inevitable, in your process, but you’d like to be able to identify the bad ones, correct?



And there is quite a small percentage, so even clicking through them doesn’t feel like the most reliable way to spot them as they can be quite well hidden, if we can flag them we can go back and fix them


Hi Sash - testMarkOTEdges will probably help - to be more specific, you can get at the individual edges in a brep and check those in a script - Brep.Edges[index].Tolerance in Rhino Common.
(keep in mind that opening these as opposed to importing to a file with known tolerances, may not ring up any OT edges because these open with very large tolerances.)
Does that help?


1 Like

Wow, thanks Pascal,

It helps a lot - I think this solves the main issue of diagnosing the files. I will make sure to import them in then to catch the troublesome ones.

Thanks a lot as always!

P.S. And I realised that Mesh.Check() just isn’t available on Rhino6, so that mystery is solved too