QuadMesh prototype command available in latest WIP

Hello David,

I am very excited about this feature and did a few tests… attached a simple object that turned out buggy…

best Andreas

quadmeshbug.3dm (2.5 MB)


The main reason this happens is because the triangle mesh that we get from meshing the surface has degenerate edges. The meshing of the input surface uses the Rhino triangle mesher. In my quad mesher code I am trying to automatically fix these issues so that the main QuadMesh algorithm is given a good, clean mesh. This doesn’t always work, though.

In order to see the problem, try using the Mesh command on the surface and set “Maximum edge length” to “1.0” (uncheck Refine Mesh and Pack Textures). Then use MeshRepair on the resulting mesh. It should report 10 degenerate edges. This can be fixed with MeshRepair. After the fix, it will report 20 naked edges. This can also be fixed in MeshRepair by clicking “Fill small gaps”.

Now we should have a good input mesh. Unfortunately, using this “custom made” mesh as input will produce a very strange-looking quad mesh, with even more holes than before. I need to do further investigation to know what is going wrong in this case.

Thanks for testing!

Hi David and @bobmcneel,

Reading this reply with an outline of the workflow and problems encoutered it feels like you are patching problems with problems.

What I deduce is that the core mesher causes ‘dirty’ meshes that subsequent tools need to fix in order to make the mesh useful for their purpose. I was expecting the quadmesher to be a new approach circumventing the old inadequate mesher. It seems now however that the errors created by the old mesher will keep percolating through.

Are there plans to fix the core mesher at any time in the future instead of building on it?


1 Like


I’m going to reproduce your comments here and answer each of them:

Note mesh on cone side now pretty good, though meshing of cone base still not symmetrical, which seems to cause a twisted location of side meshes. (This seems improved over previous WIP, but is still there.)

Yes, it looks much better now. This is the main improvement I’ve made since the last update. It allows singularity points to move around the surface so that stretching is minimized. It still has some issues though, such as the asymmetry. I need to take a look at that, because I don’t see any reason for why the base would become that “wobbly”.

Note open surface corners at A, B, C, D now used as quad corners. Something not right at E, though.
Changing Quadsize to 1 gives very good result. QuadSize 1.2 causes problem at F. 1.4 causes total disaster mesh. Apparently QuadSize values of 0.5, 1.0, 1.5 and 2.0 produce successful meshes on this surface, other values not so much. IF THIS IS INHERENT in quadmeshing, I think a slider control with interactive preview to chose among a set of values would be the way to go.

There is nothing inherent in the algorithm which would prefer quad size values of 0.5, 1.0, 2.0 over other values. The largest issue currently with the quad mesher is that the quad meshes contain sporadic holes, i.e. missing quads in places where it looks like it would be obvious where to put a quad. The reason for this is because of problems in how the surface is “unwrapped” into the 2d-domain. This is important to fix. I believe most of the problems you see with this model - in fact, most of all models - stems from this.

And yes, option-value retention during a Rhino session is on the TODO list :slight_smile:



In order for the quad mesher to work, it needs an input in the form of a triangle mesh. This input doesn’t have to be perfect, but degenerate edges can be quite bad. Every now and then, the Rhino core mesher generates a bad mesh, and QuadMesh suffers from that. It’s something that needs to be fixed, either by finding and fixing the degenerate edges, or by rewriting the core mesher, which would be a huge job.

The issues with the Rhino core mesher that interfere with QuadMesh are often very minor. Usually there are triangles close to creases with almost zero area. As long as these cases are correctly handled, the input is good to go. It doesn’t matter how messy the triangles look to the eye, QuadMesh really doesn’t have a problem with it.

I would definitely not say that QuadMesh “is building on top of” the core mesher. They are very separate.

Having said that, I can understand that people could get disappointed when they hear that the Rhino mesher is used as part of the quad mesher… But I can assure you, it’s not used in any fundamental way. It could be swapped out.


come on guys! this is waaaaay overdue. you know you want to :stuck_out_tongue_closed_eyes:


Hi David,

Thanks for the reply and insight. I still do hope these issues add some weight to the need to fix the core mesher.


1 Like

Thanks for the input Willem :smile:


Hi David,

First let me say that I have just installed Rhino WIP and the QuadMesher command alone is a HUGE thing!
Working back and forth with a subdiv modeler (Modo) this allows a great freedom in choosing the most appropriate approach for each geometry, without having to use plugins or other tools like ZBrush’s ZRemesher.

Even at its current state, fixing the problems with a bit of polygon reconstruction and retopology takes just a few minutes compared to the practically uneditable mesh created by Rhino 5.

So, congratulations, and keep up the great work!

If this can be of help, I have made a small test and found that, apart from the missing polys issue, the main thing that is missing is to have clean topology in correspondance of some surface transitions for lower density meshes as well as a system capable of adding supporting loops for small fillets and curvatures.

It seams that at the moment the only way to achieve both these results is to increase the overall density.

In the picture below, in the mesh generated with the lower density setting, the hole/external surface transition is not smooth: it’s not very easy to fix and it does not subdivide very well.

If it could be possible to have a circular loop there, then the local detail problem would be secondary, as it would be quite easy to add a couple of supporting edges (like for the top flat cap surface below).

However I’m not sure if the first problem can be resolved independently from the second one.

Please let us know if these types of examples can be of help (in case I’ll post the 3dm file) or if you are already aware of these issues and we should just wait for the next update :smile:


Hi, made a file to test out the quadmesher and it almost got it right. It takes time to calculate though.
Why is that?

quadmesh stress test.3dm (3.0 MB)

Hi Marco,

Thanks for the examples and pictures!

QuadMesh supports changing the quad size on areas of higher curvature, but I have chosen to not expose that functionality for now (it was exposed in an earlier version of QuadMesh). The reason it’s not available right now is that the current implementation helps just as often as it makes things worse. I know of a much better way to handle this, but I haven’t had the time to explore it yet. I am aware of the issue that your first picture shows. Could you try to increase the AlignmentWeight? Try to make it 10 times larger. That should force the quads to align better with curvature and perhaps create better transitions.

In short, I am aware of the issues presented here. Unfortunately I’ve been busy with other things lately and haven’t had much time to work on QuadMesh.


How long did it take to calculate? Could you also post the settings you used for QuadMesh?

QuadMesh does take longer now since it’s doing “node relocation”, which is basically a post process which moves singularity points around if it makes the quads 1) more square and 2) better aligned to curvature. It can make a huge difference in some models.

Hi David,
I used the default settings for the quad mesh.
Do you get fast calculations?

I don’t get fast calculations. QuadMesh is quite slow, and gets much slower as the number of vertices in the input model increases. The reason it is so slow is because it is doing mixed-integer quadratic optimization. Twice!

My thinking is that it doesn’t matter if the calculation is slow if I get very good output in the end. Of course, more work needs to be done in that department.


OK, that makes perfect sense. Looking forward to see it developed.

I have tried an alignment weight of 500 and 1000 but I couldn’t see significant differences. I guess it depends on the individual case.

However since this is a wip I think it’s pretty normal.

I really think you have something big here, and many 3d modelers could be more inclined to use nurbs for hard surface modeling if they knew they would be able to have nice meshes with a single button operation, so hopefully you’ll find the time and resources to refine the command!

And regarding your comment:

Personally I totally agree.


Well, there is a speed at which everyone will think the tool is completely useless, another at which a lot of grumbling will occur, a third which will bring smiles and yet another that will produce wide-eyed amazement.

I just don’t know what these are in hours and milliseconds for any given job. :smile:

In most scenarios I would prefer both a fast mesh and a slow one. It would be comparable to a render, do I need a quick sketch or a high resolution photo realistic one?

And regarding long calculations: knowing progress and estimating completion is key.

As well as cancel abillity.


I finally tried the quadmesh on a real project. Impressive progress, the results that I got is definitely something that I can use to take a nurbs model to SubD and explore design options. …that being said it could be better. in some areas of high detail the mesher left complete gaps, it’s that the approach to it? if detail smaller that the density chosen, gets ignored? …not a bad idea, just wanted to understand it.

Can I share my file with the RMA genius working on this? Would that be @DavidEranen? if so, David, whats your email?



gustojunk - thanks for the feedback!

Detail doesn’t get ignored, but in cases where you have a flat:ish surface which has sudden, local detail it can be tricky to go from large quads to small quads within a small enough distance to accommodate the increase in detail. There are several approaches to fixing this, ranging from decreasing the target edge length, to trying out different algorithms altogether.

Keep in mind that for the last several weeks I have been busy with other things so not much has happened with QuadMesh.