Agreed, and I'd have no problem Michael, paying for an additional mesher along these lines if you were to come out with one.

Of course for me, I currently use retopo when I need to get quad optimized MoI objects into my poly apps.


-Will

Well, seems I've caused a bit of a stir here. And, looking back on it, I guess I really didn't explain myself; what I did is there, but not really the why I came to do it this way.

As both PaQ and Michael have mentioned, the best way to get a SDS mesh from a NURBS object is with human judgment via retopology. There's really no magic way to get the "right" mesh when you deal with trimmed NURBS surfaces. Now, if you only have fully non-trimmed surfaces, then you actually CAN get an SDS surface from it without much fuss at all; the CVs of a NURBS surface act the same way as the control points on an SDS cage (they both follow b-spline smoothing), provided all the surfaces that you want to connect together are at least G1 in their continuity. This is actually what Maya's NURBS to Subdivision conversion aims at; it will untrim everything before conversion too, since it just doesn't want to deal with the mess of trying to figure out what to do with the topology around them.

Before now, I would do things the way PaQ describes them (import the high resolution object and retopologize on top of it), only I'd do it in a poly modeler instead of something like Topgun (mainly because I haven't looked at such tools yet). There's actually a rather good tutorial for using the tools in Modo for this very purpose here. However, this really just felt tiring. Now, from watching videos of Topgun and 3D Coat, they do retopology in a way that's faster, but I'd still have to do the whole thing.

So, one day I'm looking at the mesh output of MoI when I turn the angle way up. And by golly, it looked rather nice! Not perfect by any means, but it put the edges in the right place to hold a curve and didn't muck up the model with a ton of triangles. So I went down the path that led to my current method of trimming the mesh to control the points where I want edge loops and exporting problem parts separately if that helped. For most of my hard surface modeling needs, this actually did a damn large chunk of my retopology for me; I just needed to clean up the flow from some surfaces into others, and maybe normally retopo some more annoying parts. I also, if it looks like I need to, import a high res version and use Modo's Constrain to Background feature to rework the lower poly onto the higher one (for times where the SDS shrinks it too much or I need to retopologize a decently curved section from scratch).

The whole point of this method is, really, to just save me some time. I know it's a rather sick and twisted thought process of taking the sexy-smooth NURBS surfaces and faceting them up only to smooth them again, but if I could just plug these NURBS models straight into a game, I would! It's just an odd method of work that I've found works well for me. Now, if all I wanted to do was a high poly render, I'd just forgo all this mess, export a high poly from MoI to ZBrush on and then just take that back into Modo (or Maya or whatever) for rendering. For animation destined for render-only, I'd still kick out a low-poly version for proxy, but I'd not care much about it being SDS ready; keep the animation proxy light and looking something like the final object and just swapping in the high-res version for render.

Hi jonah,


Yeah and where these areas collide into one another that kind of shape alteration will probably tend to bring some kinds of bunching or pinching into the sub-d result, probably generating some little lumps and undulations that were not in the original NURBS model.

It will be hard to maintain the surface quality integrity of the original NURBS model with this kind of a process since it is just being discarded and not even the original normals have any influence on the sub-d generated result. That's a big difference from render mesh generation where the normals from the NURBS surface do get used in the rendering which helps greatly to make the rendered result match the original surfaces.

- Michael

Why thank you Michael! I had no clue those options were hiding out there in the INI file (probably should have looked, but just wasn't nosy enough this time). As for the explanations of exactly what those options are doing, that really makes sense. I had noticed a "floor," shall we say, of where "avoid smaller" seemed to do much; now I know why!

As for my contorting of the mesher, I'm fully aware that it isn't built with this kind of thought process in mind. As I noted in my opening post, this kind of workflow just doesn't seem to be too "popular" (if that's even something you could use to describe it). I do think that some of my thoughts on tweaks from this post might be of some use; not magic bullets, but just some generalized cleanup. I can continue to use scripts in Modo to do some of it, but MoI could use the fact it has the real surface info to make those T-junction loops of "close but not quite" welds lie on the surface where they should.

But, yes, to make a mesher perform more for this kind of mindset would require a totally new mesher. That's more or less what this post was talking about; that is really just a thought experiment more than anything. (And please don't take offense to me referring back to my posts; I really DID post up a giant wall of text.)

The MoI mesher is GREAT at what it is intended to do. Leagues better than any other I've used. Which I think is why I found I could bend it to my needs so well. ^_^ If you ever write a mesher that takes this kind of mindset into account, I'd love that. But, even so, the current model scratches my itch with pretty good deft, so I'm already quite happy.

Hi Keris, yeah I know that looking at the nice clean n-gon wireframes starts to make the gears go in sub-d modelers heads about how they could leverage those meshes for sub-d work.

But it's really a pretty big mis-match... The best example I have to demonstrate it is this simple model here:



Generating a n-gon oriented mesh creates just a single n-gon on the top cap there, which is the correct result to get a minimal number of polygons and a wireframe that follows the original NURBS object structure. It's a very clean result, and perfect for rendering (and potentially non-subd direct polygon editing).

But it's totally not the right result for what you want - you would instead want to have the top broken up into something like a hundred little quads that radiated inwards from the edges. That's not like a minor tweak from the current result, it is a radically different result that is needed.

You're going to run into stuff like this all the time unless you greatly restrict the kinds of shapes that you actually attempt to model in MoI.


> I do think that some of my thoughts on tweaks from
> this post might be of some use;

Well, the problem is that probably some of them would come at a detriment to other situations.

For example:


Here's an example of a NURBS trimmed plane created by drawing some curves and using the Planar command in MoI:



When saving to an n-gon mesh, the mesh result will be like this:




So notice here that every single vertex in this mesh only has two edges leaving from it, so according to what you wrote they should all be deleted and nothing should remain of this polygon?

The problem is that you're not really looking at the entire picture of what the mesher has to do, some of the things that would help for your particular goals are not able to be applied in general because they don't work universally.

One thing that sub-d modelers object to is adaptive subdivision - that's where the mesher changes levels of detail to put some more polygons in an area of a surface that has more curvature.

For example here:


There was a change in refinement level there at the red dot because the surface was going from a flat-ish area to a more curved area. When that happens there will be n-gons generated at the transition points.

It's not generally feasible to not have any adaptive refinement at all, because that would force surfaces that have curvature localized into a small area to get an extremely heavy mesh generated in their flat regions. For example a shape like this:


Trying to do that with no adaptive subdivision at all you have 2 choices - either you get a too dense mesh through the whole thing, or you get too sparse of a mesh through the whole thing and the small feature is not present at all.

So I understand that you don't build things like this, but it is the mesher's job to handle all kinds of situations like this without just blowing up...

- Michael

I guess I'm just being a moron in trying to explain my thoughts here. Sorry Michael if I'm sounding like an idiot on repeat. ^_^;



Yes, such a shape would be impossible to output in this way. And I'd just not try to force it. My goal, really, is to leverage the mesh when and where I can, and in other places just output it looking good and deal with it another way (be that doing traditional retopology work or just baking the complex item onto another via a normal or displacement map). It's really a specialized thing for when and where I think I can cheat the system.



According to the letter of what I wrote, yes. But that actually wasn't my intention when writing it; I should have qualified that to mean "vetexes that only have two edges connected to them that are on the interior of a surface and not on the edge." Like a vertex just jutting up in the middle of a surface but not actually having it connected enough to keep the polygons from being shaped oddly. Really, after reading the rest of your message, I'm thinking that when these show up for me is when the adaptive subdivision would kick in, but I've made the settings such a coarse outliner case that it breaks what would have been an edge into just a lonely vertex. Really, it's more my fault for abusing the system in such a way.

I also actually created such a surface (with a complex N-gon edge) for use in creating a specific pattern of displacement on an object. I just exported it at a pretty high resolution and then just used ZBrush to project it onto the simpler SDS object. Worked out very well!



This is really so very true; we don't like it when this happens uncontrolled in the mesh (because it totally throws the smoothing off). I do fully understand why you would want it in MoI's primary meshing function (making renderable items). Just maybe a way to toggle it off for idiots like me.

So, yes, you're right in that MoI works as it should to achieve its intended goals. I'm fully aware I'm breaking the system in ways that are not intended or supported. And I've also been too presumptuous about my ideas on "improvements" to help this method. Again, sorry if I've sounded like I just don't "get it." I know you're trying to tell me (and everyone else) not to get their hopes set too high; and I also know I'm probably broaching on "but Daddy, why not?!" territory. I think I just grabbed onto an interesting (to me at least) thread and just didn't let go. I also didn't fully think through all the ramifications about trying to tweak MoI into working like this in any way other than a happy accident.

Hi Keris,


The problem is that you're going to easily end up with similar situations as that once you combine just a few more pieces together or have even a moderately complex object instead of a very simple one.

Even the example I posted was pretty simple...


Yes, well that's the problem that it is such a specialized thing that you are asking about, it would only apply to certain kinds of models, and for a special purpose target... That's a lot of specializations.

It can be detrimental to the wider body of normal users to have an important interface that they need to use to be clogged up with a whole bunch of controls that only apply to very specialized circumstances.

Every control that is added to the UI makes it more complex to use, and changing the behavior so that other situations will not work as well (like not having adaptive subdivision at all for example) is also detrimental for cases like I posted previously.

So when weighing things, it is hard to justify making an attempt to jury rig the mechanism with bailing wire, duct tape, and chewing gum to try and make it do something that it was not intended for.... I mean that could be possible if there were not detrimental side effects but there are.


You're probably going to have to post an example (if you had one previously in this thread, it's just too long for me to sort through sorry!) to explain more about what this means then.

You shouldn't normally have something that has only 2 edges connected to it internal to a surface and not at an edge. It can happen at an edge because edges can be curved differently from the surface they are on, like in the previous post I showed a plane that had a wiggly trim on it - that's the kind of situation where you can get further subdivision along an edge only which is I think the only place where you get only 2 edges connected to a vertex.

When internal subdivision happens you should get at least 3 edges going out from it, like this:



I guess the other kind of subdivision that you mentioned previously is when holes are split - but I don't know how to avoid that because most polygon formats do not support polygons with holes internal to them. It would be cool if it could analyze the holes with artificial intelligence and determine the absolute best pattern for splitting it, but it is difficult to program human intelligence and judgment into computer code.



But are you sure that these are not happening at an edge though?

If it actually was internal to the surface and not along an edge then that could possibly be something I could actually improve...

If you have an example image of this particular case, please post it so I can understand it better.

If it is happening at an edge, maybe I could still do something about it by trying to avoid edge refinement by some amount in the case of a coarse angle being used.


Re: Toggle off adaptive refinement - I've thought some about doing that, but it also opens up some difficulty... Like I mentioned previously there are actually 2 choices - should it extend refinement throughout a surface so that the whole surface becomes more finely subdivided? Or should it avoid refinement in which case small details like that little bump in the middle of a broad flat surface may be eliminated? Also avoiding refinement would have a major side effect of kind of partially disabling all the other parameter values. For example generally there is a starting base mesh which is then refined adaptively to ensure that all places on it match the tolerances that you asked for. Without the refinement your result will not fully match the tolerance values that you specified. It is rather difficult to portray this kind of semi-disabling of the tolerance values in the UI.

- Michael