Testing new QuadRemesher

Just to add a word of caution to this-

While Kangaroo can adjust quad meshes by moving the vertices slightly to make the faces planar, this is only possible when the initial mesh meets quite a high standard for regularity and curvature alignment.
The usual application so far has been for architectural panelizations, where typically the surface is smooth, and there are only a very small number of irregular vertices (and even then, it’s also often still necessary to not keep the boundary vertices fixed to allow the mesh to slide around to better align with the curvature).

From what I’ve tested so far, the output of the quad mesher does not reach the required level of curvature alignment on many meshes, and trying to make the faces absolutely planar is likely to lead to frustration.

If quads are oriented diagonally to the principal curvature directions (think of a diagrid on a cylinder), then it’s just geometrically impossible to make them planar through any amount of nudging vertices without changing the topology. While the QuadRemesher does produce meshes which are mostly fairly well curvature aligned, for complex surfaces it seems they often still deviate enough around the irregular vertices to make absolute planarity impossible.


I was wondering why I was having difficulty getting them planarised easily - this explains a lot, thanks.

Add a zabra&naked edge to the quad remesh command?

It sounds great

I did some tests and found that when the preview is active with complicated objects if you change from “Target Quad Count” to “Target Edge Lenght” it takes long time to calculate an unnecessarily dense object.
Has anyone encountered the same problem ??

Is it possible to change the default value in the “Target Edge Length” option? I think it is better to leave it empty or with a much bigger value.


1 Like

Very simple case, awkward result. I need taget grid ca. 0.2m

SRF to test.3dm (98.6 KB)

Try adding a little thickness to the surface then remesh. Afterwards, select and delete the additional faces. The small holes are going to try to be looped as open edges. This in combination with your edge length size mean that loops can’t be created since the edge length is as long as the hole. All of this together means you end up with unwanted noise.

So for this case having some additional face data from some extrusion surfaces helps the algorithm understand how these holes work and how to better preserve them.

srf to test remeshed.3dm (1.0 MB)

Adding thicknes is a general advise or this case only?

Just this case. The desired edge length is too large to generate the appropriate loops around the holes.

Cool, thanks!

1 Like


@mehran09197306634me thanks I’ve logged the request here.




Why you didn’t let me know?! :wink:

Discovered it today. This is beautiful.
Of course It is still fragile and very easy to break but it is growing.

Thank you all!




Hi all @Trav
When I execute a solid object with the quadremesh command it doesn’t work properly but if the object is converted to a mesh and then run with the quadremesh command…it is good

bug.3dm (1.2 MB)

yes i have this problem in my preview in rhino7

preview .3dm (900.6 KB)

Hi - that object gets selected with the SelBadObjects command. How did you create this?

?? :neutral_face:

That Patch surface has a bad trimmed edge. ExtractSrf > Untrim with keep trim curve > Trim again > Join… fixes the render mesh here. I don’t see this relating to QuadRemesh though :slight_smile:

If you extract the render mesh (which is used by the Quad Remesher) you’ll see that the current Rhino document settings generate a mesh with naked edges and thus you get a poor result. Either improving mesh settings or the box geometry resolves this.

Thanks, filed as https://mcneel.myjetbrains.com/youtrack/issue/RH-57472

@Trav I was filing this at the same moment as it seemed like a bug. I see what’s happening now, it’s a render mesh versus NURBS issue. Maybe we could prompt the user if the two are contrary in terms of naked edges?

1 Like