I successfully converted the file to NURBS but it is too large to upload - 99 MB.
Command line history:
Command: ToNURBS
1 object selected. 0 NURBS curves and 68449 NURBS surfaces will be created.
68449 NURBS surfaces will be packed into 1277 larger surfaces.
To NURBS options ( DeleteInputObjects=No OutputLayer=CurrentLayer SubDOptions )
Converting to NURBS… Press Esc to cancel
Autosaving file as
Are you doing conversion in Plasticity?
@JKolodner yes, I updated the previous post and explained the little trick I used.
@osuire If you send me your email privately, I’ll send you the file. It’s too large to share here.
Hi @osuire and @davidcockey
I converted as well, with no problems at all… except the fact that it did take a long time (had it running in the background, so don’t know exactly how long).
-Jakob
@Normand Probably that’s why Plasticity’s PolySpline command works much faster: it seems to use the computer’s processing power more efficiently.
Maybe this command could be improved to better utilize the PC’s processing power. @Gijs @theoutside
Tonurbs
Doubtful. Virtually all “Content creation” tasks are inherently linear.
@brvdln, how long did the Plasticity Polyspline conversion take? (In your 10 yo PC).
Another things that Plasticity claims is that all patches are G2 all around. Including at corners. It’s time to kickstart the tires of this; are users, are more importantly, McNeel developers. I haven’t tested it yet.
G
@gustojunk
It took me about 8/10 minutes on my 10-year-old work PC.
What really surprised me about the Polyspline command is that it can convert very dense quad meshes like this one into NURBS, and it does a remarkably good job.
That said, I still prefer Rhino’s ToNURBS “Packed” method. In most cases, especially if you’re going to build a mold from the model, having thousands of tiny quadrangular NURBS patches is more of a disadvantage than an advantage. Managing that many surfaces quickly becomes heavy and visually cluttered unless you have a very powerful workstation.
Over the last few weeks at work I’ve had to convert several meshes to NURBS, and Polyspline has been very useful because, in some cases, Rhino would keep processing indefinitely or struggle with the conversion, while Polyspline converted those dense meshes to NURBS in roughly 5–10 minutes.
Thinking about Polyspline and Rhino’s ToNURBS, I have another consideration. Let’s say I want to preserve the quad-based structure, but I also want something equivalent to Rhino’s Packed option. It would be useful to have a sort of “Quad Packed” mode where, for example, an area containing 20 quad faces could be merged into 10 larger quad-based patches by intelligently absorbing neighboring regions, similar to what Packed does. This would significantly reduce visual clutter and file complexity while still preserving the quad layout.
Something similar to the ReduceMesh concept could work: a percentage reduction slider or a target face count. That would provide a nice balance between maintaining a quad structure and keeping the resulting NURBS model manageable.
For example, in this case I created an internal offset of the mesh by 0.8 mm, then converted the mesh into a quad mesh. To speed up the process, since Rhino’s ToNURBS was taking too long, I used Polyspline for the conversion.
This converted portion is useful for some of my milling strategies because, as @osuire mentioned, “Some milling strategies are exclusive to surface geometry.”
@JKolodner @cdordoni So the external geometry that will actually be machined remains a mesh, while I use an internal offset of that same mesh as a guide, first converted into a quad mesh and then into NURBS. This allows me to take advantage of machining strategies that require surface geometry without having to convert the entire model to NURBS.
I’m a bit late to this party, so I’ll probably be repeating some of what has been said already, but to answer clearly: there is no limit to how many SubD faces Rhino will attempt to convert with ToNURBS.
What happens when you convert a big SubD:
None of it is a hard limit, it’s just the accumulation of certain things where computation time grows quadratically that will make ToNURBS on a large SubD slow. And NURBS patches are not as memory-efficient as SubDs, so that can slow down things too or even crash Rhino by out-of-memory.
As for the multi-threading and other improvements, it’s in the list but hasn’t gotten to the top of it yet:
RH-69054 ToNURBS could use a progress bar
RH-69055 Any chance ToNURBS could be multi-threaded?
Part of the reason why these haven’t been a high priority, is that making a SubD or a Brep with 100k faces is kind of going against the spirit of SubDs and Breps. If the goal is to make complex but editable shapes, 100k faces is not going to fulfill the editable part of it. Rhino will break in other places than ToNURBS when you have too many faces in a SubD or Brep, and you would probably be better served to stay in mesh representation all the time (in a mesh-modelling software maybe), or export the SubD as a subdivided limit surface mesh.
Going from a point cloud to a controlled collection of surfaces (with as few surfaces each spanning as big of a feature in the model as possible) is the hard part of reverse engineering and AFAIK you can’t do that with Quad Remesh.
I’m sorry that this doesn’t really help your workflow of scanning and milling objects with intricate details. I hope better tools (maybe not SubD, maybe Polysplines will be it?) come along at some point to achieve that more easily.
hi Pierre,
What stops you guys from implementing Polysplines in Rhino (aside from resource prioritization, with is a major consideration)? It looks like Plasticity is licensing it from the creator, based on what’s said here (4:44 in timeline):
Is Polysplines a proprietary technology or could someone else build their own version based on the research published?
G
A post about polyhedral-net splines, aka Polysplines with links: Polyhedral-Net Splines (aka Polysplines) alt to Catmull-Clark
The researchers/developers/inventors have made available a software package which is free to use for research but contact the authors for commercial use.
A quick search at the basic USPTO website did not return any patents or patent applications, but that does not mean nothing exists. I have no idea if this is a T-splines type situation.
We’ll see if Pierre or someone else form McNeel responds.
Can this be considered an option? @pierrec
@pierrec , @gustojunk , @davidcockey I can’t see how this is better than the actual SubD in Rhino.
The result is really close to the unpacked geometry and this is worst than what Rhino does.
What really should be implemented is the T-Splines ability that we know has some major advantages over SubD.
Where do you see improvments?
Eh bien, merci Pierre.
Ca répond exactement à ma question.
Do you mean Quad remeshing in general, or Rhino’s implementation ?
I’ve been fooling around with the “Quad Remesher” Blender plugin (from a French fellow by the way), and I see lots of possibilities.
It allows to control where more quads should be used, and define clearly how quads should flow using material painting, which is similar to Rhino’s “guide curves” concept, except it works.
Packing already suggests the ToNurbs task can be solved in parallel, multithreaded.
Just create a fraction subd for each “color patch” in the packing, containing also a stripe of faces around the patch itself, and the result will be correct.
Problem is we don’t have control for a custom packing, so the final result will become further different.
Otherwise this would be a fun project to try to code.
My guess is that the bottleneck isn’t the convert of SubD faces to NURBS. But rather the joining of all those NURBS surfaces into a single Brep.
– Dale
Well, if that’s the case, why not at least output the surfaces instead of freezing the computer to death with no progress bar ?
Run ToNURBS with Faces=Unpacked
ToNURBS | Rhino 3-D modeling
That’s not what I meant. I don’t think Dale’s comment was about packing. Just joining surfaces, be they the result of packed Sub-d’s or not.
