SubD development status?

Hi all!.

Reporting more bugs about SubD:

  • creating a box SubD on a Cplane doesn’t work. Output box is always world-oriented (and with wrong sizes)

  • SubD cylinder radius changes depending on if it is “solid=no” or “solid=yes”

Solid version have control polygon points exactly at radius distance.
Non-solid version have subD surface with vertexes at radius distance (this one is surely better)

Also, the 2 bugs reported here SubD bevels feedback - #8 by BrianJ are still unfixed.

Still, any tool between Curvature / Draft / Environment / Zebra analysis have that:
2021-02-26 12_17_48-Window
which is completely ignored.

The new function “Create Draft Curves” in Draft analysis, extract curves from a SubD by actually using a G1x (guessing?) version of output, which often is really different than what seen on screen.
2021-02-26 12_59_12-Window

I think I managed to convince my boss/employer to switch from RH5+TSplines to RH7+SubD.
But often we have troubles with the tangency that is not respected.

We love how SubD is perfectly integrated with rhino and how snappy fast it is.
But the actual implementation feels imprecise, un-technical …

We can achieve great precision and smoothness with rhino in general.
And that’s true also with TSplines (apart from the really really slow computation and glitchy implementation).

With SubD? Nothing of that sort.

There were any development regarding subD tangency problem?

And why on YT that problem is marked with “Release target 8.x” ?? :frowning_face:

It is my personal opinion that this should get all the possible attention and effort from McNeel staff.
Rhino works fine. Other Bugs can have workarounds.
But this SubD tangency problem is a missed goal.
What’s the point of having subdivision surfaces if then the CNC is going to “hiccup” over the creases?
Or when trying to offset the surfaces of complex parts, 100% of the times is going to have open edges?

Should we consider SubD a “toy” inside and alongside the really professional Rhino and GH?


Oi… I see this - thanks.
RH-63024 SubDBox: only world is used
RH-63025 SubDCylinder: radius varies with Solid=Yes/No


1 Like

In that slider, the “for raytracing” is supposed to indicate that those meshing parameters apply only to raytrace renderers (Cycles, VRay, etc) using legacy meshes to render and do not render directly from the SubD. Viewport visual analysis modes (Zebra, etc. ) render directly from the SubD and use the same OpenGL mesh as shaded display. We understand this is confusing and need a cleaner UI. Ideally, this slider control would not appear for analysis meshes.

Yes, ok.
But that meshing part was really to underline how using SubD and SubD tools makes one feel like working with abandoned functionalities.

Old bugs forgotten, more to add. Tangency still absent at extraordinary vertex, we have only G0.
And, out of the G0, G1, G1x and G2 options, G1x and G2 really deform also the surface around the vertex, and that make the output not useful.

SubD are really fast and perfectly integrated. And that is awesome.
Can’t we have them smooth? Smooth as subdivision surfaces should be? Like T-splines?
Is that completely impossible without losing speed/performance?
Is McNeel actively trying some workaround? Something?

This … situation … should have been clearly stated in Rhino 7 sales.

I’m having difficult time using SubD for non-trivial cases.
I am the only one?
Just only in my area I heard other Rhino users forced to stick with RH5 and Tsplines… :confused:



1 Like

Rhino SubDs are Catmull-Clark subdivision surfaces. Away from intentional creases and extraordinary vertices they are curvature continuous (G2). At extraordinary vertices they are tangent continuous (G1) but typically not G2.

The NURBS representations of Catmull-Clark subdivision surfaces are approximations at extraordinary vertices. NURBS surface and can have geometry that SubDs cannot; perfect cylinders and perfect spheres being important examples. SubDs can have geometry that NURBS cannot; the corners of sectors at extraordinary vertices being the the pertinent example here.

There are currently 27 bugs to make the NURBS approximation smoother at extraordinary vertices. This will get attention in Rhino 7.x. This week we have more pressing SubD issues to address first, excessive memory use being primary.

Any “surface” you see in Rhino (NURBS, polysurface, extrusion, SubD, …) is being rendered with a mesh approximation. Keeping meshing fast while delivering a mesh that is dense enough to “look smooth” is a difficult problem and will continue to receive attention. The meshes used to render SubDs have the ability to show 4 or more levels of detail. The OpenGL code and raytracing we use to render SubD in Rhino 7 currently does not take advantage of the SubD level of detail feature and the ability to adaptively increase level of detail as you zoom in. At some point in the future it will and the core support is already built into SubDs.

The colors you see in visual analysis displays are 99% interpolated colors from actual values at render mesh vertices. A finer mesh creates a more accurate display at the expense of meshing time. With SubDs, once the OpenGL code is improved to use the build in SubD level-of-detail in an adaptive manner, these displays will be very nice.

SubDs currently do not provide false color curvature visual analysis calculated directly from the SubD. There are 5 active bugs concerning this failing and it will get address in Rhino 7.

The curvature flaws you show in your images are not in the SubD, they are in the NURBS approximation of the SubD at the extraordinary vertex.

I understand why you are frustrated and my guess is that you need improved ToNurbs continuity at extraordinary vertices, curvature analysis directly from the SubD, and OpenGL support for SubD adaptive level-of-detail to address the problems you have described. I believe we understand what’s at the heart of these problems, that we have solid strategies for addressing them, and the ToNurbs and curvature analysis issues will get lots attention in Rhino 7 service releases.


More information on the excessive SubD memory use mentioned above.

In Rhino 7.0 - 7.4, SubDs with fewer than around 50 faces were wasting lots of memory. In addition, SubDs were under reporting the amount of memory they used, which meant deleted SubDs were not removed from the undo list as quickly as they should have been.

The result of these two bugs is: If you are doing lots of SubD editing or you have a model with lots of small SubDs and you are moving those SubDs around, then Rhino 7.0 - 7.4 gobbles up memory at a high rate and creates a situation where your computer may run out of memory and crash.

Both bugs are fixed in Rhino 7.5.

Rhino 7.5 release candidate 1 will be published around 3:00PM March 9 2021 Pacific Time. Rhino 7.5 will be published around 3:00PM April 13 2021 Pacific time.

If you want to automatically receive release candidates, set your update frequency to “Service Release Candidate.”

(We publish a new Rhino service release the 2nd Tuesday of the month. For the preceding month we ship a continuously improving release candidate.)

Many of you send us crash reports. @mikko noticed a pattern in crash reports involving running out of memory and, after more investigation, found the two bugs described above.

What we do with crash reports:
We are not able to reply to each crash report. However, every Monday the “crash triage developer” looks at all the crashes that came in the previous week and assigns the crashes to somebody to investigate more deeply. In addition that developer looks for patterns in the crashes to help us focus our efforts on crashes that appear to be widespread. The task of being “crash triage developer” rotates through every developer on our staff.

So what?
I mention this to thank you for sending in crash reports and encourage you to continue to submit crash reports. It is extremely helpful if you mention what you were doing in the comment field of the crash report submission dialog. A simple comment like “editing subd” provides important context that we often cannot find when digging around the other details we get from a crash.


I imagine going something like this:

In the past few days I experienced multiple crashes of Rhino 7 and almost every time I had to restart my PC, because Windows 10 got very sluggish after each Rhino crash. Some of these crashes resulted in a complete freezing of Windows. I just found the present topic, however,I wrote some more about the crashes here:

Basically Rhino 7 crashes once the memory usage reaches a little bit more than 1000 MB, despite the fact that I have 16 GB of system RAM and my video card GTX 1660Ti has 6 GB of video RAM.

It sounds like this particular issue is not about editing SubDs. @stevebaer or @jeff can you help out here?

RH-63025 is fixed in the latest Rhino 7 Service Release Candidate

1 Like

RH-63025 is changed but still wrong.

Solid=No cylinder have SubD (smooth) vertexes exactly at user radius.
Solid=Yes cylinder now have control points at the corners of a circumscribed polygon, resulting in a rotated (unpractical) SubD cylinder that again have wrong diameter.

Note: SubD cylinder solid=No uses control points placed the same way as circle>Deformable at degree 3.

1 Like

I’ve passed this onto @tim to take a look.

1 Like