Ok, so I’ve ran some test. Had some successes and some failures. I moved onto a Comlicated Lego Piece.3dm (1.3 MB) I modeled. It had some issues with non-manifold edges. So I fixed that (Atleast according to Rhino 6) and then tried to quadmesh. It says the object has non-manifold edges. But when I run a showedges it says it doesn’t have any non-manifold or naked edges. So one of the two commands seems to show a bug. But maybe not?
Good eye Willem, I didn’t even think of that. I didn’t look too far into the model, I guess I let the technology do too much work for me.
Thanks for testing. I’ve just fixed the issue you were having with zero-area triangles. It should be available in next week’s WIP.
Here is the output with QuadSize = 0.5
There are some uneven quads at the top and bottom which is something I’m working on fixing currently.
Not much progress on these issues as of this week’s WIP.
Here’s some additional testing on the Sept 22 WIP using the same objects. Please read the revised notes.
V6Test01 003.3dm (2.4 MB)
I’d also be grateful if you could give a description of what each of these options and reported items are:
(You know you’ll need to do it eventually anyway; a draft right now would help us testers )
Edited 9/24/15 10:30 pm EDT to correct link to attachment .3dm
This looks very promising!
And do you think it would be possible to make a “reducemesh-quad-remesher” tool based on some of the work you are doing?
I was going to respond to your previous post last week as a new WIP went out, but because of build issues it didn’t go out as planned. I will get back to you once the latest version of QuadMesh is up. Things have improved in some areas and the model in your post works better now.
I’ve been thinking about having a post-processing step after you’ve run QuadMesh where you can selectively increase or decrease the density of any part of the quad mesh. This could also happen automatically until a certain tolerance criteria with the original surface is met.
But I’m guessing you want the reduction to happen first, and then quad mesh the result?
Hi David, that sounds great.
I just thought it would be great with a (low poly) quad remesher that could be used on scan data and other meshes, that’s all, so what happens first and last doesn’t really matter to me I think.
I am very excited about this feature and did a few tests… attached a simple object that turned out buggy…
best Andreasquadmeshbug.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?
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
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
Thanks for the reply and insight. I still do hope these issues add some weight to the need to fix the core mesher.
Thanks for the input Willem
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
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)