Why NURBS and SubD are not back and forth compatible?


Even though I have been taking it as a fact until now, I realised that NURBS and SubD are not back and forth compatible. For example, when a SubD surface (with extraordinary points) is converted to NURBS, the final surface is an approximation of the first, not an identical.

I guess this is because of the underlying maths of SubD, which -I guess again- is not compatible with NURBS (or maybe it is up to a point). Why is that? Do McNeel plan to make it 100% compatible, meaning that when one converts the SubD surface to NURBS they get an identical surface or object?

Thanks a lot :slight_smile:


1 Like

Hey Theofanis,

in general even if you rebuild a curve you have a deviation, so never exactly the same curve.
SubD is a mixform between mesh and nurbs and therefor it is mathematically impossible to “switch” without slight deviation.

The more controlpoints you allow to be created, the more precise it will end up. however, SubD is meant to be the less complex possible to obtain the smoothest surfaces. So if you choose to have very little deviation by using high complexity, you’ll end up with a very difficult to modify subD model.

Alternatively you can try “quadremesh” with your model to obtain an ordered mesh which can be converted more easily than Nurbs, IF your model contains Nurbs with high isocurve density.

I hope I haven’t written too much garbage from technical view and somehow answered your question :wink:

Best regards


Hello - no. They are not ‘100% compatible’.


Thank you both. That was the good thing with the T-splines plugin: low-DOF modelling, 100% compatible with NURBS. I guess I have to read more about SubD to understand the advantages they provide in modelling, provided they are not 100% compatible with NURBS.

There was a discussion about this in the March issue of Develop3D. Page 35. You can find it on-line.


1 Like

Thanks a lot :slight_smile:

The article has some info, but it is not absolutely true. For example, Scott claims that all SubD have a NURBS equivalent, which is not the case.

*For example, SubD surfaces with extraordinary points (EOPs) of valence 6 do not have NURBS equivalent. As far as I can see, SubD have a NURBS equivalent if they contain EOPs of valence up to 5. Valence-3 EOPS are behaving well too.

EDIT: My mistake. I checked it again and SubD with EOPS do not behave well, i.e., they do not have a NURBS equivalent (at least in my case).

@dalelear calling Dr. Lear… woudl you chime in here and clear this up?

All generalizations are false, including this one.


Hi John, can you please be more specific?

No. I was being ironic.
Poor font choice.

1 Like

I don’t get you to be honest. I suppose we are here to understand how things work, right? Do you have to add anything towards clearing things?

Just underscoring what has been said.
NURBS, SubD, and Meshes can all be used to describe 3D geometry.
They are not interchangeable.
Because of this, approximations and fitting are required to “convert” one to the other.
This will degrade the quality and accuracy of the model.

Reading a marketing article that quotes Scott Davidson should not be interpreted as an accurate and complete technical discussion. That’s not was the interview was about.

I don’t think we disagree. I was just trying to understand up to which point Scott’s claims were true, that’s why I started experimenting. You might have been ironic before, but believe me when I say I am a Rhino fan and I try to make the best out of it, as well as to contribute towards being the best product.

Thanks for wrapping it up!

Looks like I’m a little late to the show and JB handled it below.

The salient technical point is that the shape of a Catmull - Clark subdivision surface near some extraordinary points cannot be exactly duplicated using a NURBS surface.

This is a mathematical fact and thus there is nothing to “fix.” (Just like we can’t “fix” the fact that lines and circles have different mathematical properties.)

At these extraordinary points, Rhino’s ToNurbs function creates a NURBS surface that closely approximates the shape of the Catmull Clark surface.

If a person felt the need to understand the mathematics of the situation, I would begin by reading this paper by Doo and Sabin.

D. Doo and M. Sabin: Behavior of recursive division surfaces near extraordinary points, Computer-Aided Design, 10 (6) 356–360 (1978)

Then I would look for text books and papers discussing Catmull Clark subdivision surfaces that cited this paper and read them.

I don’t see any links to or direct quotes from the marketing material mentioned above and cannot comment on what was said.


Thanks for the detailed reply Dale. Since the underlying mathematical representation of SubD depends on Catmull -Clark, it makes sense that there can be no fix. I wasn’t aware of the fact that SubD solely depend on the Catmull-Clark algorithm; I mistakenly made the assumption that there would be an effort to develop something close to T-splines. My hypothesis was wrong, from which my question about back-and-forth compatibility initiated. Thank you for clearing things up. Thank you all.

Link to the Develop3D interview with Bob McNeel and Scott Davidson: Interview: CEO Bob McNeel talks Rhino 7 - DEVELOP3D


We chose Catmull Clark subdivison surfaces because that representation is completely in the public domain, is used by a wide variety of modeling applications, has been used in a wide variety of applications for decades, and is well documented in readily available books and technical papers.


Ha! Cliff Notes… :wink:

Sure, if one wants to be anal retentive about it. Or just draw and don’t worry about any .002 deviation no one can see or feel, while basking in the glory of all things SubD, where approriate. (Or NURBS when your manufacturing tolerances are .002… :innocent:)


to throw a bit of a shadow on all of that:

from wikipedia

none of T-splines, subdivision surfaces, or NURBS surfaces can always accurately represent the (exact, algebraic) intersection of two surfaces within the same surface representation.

also if somebody wants to make a T-Spline plugin for Rhino -
there you go, an open source Kernel

That’s another thing, but it is true. An intersection, is not part of the surface representation itself, therefore it can only be approximated. This is the case for every trimmed surface as well. The curve of trimming cannot be represented accurately by using any mathematical representation.

I am aware of that project. I have been contributing in developing something similar, but in C#, as a Rhino plugin. I’ll check again SourceForge’s to see if there’s anything interesting.