Quad remeshing and Sub-D in Rhino has given us a great reverse-engineering tool, but it seems to choke at the last step, when it comes to converting the sub-D to NURBS.
It seems to be linked to the original number of faces rather than the number of patches because in the attached example, I have a 68417 face sub-D, so yeah, it’s quite a lot, but the number of patches seems reasonable.
So why does Rhino hang in a limbo when attempting to convert that to NURBS ?
You should enable “Packed” when converting. Packed merges a quad face grid into larger NURBS surfaces, instead of converting every single SubD face into an individual NURBS surface.
Otherwise Rhino generates an enormous amount of separate surfaces, and depending on the PC performance it can easily freeze or become extremely slow.
Personally, I only leave the option that converts faces into individual surfaces enabled when the face count is relatively low.
I do enable “Packed”. Did you manage to Nurbs this ?
My computer is a juggernaut, and it can’t handle it.
Left it running all night. What I find strange is that the memory and CPU usage is very low, so I guess Rhino is just procrastinating around and not trying very hard for some reason.
Hello Olivier,
Unfortunately, I don’t have an answer. But since I’ve known you for a very long time, I feel free to say that your Rhino is probably telling you what you are allowed to permit yourself in this life: “just procrastinating around and not trying very hard for some reason.”
And that’s despite you being a juggernaut…
I see that you import your quad mesh in Rhino and then “Quad remesh” it again in Rhino to reduce the face count. Sadly, a lot of subtle details are lost at this step.
I used the Exoside remesher in Blender.
If I don’t use “adaptive size”, with 41000 faces, I am able to get a nice result.
Still trying to understand what are the limitations of the “To Nurbs” algorithm to get the best result possible…
yes by reducing the quad some details are lost, but this evening when I’ll be at home I’ll do a test with my PC, and I’ll make a subdivision not as shown in the video but less invasive so as to maintain more details
However, if you need to mill it, why not leave it in mesh? For the machine path, it’s fine anyway and you don’t have to struggle with the conversion.
Some toolmakers in the past have refused meshes because the toolpath cannot be optimized. Perhaps the CAM software is more capable now so it is a non issue?
@cdordoni Usually when I need to create patterns, textures, or organic structures like floral details, that area is modeled as a mesh, while the rest of the design stays as surfaces (smooth parts). In this example, for instance, the wedge is a NURBS object, while I converted the quilted effect into a mesh. It also has the advantage that commands like FlowAlongSrf tend to work better and faster in those situations.
Sooner or later I think I’ll publish a video showing how I work between NURBS and meshes, because a lot of colleagues keep asking me how I do it — things like, “How do you match the mesh so accurately near the surface edges?” and so on. At first, most people think it has to be either NURBS or mesh, but they’re just two different mathematical systems used for the same mold. Usually you don’t even notice it here, because for example I only enable the wireframe when I actually need it in the viewports.
So, what I did after lunch was this: I took your file and kept it as a much denser quad mesh, then I exported it as OBJ instead of STL (I don’t know why, but STL doesn’t seem to work properly — it’s actually specified inside the program). I imported the mesh into the new version of Plasticity, which now has a function called “Polyspline.” I noticed that, unlike Rhino, it can convert a very dense quad mesh much faster with the same PC hardware. In fact, even on my work PC, which is 10 years old, I managed to do it, while in Rhino I couldn’t complete the ToNURBS conversion with such a dense mesh.
