Hi @BrianJ I am testing out the new SubDCrease and it has great potential!
And the new ToNurbs command is also a great step forward regarding it’s patch layout.
But I see two big issues with it.
It makes way to dense nurbs. Like way-way to dense nurbs.
It makes way to dense edges.
I presume ToNurbs uses networkSrf as the underlying geometry generator.
And I think that is part of the problem. IMO ToNurbs should use:
Sweep2Rails or EdgeSrf as the tools of choise.
Generate edge curves from the nurbs in a much smarter way.
IMO an edge curve from a SubD patch should never need more than 6 control points as it is actually a just a blend curve. Doesn’t that sound right? Even though the edges of the SubD has different crease values?
Take a look at this file and see how massively dense the surfaces are. They will be impossible to edit as nurbs and thus not suited for an efficient subd-nurbs workflow.
I would expect a result closer to the gray sweep2 surface I remodelled below.
And in my opinion the front part of this object (the yellow highlightet one) should have been three nurbs surfaces. That way we would get something closer to a nurbs modelled object with better editability for future modelling.
And last thing. We need a 100% crease tool so we don’t need to type that in AND we need 100% to be 100% so we can have sharp edges like in V7.
It seems like the new gradual crease tool has replaced the old either-smooth-or-sharp option, but now we can’t have the good old sharp version. Sometimes this is needed.
Or did I miss something? If so I would expect others to miss it too
The following is my understanding, which could be incorrect:
Each face in the version of SubD used in Rhino can be represented exactly by one or more multi-span degree 3 NURBS surface. The exception is around extraordinary vertices where there there are not exactly corresponding NURBS surfaces so approximation is required.
ToNURBS converts each SubD face to the equivalent NURBS surfaces. Away from extraordinary vertices the conversion is exact. Around extraordinary vertices how the approximation is handled is determined by the ExtraordinaryVertices option. The option Faces=Packed merges NURBS surfaces which are in a grid into single multi-span surfaces.
The increase in the number of control points is a direct concequence of the “exact” conversion of SubD to NURBS.
That might be correct, but you can manually generate the same result if you extract the edges of a SubD and join them up (accordingly to the nurbs layout that is automatically generated) and then use NetworkSrf to generate nurbs.
My example above shows you can get the desired tolerance in the nurbs with a lot less isocurves, which is a much better for nurbs modelling.
Please double check my findings and see if you come up with the same results.
A quick experiment I did with one set of faces on one SubD surface results in the NetworkSrf result having more control points then the ToNURBS result. The number of control points in NetworkSrf compared to ToNURBS depends on the desired tolerance and the shape. ToNURBS does not have a tolerance - it provides an exact match where possible and close at extraordinary points.
The behavior of ToNURBS when used with SubD objects is analogous with it’s behavior when used with a mesh. When used with a mesh as input it creates a NURBS surface for each mesh face which exactly matches the mesh face. When applied to a SubD object it creates NURBS surfaces which exactly matche the SubD faces where possible, and close at extraordinary points. In general the results of ToNURBS may have too many control points for efficient editing. It is probably a mistake to try a workflow which anticipates editing of the results of ToNURBS without rebuilding/simplification first.
ToNURBS does result in NURBS surfaces which can be used as input to operations or exports which need NURBS surfaces. For me that is it’s primary use.
A tool which takes a SubD object or an arbitrary mesh as input and results in NURBS surfaces within a specified tolerance, with the number of control points dependent on the tolerance would be a different tool than ToNURBS.
Why do you think that? IMO utilizing tolerances to keep a model light and editable is a good approach. And ToNurbs has already changed since it’s original form, so if the developers want, it will probably change more.
What I don’t understand is why each face is turned into a nurbs with 16x16 isocurves when they aren’t needed. Rhino just needs the edges to be within tolerance for them to join.
I do not recall any fundamental changes in what ToNURBS does with SubD objects since it was introduced in V7. There may have been some expansion of how extraordinary vertices are treated during the WIP phase.
A SubD object conversion to NURBS using a tolerance which potentially could result in surfaces with fewer control points would need a fundamentally different algorithm and methodology than what ToNURBS has always used. That may require significant development and possibly some invention.
I don’t know how the ToNURBS command creates the surfaces exactly or if it would be possible to make them less dense. @pierrec Will know more on this. I know that at extraordinary vertices (e.g. five edges meet) we need denser surfaces for continuity.
I don’t see the bug with ExtractSrf using either icon. I tried preselection as well as clicking on a face in your SubD as well as with or without Copy enabled but it all works as expected here. What build are you using exactly?
OffsetSubD uses the control polygon so it’s not as exact as OffsetSrf but at the same time can be more forgiving in certain cases. With that said, I filed this tolerance request for the command in the past but it hasn’t been worked on yet. https://mcneel.myjetbrains.com/youtrack/issue/RH-58984
The Crease command is still in Rhino 8 for sharp crease. You can alternately use the CreaseAll option in the SubDCrease command. @pascal is I think putting Crease as a right click option on the SubDCrease icon to make this one click too.
