QuadRemesh processing gets stuck at 75%


I can’t get QuadRemesh to run on this mesh:
skullTriMesh.3dm (14.8 MB)

The process quickly goes up to 75% and freezes there for at least 6 hours. It’s a closed triangular mesh of roughly 600K faces and 300K vertices. I’ve tried several Target Quad Count, from 2K to 200K, Adaptive Size from 0 to 100 and Not Detect Hard Edges, with no success.

Please take a look, maybe the input mesh needs to match a set of conditions, like size, num faces, regularity, etc? It would be good to know that.



ok- I had to remesh this part in a different software, bring it back into rhino as an stl…(obj hung) , explode it and then a pile of tiny disjointed parts were revealed… once I removed them, the quad remesh succeed-

lesson for today> mesh input quality matters A LOT

skull_kfix.3dm (9.2 MB)

Interesting! Do you know of a systematic way of treating the mesh in such a way that QuadRemesh will succeed? The kind of artifacts that you found there are very typical of meshes coming from segmentation of 3D CT scans.

Also, I observe that the mesh you got is open. Do you know how to close it again like the initial input mesh?


I had to try it in both zbrush and freeform to decimate and clean it up a bit-

obj failed in both instances… stl did work.

you can fill holes in the mesh result with the fillmeshholes command

1 Like

Try the Check command on the mesh. It can identify disjoint meshes and the like.

Then there is a Split disjoint mesh command to fix it.

1 Like

Hi @scottd ,

There’s the following information upon Check command:

General information about this mesh:

Mesh has 334 pairs of faces that intersect each other.
  This can cause problems if you're doing mesh boolean operations with it.

Mesh has 98 faces where the face normal differs substantially from the vertex normals.
  These normals can cause problems if the ultimate goal is for rendering or boolean purposes.

Mesh does not have any degenerate faces.
Mesh does not have any ngons.
Mesh does not have any extremely short edges.
Mesh does not have any non manifold edges.
Mesh does not have any naked edges.
Mesh does not have any duplicate faces.
Mesh does not have any faces with directions different from the mesh as a whole.
Mesh does not have any disjoint pieces.
Mesh does not have any unused vertices.

ID: 2155f5e3-9da1-4682-befd-46c14eb19e9c (49)
Object name: (not named)
Layer name: Default
Render Material: 
  source = from layer
  index = -1

  Valid mesh.
  Closed polygon mesh: 282378 vertices, 566460 faces with normals
    Bounding box: (-204.402,25.8127,-139.079) to (-33.4105,219.883,1.03493)

There’s no disjoint meshes, so Split disjoint mesh does not change it.
What about these pairs of faces that intersect each other and these faces where the face normal differs substantially from the vertex normals?


Self intersecting faces can be a real problem. Somewhere the faces overlap or are twisted up.

Hi @scottd,

I managed to get a clean mesh with no self-intersecting faces, this one here (it just has 1 face with normal substantially differing from its vertex normals):

skullTriMesh02.3dm (14.7 MB)

However, QuadRemesh still gets stuck on it at 75%… After at least 2 hours, it’s not finished yet. I put the default parameters (except Detect Hard Edges which I don’t check). As the default target quad count is 2,000 and the input mesh has half million faces, maybe the size is so big that the underlying algorithm will take a lot of time to get the final mesh?

Also, when aborting Rhino 7 while running QuadRemesh I sometimes have my CPU unexpectedly running. I discovered QuadRemesh keeps running a process called “xremesh.exe” even after Rhino 7 is terminated (through the Task Manager). This happens only sometimes to me so I can’t reproduce the issue, it’s odd.
I use Rhino 7 SR0 2020-7-21 (Public Build, 7.0.20203.15405, Git hash:master @ 58c6ed1fec2f18dc6f0a87be0ee7238d65606456).