nurbs and subdivs, a history

Matte: thanks so much for discussing that subdivision surfaces are, in fact, actual true smooth curved surfaces. The misconception that subdivision surfaces are just smoothed polygon meshes is very pervasive, and it is very frustrating to me. It’s really difficult (for some reason) to explain to people that that’s not the case.

I hate to get into a ‘yes they are/no they aren’t’ debate, but

No they’re not. :slight_smile:

Again, terminology is important. If you’re talking levels, you’re either talking multi-resolution, or smoothed polygon approximation. They are NOT subdiv surfaces. Yes, thats how everyone (except for maya) handles it and names it, but its not the same thing.

Subdivision surface = catmull-clark surface. Ie, its a curved surface description, and as such, methods have been developed to project curves on surface, and create trims, and do other nurbs style operations.

Further proof of this is again found in maya. If you’re just smoothing polys, there’s no way you can mathematically generate a clean curve from that surface, much less make an equivalent surface in another curve format. So in max/xsi, you can set the level really high to make it appear curved and smoothed, but thats it.

Maya has a ‘convert to nurbs’ function, which can take a subdivision surface, and generate an identical nurbs patch model. Ie, its converting from one curved surface description to another. And by happy coincidence, the nurbs cv’s positions will match exactly to the original poly cage you started with. Weird eh?

Nubs objects aren’t made up of polygons to come up with curve objects. It’s simple common sense. You can’t apply trimming on polyhedral objects expecting perfect-looking curves like nurbs with variable subdivision resolution.

Hmm…lemme make this plain and simple. Catmull-Clark doesn’t generate curves in the real sense. It applies resolution. Well, yes with the added surface tension. The object may look like it curved, but it still made up of polygons. It’s not a true curve. It’s a temporary application to aid modeling. If you apply subd level 1, for example, to make it permanent you’ll see that it is still made up of polygons twice the amount of the original.

You don’t need to apply a subd level to represent a picture of a cube, for instance. What if you want to apply fillets to produce the shape of a dice? You don’t apply Catmull-Clark, you apply simple subdivision first, then tweak those corners to make them look like they’re filleted.

My point in all these is, if you have to have features like trimming on polyhedral objects combined with subd, then you have to decide at what resolution you’re going to apply them. That’s exactly what stumps coders into producing these NURBS features. Obviously, to make perfect-looking curves you’re gonna have to apply subd with high-resolution levels.

It isn’t weird at all. Again, let’s make this clear. NURBS curves are perfect, mathematical curves. If you have to represent perfect curves on a slow computer and display them smoothly it would crash. Why? Because it can’t. Normally, it would convert them first with an infinite amount of polygons to produce that perfect-looking curve. That’s why Amapi gives you that option. It displays NURBS objects like they’re polygon objects depending on the resolution you apply. The higher the resolution the NURBS-looking they get. The only conversion needed is to put that display into hard-rock poly objects.

I sense a thread lock coming on…

Look at this link again:

http://www.research.ibm.com/people/i/imartin/subdiv-sharp.html

Its very clearly a subdiv surface with trims applied. Now look at the title of the original paper by catmull-clark:

http://www.idi.ntnu.no/~fredrior/files/Recursively%20generated%20B-spline%20surfaces%20on%20arbitrary%20topological%20surfaces.PDF

‘recursively generated b-spline surfaces on arbitrary topological surfaces’. Ie, if done correctly, the final limit surface is a b-spline patch, not millions of polygons.

Your statement (“what level does the trim work at”), could easily be applied to nurbs. You can preview nurbs at several different quality levels in maya, but you know that ultimately you’re dealing with a smooth surface. Same for subdivision surfaces.

I repeat, nurbs curves have fixed resolution. You’re confusing the actual mathematical curve with the way apps like Maya displays it. It doesn’t produce extra vertices like polys. Fact is, vertices, edges, faces don’t even apply to nurbs. They can be anywhere on the surface. CV’s are there to aid YOU in editing the object.

blendDoodler

sketchup is for sketching architecture and not for working on the finale 3d models.
sketchup is great when you have some nice boxy house models. everything
organic gives you a problem when you want to perform boolean cuts in it.

at this point apps like archicad are a much better solution. they also offer static versions. and when you need to create free form tools which or patches based on formulas you often use the NURBS tools in there.

also Subdivision Surfaces are nothing else than interpolation of space. you still work with a low polygon cage below.

Rhino calculates to the point where two nurbs patches intersect. what you see graphically is nothing else than a rough visualization of that.

smooth proxy in maya is what you want. it is similar to subdivs. however it only supports smoothing. it is like an interactive smooth tool. i rather prefer the subdivision because it can crease edges, points, and faces.

mh subdiv with perfect booleans? it would be nice but does sound like it will be possible nor ever happen. i assume that the resolution dependency of subdivs is just the problem here. what works perfect in NURBS is not present in polygons.

blendDoodler

Heh, and you’re confusing exactly the same issue with subdivision surfaces. As you point out, Nurbs modelling tools expose cv’s to help you edit the object, subdiv surfaces expose a polygon cage to do the same. The end result for both is identical, a spline patch

“Subdivision surfaces are, in fact, actual true smooth curved surfaces”??? That’s an oxymoronic thing to say.

BlendDoodler, subdivision surfaces are true, curved surfaces. That’s what Matte has been trying to explain to you.

He even pointed out the original research paper for Catmull-Clark subdivision surfaces.

If you’ve ever taken a calculus class, then you must be familiar with the concept of limits, as well as the concept of infinite series. Subdivision surfaces are based on those concepts.

Subdivision surfaces are defined as the limit surface that is achieved by an infinite series of subdivisions. And the resulting limit surface is perfectly smooth, and it is very precisely defined. So precisely, in fact, there are algorithms for calculating exact points on that limit surface, which is in fact another way to calculate and render subdivision surfaces (if you’d like me to link you to the research paper, just let me know). So precisely that Catmull and Clark proved mathematically that it has C2 continuity over the entire surface except at extraordinary points where is has C1 continuity (meaning in layman terms that they proved that it is a true smooth surface).

The “polygon cage” of a subdivision is really just control points with topology information. Nurbs are the same, except that the topology is implicit since the control points for a single patch are always in a grid.

This might be hard for you to believe, but Catmull-Clark subdivision surfaces and Nurbs are actually closely related. Catmull-Clark subdivision surfaces generate Bezier surfaces whenever it is topologically in a grid (it has different–but still well defined and related–behavior when that’s not the case). And Bezier surfaces are a sub-category of Nurbs surfaces.

Asking what subdivision level you use to do booleans on a subdivision surface is like asking what tessellation level you use to do booleans on a Nurbs surface. In practice, both Nurbs and subdivision surfaces are tessellated into polygons in order to render them (with the exception, perhaps, of a very few ray tracers), but in theory both of them have control cages that indirectly define a perfectly smooth surface.

The reason that they’re called subdivision surfaces is because they’re defined by an infinite series of subdivisions, not because you subdivide it just a few times to get a smooth-ish polygon mesh (although that is a useful way to tessellate it for rendering).

Man, you just made the subject more complicated than it actually is. You need to explain in plain language the relevance of subd levels. The way you have explained things, they don’t have any.

For those new to NURBS, check out this brief article to give you a basic idea of how they can’t seem to escape the use of polygons especially during rendering and display time: http://www.hydraulicdesign.net/meshes.htm

cessen

as far as i know Maya has a true subdiv implementation while the majority of other software do not. in fact as far as i know also renderman can render those subdiv
directly without tesselation - like it is treating nurbs.

i get this feeling that we all started to use keywords for the wrong terms.
sofar that we do not even know it anymore. thanks a lot for your deep explanation.

All that’s really needed is just a label–a flag on the mesh that says “this mesh should be interpreted as the control cage for a subdivision surface, not as a direct poly-mesh”. In that sense, no, Blender, XSI, etc. don’t have true subdivision surfaces. But it wouldn’t be hard to add.

That sounds odd, but it makes sense when you stop to think about it. The only difference between a polygon mesh and the control cage of a subdiv surface is how it’s interpreted and used by the renderer.

Pixar’s Renderman renders subdiv surfaces the same way it renders Nurbs: it tessellates them down to a sub-pixel level. So, yes, for most intents and purposes it can be considered a direct rendering of the surface, but if you want to get really technical (and I’m sure you do ;)) that’s not the case.

That’s very possible. I also think the name is misleading in the first place, because it gives rise to thoughts of normal poly modeling operations. It would have been less misleading to call them “infinite-subdivision surfaces”. :wink:

It’s also confusing because nothing is really different from poly-modeling from the user perspective (aside from it being a smooth surface), so people assume that must mean it’s the same as polygons. But honestly, that’s the whole reason that subdivision surfaces are awesome: you get the flexibility and ease of modeling like polygons, but you also get the perfectly smooth surface like nurbs. It’s like the best of both worlds.

It’s also confusing because most packages implement it as an extension of their polygon system. It makes sense to do so, since it’s pointless to write duplicate functionality (there’s so much overlap), but it does confuse the issue.

Exactly. They don’t. At least not to any of the discussion I’ve seen so far.

The plainest way I can think of to explain it is the following:
Subd levels for subdivision surfaces are akin to tessellation levels for nurbs: they are both just approximations of the true, curved surface. In both cases you would have to set the subd/tesselation level to infinity to get the true surface.

So, before this gets locked (which I hope it doesn’t because it’s a good thread), I have a question, just to see if I’m following.

So, I’m getting that, subd levels correspond with discrete iterations of catmull-clark. Run it once on a mesh, you have a subdiv 1 mesh (basically the mesh you get when you apply the modifier in Blender). Run it infinitely, and you have a true curve. So in that sense, the algorithm describes a true curve, but in practice actually results in subdivided meshes.

Is there some kind of shortcut to calculating arbitrary points on a the limit subdiv curve, other than repeated iterations of the catmull-clark algorithm? If so, is that what Maya’s “true subdiv surfaces” is all about? Because obviously using arbitrary subdiv levels in Blender is only feasible if your idea of “arbitrary” is “2 or 3”.

My point is that I can see in principle how catmull-clark describes a true curve, but I can’t see what exactly that would mean in practice, unless there’s another way to calculate that same curve. Is this the point of the originally posted article? Is this approach different from Maya’s true subdivs, or is the point here just that Maya’s is poorly implemented?

Yes there is a way to compute points on the limit surface, see this paper by Jos Stam, who works at Alias. One reason why you might not see this technique used in other software is because it is patented by Alias.
http://citeseer.ist.psu.edu/stam98exact.html

The trick about making subdivision surfaces display exact is not so much about how you compute points on the final surface, by subdivision or using formulas from the above paper. That’s really an implementation choice, there are only so many pixels on the screen, and at a certain subdivision depth there is no difference. To display subdivision surfaces exact, you need to either adaptively subdivide the mesh, or adaptively compute more points on the limit surface. The latter technique is likely more efficient and simple, but both should give the same results.

I see. Thanks!

So, it looks like the approach in the paper in the first post would add a number of operations to the possible toolkit of things you can do with subdiv surfaces, bringing them at least more in line with what you can do with NURBS. Is there a catch? Anybody have any idea how deep the re-coding of the present subdiv surfaces would need to be? The abstract emphasizes that the approach “remains within the multiresolution subdivision framework”. Does that mean it could be implemented more or less on top of what Blender already has?

at a guess I’d say no, but I’m not a programmer. thats where this conversation goes beyond my knowledge. :slight_smile:

the catch? nurbs objects are always made out of even patches.

mayas subdiv does not allow anything besides 4 side polygons.

i am not sure. while cessen mentioned that the internal structure
of nurbs and subdivs are similar i dont know if they are the same.

but i am not a coder so i do not know. i just asume that there must
be a difference. otherwise we would have that ueber tool already.

nope, i’m testing now, i have 3-sided, 4, 5, 6, even 7 sided polys, converts to subdiv fine. the wireframe on the subdiv surface looks pretty funky, but it can be done. And just to make sure, I converted to nurbs too, works fine. Again, crazy patch layout, but it works.

I think thats half of jos stam’s clever paper, pre-calculating how the patch layout should be around ‘extraordinary points’ (ie verts with anything other that 4 edges connecting to them), and storing it in a lookup table for fast access and drawing.

And to test to its logical conclusion, I projected a curve onto the surface, and trimmed it. Behold, a trimmed subdiv surface. I can still edit the polycage (its slow though), and the surface+trim update.

http://www.tokeru.com/matt/subdivTrim.jpg