Thickening subd with offsetsrf creates weird bumps

Close but no cigar:
image

G

I didn’t spend much time making the control polygon looked clean, but skewed faces there are not really an issue for the NURBS conversion. On regular quad faces the NURBS conversion is exact, so what you see in the SubD is what you get in the NURBS.

Those tiny faces at the corners with a vertex that has incident edges at almost 180° are the really annoying ones because they are impossible to get to look right on the SubD, and the NURBS mesher makes them look bad in Zebra / renderings.

1 Like

In my workflow, this is currently the best solution. Even having triangles or worse… let them be in a planar area of the model and it’s fine.


That “yet” … we are anxiously waiting here! :upside_down_face:

@pierrec
my idea was more like this:
let s say there is a perfekt G2D7 option in the ToNurbs (Curvature G2, Degree 7).
_ToNurbs G2D7
resulting in a degree 7 Surface
_fitSrf tolerance=0.01 U-Degree=3, V-Degree=3
should do a good job for most production techniques
… and nowadays many CAD-system can handle more then Degree 3 I think…

I didn’t realize you posted that. It looks better but there certainly is something still happening there.

So it isn’t technically a smooth joint. I can barely see the joint on my computer though. Does that mean that in most cases it will be usable?

If SubD isn’t G2 at star points then what is it?

Yeah I have to agree this looks worse than the bumps created by the regular tonurbs process

It sounds like there is hope for the future and a future version of rhino will have a simpler way to get these kinds of "saddle"s to translate to nurbs better and easier?

I’m getting the vibe that maybe the SubD to NURBS tools aren’t ready yet. I wasn’t aware of a native SubD offset tool when I started this so that’s nice to know about. Is there anywhere else that I could really take a SubD though? When I export to STP I think it’s converting it to nurbs still. And Keyshot won’t even import the file.

You are not wrong. But neither fully correct.
We are working with SubD since 2 years now. Everything is fine once you learn how to avoid the defects/shortcomings of current tools.
We can’t manually chose how faces are packed. G1xx is better but still not on the final target. Tools to model/analyze SubD objects are incomplete and far from excellent… and rhinocommon support for SubD is absolutely totally absent.
But SubD works! Fast and quick, reliable. The difference from 6 and 7 is huge just alone thanks to SubD.

STEP format doesn’t support SubD geometry type (if i’m not wrong). So if you export a SubD to a .step, rhino is automatically doing the toNurbs conversion first.
You better do the conversion yourself to see any possible defect before the export. Wiser.

Keyshot use rendermeshes saved in the .3dm file. If you model your project, start to finish, in wireframe mode (so never meshing your nurbs geometries), keyshot will see nothing.
SubD are “glorified meshes”, “smoothed meshes”. Usually the meshing of nurbs is heavy and done by the cpu, and saved on the .3dm to avoid recalculating it all the times. SubD to mesh conversion is much easier and faster, probably done by the gpu (just a guess), so not stored in the .3dm (guessing here too). If you need to see your SubD in Keyshot, do ExtractRenderMesh or convert to mesh, or to nurbs (shaded mode) …

What is Rhinocommon?

So thus far, the only way to do the conversion and get something remotely usable is the subdivide trick + g0 tonurbs conversion. But even with the subdivide trick, G0 isn’t going to be continuous and G1 has some bumps.

Both will have some noticeable problems in manufacturing or visualization depending on the manufacturing capability or visualization angle, respectively.

I totally agree with you that SubD seems like a really fast way to get the design out there but if I can’t do anything useful with it then it’s kinda pointless.

Let me know if there’s a nurbs conversion trick I’m missing here.

From Rhinoceros Help - ToNURBS | Rhino 3-D modeling (mcneel.com)

ExtraordinaryVertex

Continuity on a SubD at extraordinary vertices is G2. When converting a SubD to a polysurface, extraordinary vertices can only be approximated. This option controls the continuity of the polysurface at extraordinary vertices. Away from extraordinary vertices, the polysurface is always G2 in smooth SubD regions.

Zebra analysis shows G2 near an extraordinary vertex on a SubD.

G0

Makes the polysurface G0 at the extraordinary vertices. The shape of the polysurface will be as close as possible to the SubD.

G1

Makes the polysurface G1 at the extraordinary vertices. The polysurface deviates from the SubD a little bit more than G0.

G1x

Similar to the G1 option, but tries to make the edge normal deviation around extraordinary vertices 1 degree or less.

G1xx

Makes the polysurface G1 at the extraordinary vertices and uses double knots on the isocurves near the edges. More control points will be added to improve the smoothness of Zebra stripes.

G2

Makes the polysurface G2 at the extraordinary vertices.

Forcing G2 adds bulges or dents around extraordinary vertices.

How can it be that

and

?

The math used for SubD and NURBS is different.

SubD math is inherently G2 continuous at extraordinary vertices.

NURBS math can be G2 continuous at extraordinary vertices only in certain situations.

SubD math can be exactly converted to NURBS math except at extraordinary vertices. (There are special situations where the SubD math can be converted exactly to NURBS math at extraordinary vertices.) That is how the math works.

Conversion from SubD to NURBS at extraordinary vertices requires tradeoffs between level of continuity, magnitude of deviation from the shape and number of control points.

It it possible to tell the toNURBS command to put in more control points or is that what subdividing the subd does? I guess using G0 with more control points, while it never will be “continuous”, the deviation at the boundaries will be so small that it won’t matter?

Charles