Theoretical SUB-D


I’m so glad that you liked that.

I really could make a few small timelapse vids on making some facial features.

I’ll get on that.




This is a really usefull thread! Please keep it comming… :bounce:


Great tip! More, more!

I was a little pissed off about the deletion thingy, but really, with a 6 page thread you can’t easily draw anyone else in :slight_smile:

To me, with tools like smoothing groups and the like, subdivision can be used for much more than organic shapes. It’s just a matter of making it behave.

I still want to know how fausto could do this…sorry, i’m being repetitive :slight_smile: I mean sure, Ngons can work well in some areas, like flat surfaces, but on a curved surface…


Regarding the primitives it sounds you it would be possible to capture that into a macro, and thus make your own toolbar with buttons to instantly create these useful objects.

Anyway, as E.T. seems to ponder on as well, what is SubD in a MAX context? SubD is clearly something very different from your usual polys in Maya for instance, “SubD” has its entirely own set of primitives, it’s own set of commands only valid to SubD objects, for some reason UV-mapping is severly limited (no spherical, cylindrical, etc., only “planar” and “Automatic”). And if you want your straight ordinary polys you go through a conversion-process that, essentially, ****s things up enough to make you not want to sit and do that every five minutes.

But then in MAX… in MAX SubD seems to just be an “Editable Poly” object… Wanna convert back to ordinary polygons?, well that’s just two clicks away, and bam, Editable Mesh…
And wether you use the NURMs options available from within Poly, or with a MeshSmooth, you get the same result… so is using the MeshSmooth modifier SubD? Or maybe SubD has nothing to do with the actual smoothing of the object, but rather the technique used: loops, rings, quads, etc?

And what about this thing that hasn’t been mentioned in this thread yet: resolution-independancy?

I’ve been told that a proper SubD implementation is, or can be?, resolution-inderpendant. If you use SubD objects with Renderman (the Pixar render), you get a super-smooth no-edges-visible thing going, irregardless of how much you zoom. Just as you would with NURBS. You even get proper displacement and hair I was told, which is something ordinary smoothed polys can’t do. This is, apparently, partly why NURBS has been used to much on feature-films. It can be argued that NURBS are trickier to use, but you get completly perfectly placed, lit, and oriented displacement and hair it seems.
Let me stress that these Renderman tidbits are only what I’ve been told.

Okay then, I hope I haven’t rambled on for too long, I’m just confused as to what this “SubD” is. I’m glad to see that it seems I’m not completly alone on that. Good idea on making this thread 3DZealot, it nicely balances out the… ah… deletion-incident :rolleyes: I hope we can get to shed some light on these matters.

So yeah, my question is, I suppose, if the MAX way of SubDing is MeshSmooth? And if so, what about the resolution? You can easily zoom in on a meshsmoothed model and see it’s polys… The immidiate solution is of course to up the render-iterations, but that’s an endless game… too brute-force for my taste in the long run.

Or maybe I got it wrong, and Renderman and Maya and NURBS and all that, still requires tessellation through a global iteration-value? Ie. not some fancy dynamic tessellation or whatever that always keeps a curve smooth.

[edit]actually having tried the macro-recorder I now realise it won’t work with this, there is more to it than just recording and making a script out of it :)[/edit]


I found a great article on Subdivision theory at Gamasutra.

You’ll need to sign up to read it, but it’s free.

Written By Brian Sharp, April 10th, 2000.

First, what is a subdivision surface? The obvious answer is that it’s a surface generated through subdivision. To elaborate, every subdivision surface starts with an original polygonal surface, called a control net. Then the surface is subdivided into additional polygons and all the vertices are moved according to some set of rules. The rules for moving the vertices are different from scheme to scheme, and it is these rules that determine the properties of the surface. The rules of most schemes (including all the ones discussed here) involve keeping the old vertices around, optionally moving them, and introducing new vertices. There are schemes that remove the old vertices at each step, but they’re in the definite minority.

The one thing the control net and the eventual surface (called the limit surface) have in common is that they are topologically the same. Topology is a way of describing the structure of a surface that isn’t changed by an elastic deformation, that is, a stretching or twisting. A good example and common joke is that to a topologist, a coffee cup and a donut are identical. The donut hole corresponds to the hole in the handle of the coffee mug. On the other hand, a sphere and coffee mug are not topologically equivalent, since no amount of stretching and twisting can punch a hole in that sphere.

This is near the start of the article. I don’t know if i should be putting it here…oh well :slight_smile: It goes on to talk about different Subd schemes and how they work.


The “what is SubD?” question is a dead-end, it’s an argument that will go around and around for ever and has been covered countless times on this forum alone.

To sum up: The argument depends on whether you believe that

a) “SubDs” has a rigid, set-in-stone definition, and only means whatever the person who first coined it meant when he coined it, ie it is a description of one specific subdivision algorithm that allows a perfectly smooth surface to be generated at rendertime.


b) “SubDs” is just a fashionable buzzword and means whatever the most people who use the term mean by it, ie a catch-all non-app-specific modelling technique that involves subdividing a low-detail control cage to achieve a high-detail model.

In either event it is next-to-meaningless from the point of view of modelling workflow and technique, especially in an app-specific forum when that app has “SubDs” by only one of the above definitions anyway.

So can we please keep this to a discussion on modelling technique (I believe that is the spirit in which it was originally started) and leave the pedantry out of it? I am willing and eager to contribute, but not if the thread is in danger of degenerating into yet another semantics merry-go-round, arguing over aspects of terminoligy that have no relevance to Max anyway.


mrfandiwagon, thanks, that was most enlightening. That seems to verify that SubD can generate perfectly smooth resolution-inderpendant surfaces. Very neat.

But that’s not in MAX? We clearly have polygon-smoothing, via the Catmull-Clark algorithm I belive. But not the SubD-kind Pixar started. Not the SubD kind that other programs has?

Unlike Iain it seems, I’m interested in learning about the theory behind SubDs as well as the hands-on-modeling techniques. I think the basics regarding the “What is SubD?” question is answered nicely in the Gamasutra article… all without having to go through the firely hell of several word-splitting semantics-arguments that Iain apparently has seen. Unburnt as I am from those experiences I’m optimistic that we can keep it civil and (more or less) on-topic without having to ban any talks of theory or how other programs has handled their SubD implementation :slight_smile:

Ah, we’ll see as the thread moves along.

Where most of my theoretical-related questions have been answered by the article, I guess I’m mostly just left a little puzzled… Maya has evidently gone through a great deal of trouble implementing SubD, whereas when we got the Editable Poly in… MAX4 was it?, it was just this thing that people didn’t neccessairly see the use in at first, it all seemed to look pretty much the same as the Editable Mesh.

I can’t find them right now, but somewhere on the net I see from time to time these really nice illustrations that shows how to approch a corner without loosing an edge-loop. And if you have a triangle, you can “do this and this” and voila, it’s all quad again. And how to add details without adding tri’s and such. If someone has something like that, please do post, I think they could be valuable for people (like me :)) getting their feet wet with this whole quad thing.


Ahhhh, so the question about Ngons and tris is answered… kinda. Guess I’ll have to mess with them to find out what effect they have.

It’s good to hear Ngons in static objects are okay-- in situations like that gun, it would be hellish to have to string a new loop all through the object every time I added a corner to a new detail in one tiny spot. That’s one of the reasons I’ve put off working on my Trigun revolver model so long, I was dreading that.

As for SubD, I don’t see what the big debate is. SubD is making a model that gets subdivided at some point, and that isn’t NURBS, right? Okay. Moving right along…

[ul]How do we cut into our SubD models without losing the flow of the curved surface these details are cut into? Obviously it requires making the mesh a bit heavier, but how much? Do we have to string changes along all around the model, or are there easy ways to limit these additions and changes?

How do we keep the added detail consistent, if we have to change something? I would be inclined to say reference objects… often I use primitives and the like that I can snap vertexes to, to keep things in line. Would it be good to keep a pre-cut copy of the object, that we can add iterations to so that we have vertexes to snap our added detail vertexes to?


It’s not that I don’t find it interesting, far from it, but I just think it’s a slightly different discussion, one that focuses on technology rather than technique (and, as I said, depends heavily on your own interpretation of the term “SubD”). If you take the hard-line intepretation of the term then Max has no SubDs whatsoever, as in the strictest sense SubDs are a property of the renderer. Any step down from that interpretation and the term becomes vague. Is any technique of subdividing a mesh to be considered SubDs, or only those which allow heirarchical editing? Is meshsmooth SubDs at all? What about HSDS (Hierarchical SubDivision Surface)?
You can go on and on, and at the end of tha day none of it is really relevant to any question of workflow or technique, because depsite the differences under the hood and in the renderer the process of actually modelling objects is very similar.

So just to be clear, for the purposes of this thread when I refer to SubDs I am refering to Max’s modelling tools (Meshsmooth or HSDS), whether or not they are SubDs by anyone else’s definition.

Here’s my take on the questions posed so far:

Max’s SubDs are not a “perfect” modelling technique. They are not accurate to very tiny tolerances, and some shapes and forms are just intrinsically difficult to model using the poly+smooth technique.


That really isn’t a problem, because they don’t have to be “perfect”, they only have to be “good enough”, which they are :slight_smile: If super-accuracy is an issue you’d model in a CAD app in Nurbs, not SubDs in Max, and so long as you keep that in mind everything becomes much more simple. It doesn’t matter if there is a flaw in a surface, so long as it is either too small or too mild to notice in the finished render.

Take Fausto’s gun as an example. The question was posed in this thread’s predesessor as to how he managed to avoid pinching in the places where he had a round hole detail on a curved surface. The fact is he didn’t avoid pinching, but it is extremely mild and very small, and as a result it’s not visible in the renders. It is extremely mild because the size of each hole is tiny in relation to the radius of the cylinder, the mesh has only a slight curve if you look at it locally. By “reinforcing” each detail with extra edges to support the subdivided mesh he further minimised any flaws, a technique that was illustrated really well in the old thread by both John and Marcel, if I remember.

The other question directly related to Fausto’s model was that of hanging verts. Again, the answer isn’t that the flaws aren’t there, the answer is that they are too small to see and therefore irrelavant. Again, most of them occur on locally flat areas of mesh (between two edges that are relatively close together in relation to the overall radius of the curve), so they are easy to control. The fact that the gun mesh won’t need to deform in any way makes it possible to pretty much ignore them.

I have a post-it note on my monitor. It says “It doesn’t have to be right, it just has to look right” :slight_smile:

My take on Ngons:
Obviously Quads are ideal, but 5-sided polys aren’t nearly as problematic as most people think. Max’s smoothing algorithm handles them very well, even on deforming meshes, and I’d take a 5-sided poly over a tri or a 6±sided pole any day. I try to keep them away from super-critical areas of a face, such as the area around the mouth or eyes, but most of the time I just leave 'em. They aren’t too difficult to kill if need be anyway.

I actually worry a lot more about poles than quads during the actual modelling process, because a pole automatically terminates an edgeloop which runs off it, and this narrows down my selection options (being a naturally lazy modeller I’d rather hit “L”(sepect edge loop), “+”(increase selection), “V”(convert selection to vertex) in quick succession than manually select 20 or so verts around an eye :slight_smile: ). By trying to avoid poles as much as possible I have to accept Ngons to a certain extent, but I find I end up with much better flow in my mesh once I am finished (and the most important areas, mouth/ eyes etc, are pretty much all quad and no poles).

I don’t approach character modelling any differently from, say, vehicle modelling. They both use the same meshsmooth afterall. There is certainly a difference in priorities though. In character modelling, at a purely technical level, you are much more concerned with deformations and rarely have to worry about hard edges and suchlike. With vehicle modelling on the other hand, surface quality is everything.

These are just my personal opinions of course, and most of them come from learning by my own mistakes or trial and error experimentation.

More to follow later…

(read these if you haven’t already)


BTW great mouth example Zealot.


Iain: Thanks, man. Can you take a second and explain poles? I don’t think many users understand the term. Good one to know.

Gaggle: On the whole macro thing…That’s a really good idea. I’ll look into setting that up.

mrfandiwagon : Great link, man, thanks

Gnarly Cranium: I promise we will get into cutting details in, well, more detail. I’m still not 100% sold on it.

Thanks for the posts everyone, let’s keep 'em coming!




Wow, great info threre Iain.

As far as i’m concerned, Iain’s word is like the bible. He has helped me a coupple of times, usually with one aswer only, and works every time.

I’m happy with those defenitions and will take it as being that.

Can we now move on to some serious modelling techniques? For one i don’t feel that box modelling is the way for me, i’m trying to attempt poly by poly and would love to see what others have to say.


And, Iain, when you putting a site up again. Loved the work you had there.


A pole is a vert with less than or more than 4 sides. We know an edgeloop is a line of edges running through consecutive 4-sided verts, as soon as it hits a pole it is terminated, so from a workflow PoV poles are to be avoided if possible. Once you get to the “tidying up” stage they don’t matter so much.


Verts that have 6 or more edges can cause shading anomilies in Max due to the way they are subdivided, so they should be avoided like the plague. You get a sort of “flower” pattern on the surface that can’t easily be hidden with the material. I’ve actually had this happen on a 5-sided vert before, but it’s rare and I defy anyone to model anything even remotely complex without using any 5-sided verts at all. BTW, this is the reason I always avoid 6-sided polys even on flat-ish areas. When you subdivide a 6-sided poly you get…a 6-sided vert!

Trying to model with no poles is just a slightly different approach to trying to model all-quads and you will most likely end up with the same mesh eventually, but the two are incompatible during modelling. Of course, my approach is only possible because Max’s Epoly object is quite happy with 5-sided polys, you couldn’t work that way in Emesh (or even LighWave).

There are better explanations in that second link I posted if you want to know more, but that’s my take on it.


Sorry Fede, I’m not putting a site back up until I have some more work to put on it, so it may be a while. And don’t take what I say as gospel, try this stuff out for yourself and come to your own conclusions, you’ll learn more that way. Hell, I even use tris now on purpose sometimes because I experimented to see what they did to a mesh and learned to predict them. If I’d just listened to everyone else’s advice I would still be religiously avoiding them.


Thanks for the explination, Iain. :smiley:

In case you have’nt seen this before in the wild,
Here’s an example of a 6+ sided vertex’s shading errors:


Aye that’s the fella. Thanks, my Max was rendering so I couldn’t demonstrate myself :slight_smile:


check this thread for 3DZealot’s primitive as a scripted plugin :


That’s really cool, man.

Works great. I so have to get into scripting more. That’s just awsome.




Iain, i see what you are saying. I think that being very early in my career i’m kind of afraid to mess around instead of trying to get it right first time round.

I hope i can use this thread in this way, if not delete the post.

Here are three situations that i’m not sure off.

is this bad topology or is it fine, and how do i fix it?

Is this also fine or what’s the story?

and finaly

When i chamfer an edge in epoly i get tris, and am not sure how to fix that. If i target weld the tri vertex then i have the two edges next to the chamfered one with some npolys.

any suggestions please.

Thanx guys.


Hey, man, it’s totally fine to post questions like this.

That little quad at the top probably should be removed. Just weld 'em together.

On the second one, you could just divert the middle loop to the vertex underneath it, and then remove the offending middle vertex.

For the last one, if you chamfer an edge, that’s pretty much what you’re stuck with.

Hope that made sense.

EDIT: good call on that last one, guys…Do what they said.




the last one i usually solve using the following method if i absolutely WANT to have quads

that way you eliminate both tris and ngons . . .

problem is that this solution results in poles :sad: