Now that we have a mesh, the next step would be to clean it up. Since my workflow involves a poly modeler, I would do the cleanup there. If you wanted to go straight to ZBrush and then to something like an STL output for manufacture, you’d probably be meshing things very differently. I’d suggest changing the method to Quads and Triangles, turn on Weld vertices, and just crank the slider all the way up. ZBrush won’t have issue with the density and you can sculpt away. My goals aren’t that, so I have to think about how I’m going to make a very efficient item out of this down the line.

Now, much of the work from here is very polygon modeling oriented. It takes skill in that mindset to do all of this, but there is a lot of rather automatic stuff to do. So I’ll cover that, which will also serve as a kind of feature request to Michael. ^_~

The first thing I do is look over the model for specific things: planer caps, T-Junctions, and poly lines on surface edges that are close but not quite on top of each other. Depending upon how messy the surface edges are depends upon when I weld edges. Areas that are good I weld up. Other parts I work out before welding. Sometimes I just go back to MoI and export problem sections again at different settings.



Planer caps are easy; there’s ways in MoI to force them how you want (I’ll get to that later), but if they’re simple, you can do them inside of the poly modeler without much hassle. Delete the faces, and if you have something like the outer part of this, you can just bridge and it works. The inside one is harder to do just right. You can edge slice in the ones you want. Or you can delete the cap, scale in the edge, then collapse the inner verts to a single point. Or you can be lazy like me and use a script that does a poly fan for you.



The next thing I look for is T-junctions and excessive vertexes. T-junctions are especially annoying; at best it’s just extra edges and at worst it causes the bordering polygons to become non-planer. Overall, I find that it’s best just to remove them. Sometimes, though, I’ll actually flow it through the object; those are only when I need the poly flow in another part, though (like linking up two surfaces). Also something to keep a lookout for is verts in the middle of edges that nothing else connects into; these two-edge verts are pointless and need to be removed. I have a script I use for that, but otherwise they’re really hard to spot.



After that, the effort really is down to seeing which edge should flow into another. This is the part that’s pretty much polygon modeling and I’m not going to cover it. Suffice to say that my choice to make this one mesh on output made it tougher to clean up. And the output isn’t perfect, but it subdivides just fine, holds the right shape in all the right place, and can be sculpted without much fuss.

Now, that’s just one object. It has a lot of parts that are common for me in my NURB to polygon workflow. But some more specialized things might be in order to talk about.

First up is trimmed surfaces. Due to the way MoI deals with them, they usually result in odd boundary edges. Especially if the trim is an interior trim. First let’s tackle them on planer surfaces. If you take, say, a round cap and punch holes in it, the default meshing surface looks like utter crap. This is the usual mess of random connection lines you get from Booleans in polygon modelers, actually.



Now, taking the idea from before about using trims to force edges where we want them, we can make something like this regular bolt pattern work fine just by putting a slice right down the middle of each one.



This is one of the few times I’d take a circle down to a square. It will subdivide perfectly round, the geometry is already pretty heavy, and these holes would NEVER be actual geometry on a game model; they’d just be normal and/or alpha mapped on. To clean this up, I needed to just connect some points and add some loops.



I’m holding those edges via edge weights (something I’ve come to love for holding machined edges in sub-d models without increasing the mesh density). Now, the display smoothing may look a bit rough, but it renders as intended, and if I actually physically SDS divide it also looks fine.

Now, doing trims on another curved surface has the same ideas. Add in trims to control things and then tweak the mesh settings. Take this round hole through a cylinder.



To properly mesh this, you have to actually understand a bit about putting holes in subdivision objects. The general idea is to have as few sides as you can get away with and to keep as many quads as possible. For this, the shape maintains fine with the cut circle being only eight sided. But, at that division, the outer cylinder is also at the same eight sides. This causes the object to not have enough edges to maintain shape.



To make this work, there’s two ways. The first is to toy with the “divide larger” option until you have the sides you want. For something this simple, it works. But, if this method fails, the other option is to mesh the two cylinder parts separately and then sew them up in a polygon modeler.



One thing to keep in mind, though, is that at this low of a resolution, there will likely be some warping near the drilled hole; this is just the nature of subdivision surfaces and the only way to get around it is to add more damn edge loops.



The one on the left is the model out of MoI, with edge weighting and a couple edges added. The one on the left is the result of running a Smooth subdivision on it. You could also compensate for the warping by moving the lip of the cut inward, but that creates odd problems too.

One last thing to keep in mind when pushing out meshes is to try to keep the NURBS simple. If you have a model with a ton of surfaces trimming and blending and sweeping into one another, the mesh it will create is likely to be very messy; MoI just isn’t equipped to handle those cases yet.



Take this over the top silly thing. It’s got fillets, weird shapes, and whatnot.



And this is what the mesher makes of it. The top and bottom of the sweep aren’t in sync. Not to mention the fillet at the end is a mess. Really, this item would require a rather large amount of cleanup to make usable. Thus, try to stick to shapes that make predictable meshes. Going over the top like here is likely to end in tears.

And now for a few ideas and suggestions to Michal. As my whole section on cleanup shows, MoI makes good enough meshes, but it makes a lot of the same choices that often aren’t helpful. Maybe adding some mesh cleanup actions that can automate much of what I’m doing now will help speed up my (and others who do things this way) workflow. Nothing can think for me, but some things are just click-click-click actions over and over.

First up, check the mesh for vertexes that only have two edges leaving them. These are useless and need deleting.

Next, check the mesh for T junctions inside surfaces. They often aren’t helping and need removal, but sometimes help when you get to a surface boundary and need another loop to join things up right. Thus for now, just complete the T-junction loop to the edges of the surface; but keep track of which loops that are made this way.

Now check for T-junctions on surface to surface boundaries. Often I’ve seen that they’re close but not close enough. Adding an option to weld these within a certain distance would help. Now take a look at the T-junction loops that were made in the last step but that didn’t weld to anything. They’re probably useless, but might be desirable to keep. A toggle switch between “remove” and “keep” should suffice.

Last is planer surfaces. You mentioned that you were looking at ways to trying to line up the poly edges when a planer-ish surface meets another surface. That would be quite nice. Add to that some actions for planer caps; circular and any regular sided object besides a square have all the edge verts collapse to the center and quads have them go to the other side.

Again, these won’t make bad meshes into good, but will help to make good meshes into very good ones.

Another process came to me while doing thought experiments about better ways to mesh out NURBS into subdivision-friendly polygons. This system is simple in concept but probably costly in backend execution. But I shall present it so that you can see what you will of it.

The goal of this method is to produce as many continuous quads as possible. To do that, the first step is to walk each visible edge (the ones that MoI is showing us), plopping down a vertex where the angle setting, using the divide larger and avoid smaller as upper and lower bounds it tries to honor, says it should put one. Do this for every edge first.

Next, compare the edges of each NURB patch that are parallel (the ones that poly edges will cross to join). Now, to make sure we keep an even count, if the two sides aren’t equal, one will need to be re-interpolated to match the other. A setting could toggle if we should go up or down; although I think that as things become more complex in iterations, some logic would probably help to choose which might be best in certain cases (thus making the option a bias toward a behavior and not strict). Now just walk through the model, evening up the count (very time consuming …)

Next, once each side is equal, check where each vertex lies compared to the underlying UV isoparams. The ratio between two UVs aren’t likely to be the exact same on both sides, thus the resulting poly line will follow a path that interpolates between them. Just run the lines across all the surfaces, letting the crossing lines meet up on the UV surface where they will. You could add some code to try to maintain some uniformity or specific aspect ratio throughout, but beyond the current option this service can be done after the fact in most poly modelers.

Now, of course, this method isn’t perfect. Following the above logic will have it utterly fail once it reaches any sort of interior trim. It can try to get around this by just ignoring the trim at first and meshing the trimmed part as above. Then, if the bias is set to “go lower,” it will mesh the interior part by trying to maintain as many edge points as the geometry above already has (like the usual guide for making holes in sub-d surfaces). If the bias is set to “go higher,” then the hole will cause the surface it’s cut into to be re-interpolated to contain the additional points. Thus doing the cross edge fitting on interior trimmed surfaces first is the best course of action.

Another failure is end cap trims. All of their natural sides are trimmed off, and unless it’s a quad trim (and thus probably should just be a damn quad without a trim), you don’t really have the nice four edges to maintain a good quad setup. In fact, in things like circle caps, you could have a whole mess of other NURBS patches terminating along it. As such, they’d need to be special cased into “known quantities” that can be meshed similarly each time. Circles and ellipses are pretty easy (each point on its edge collapses to the center. In fact, most any regular polygon besides the square can be treated like this and the effect isn’t so bad (although even sided items could be meshed across to the opposite face, but that would create a whole mess of tris). Much anything beyond that, though, is way too complex to automate. Leaving it as it is now in the N-gon mode is probably sufficient.

Now, I don’t claim this to be a silver bullet. It might not even turn out to be practical. But it’s an idea to kick around. Of course, this assumes you have enough access to the meshing system to actually make this sort of thing possible.

Great post Keris and some really useful tips.

Up to now I've just taken the model as is with enough density that modo can render it cleanly. I'll be trying your method of cutting in to control the poly flow on my next models.

Cheers.

Yes, Yes! I really appreciate you taking the time to explain your workflow, Keris.

Being that I require low-poly models for my games, seeing your methods of creating usable models from MoI is very appreciated!


-Will

Hi Keris, wow a lot of information here! I've tried to read through all your messages but you have so much stuff in there that I may have missed a bunch of pieces, sorry... But here is my attempt at a reply:

You wrote:


It doesn't do that because the same settings are not necessarily directly applicable to every kind of model, especially parameters that involve distances like "Divide larger than".

But if you want to, you can make it remember the settings between MoI sessions by editing the following item in the [Mesh Export] section in moi.ini:

[Mesh Export]
PersistSettingsBetweenSessions=n

Edit that to say =y to make the settings persist between sessions, and you can edit the moi.ini file by going to Options > General and push the "Edit .ini file" button there.




"Avoid smaller than" does not 100% eliminate polygon edges below that size, what it does is switch to what is normally a much coarser angle of 35 degrees to refine polygons that are smaller than that size. You may think of it as "Avoid normal density refinement smaller than x", but it is difficult to put such long labels on things in dialogs.

That helps to have a normal rendering density on large features, but have a rougher mesh on small areas but not have the small areas just totally degenerate to a single polygon. That makes a better result for rendering. If something like a Fillet just degenerated to a single polygon that would probably be just a little too rough for most normal rendering purposes but at a rough angle of 35 degrees it tends to give you about 3 polygons on a regular fillet - that looks pretty good if you are zoomed out and rendering the whole object which is the scenario of what "Avoid smaller than" was built to handle.


You can change the value of the rough angle in moi.ini by setting:
[Mesh Export]
AvoidSmallerThanRoughAngle=35

If you increase that to something like 90 degrees it will then generate an even rougher mesh in areas under the "Avoid smaller than" size.


Basically that setting "avoids" meshing the object with the full regular density which is more often something like an angle of 12 or 8 or something and not really such a rough angle like you are using - I have not made it through all your messages quite yet but it seems like you are trying to use the mesh export as a basis for creating a sub-d cage which the mesher is not really designed to do - it's more oriented towards making meshes for rendering and not for use as a sub-d cage which is a much different kind of process to apply to a mesh.

For someone who is producing a rapid prototype output and you want to export to zbrush, you would normally just crank the angle down and use the "Divide larger than" option to finely dice up the polygons, and set Output: Quads & Triangles instead of N-gons and then use that finely diced mesh to go to zbrush instead of attempting to create subdivision surfaces out of it.

For some examples see here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=804.26
http://moi3d.com/forum/index.php?webtag=MOI&msg=2833.5

So note that there is no conversion to sub-d done there at all, just dice things into small sized polygons and use in ZBrush...


EDIT: Ok, after re-reading your messages a few times I see that although your final goal is to go to ZBrush it is not to make an STL output but rather to do some normal maps or something to apply to a low poly game model... So the above details on using MoI with zbrush I guess won't apply to your case. But the MoI mesher is not oriented towards this same goal that you have of producing a sub-d control cage rather than producing a renderable mesh directly. In the future I'd like to try some experiments about that, but it will require a substantially different meshing process, one that tries to build polygons that radiate out from trim edges rather than one that starts with the underlying UV quad grid and then generates N-gons where trim boundaries intersect it like the current mesher is based off of.

That's not at all an easy thing to switch, it will be like writing a completely different mesher that goes through totally different calculations and processes.

It will also be difficult because it will have no connection to the UV parameter space of the surface, and the most natural NURBS algorithms are ones that use the UV space of the surface as part of its calculation.



re: Planar caps that have a radial polygon arrangement - for those you would want to have some kind of revolved planar piece so that the UV layout was like a surface of revolution with a pole in it, that will then generate a UV space that has the kind of cap like you want. MoI usually replaces flat disc like surfaces of revolution with trimmed planes instead so you may need to do some tricks to produce one, like do a revolve on a slightly curved thing and then flatten down.


But yeah the overall goal you have of producing a sub-d cage is just not what the MoI mesher is designed to do, that's why you have a lot of tips and requests about it - it is just not oriented towards your specific goal, it's more oriented towards producing output that will be rendered directly and not as input to a sub-d smoothing process.

It really needs a much different process to make a proper mesh for that goal, its not really something that would be produced by a few tweaks on the existing one, it needs to be very quad oriented and not n-gon oriented like the current one. Also it is likely that it would not be possible to just unilaterally change the mesher to produce that kind of an output because then there are places where it would actually be worse for generating clean renderable output like it currently does.


But I appreciate that you are able to wrangle some good mesh results out of MoI for sub-d anyway despite using it for a process that it was not really designed to handle.

Some of the functions that are oriented towards generating just nice general mesh structures (like trying to do more uniform and evenly spaced polygon distribution) tend to help give you something you can at least work with instead of just a big mess...

But the fundamental approach of the UV-oriented n-gon generation is just not really the overall correct thing for what you need.

It's just a really different problem to solve - MoI's current mesher is just more for generating a clean result for rendering with avoid excess polygon count. For a sub-d mesher you actually need a higher polygon count in many spaces than the current mesher, for example just on the cap of something like this:


The current MoI mesher will generate a single planar n-gon on the top there, which is the correct result for trying to get a clean render mesh.

But for use as a sub-d cage it is not good at all - you would want that top piece to be tiled with a bunch of quads that radiate out from the edges and try to have some good organization where they then collide into each other. That would mean generating actually a lot more polygons for that case than the current mesher does, and in a much different way than the current mesher does.

That doesn't mean the current mesher is not good at what it does - it just is oriented towards a different purpose...

- Michael

>> In the future I'd like to try some experiments about that, but it will require a substantially different meshing process,
>> one that tries to build polygons that radiate out from trim edges rather than one that starts with the underlying UV
>> quad grid and then generates N-gons where trim boundaries intersect it like the current mesher is based off of.

>> That's not at all an easy thing to switch, it will be like writing a completely different mesher that goes through
>> totally different calculations and processes.

If you can get this working so that there are two output meshers in MoI, one for optimized mesh and one for further development in a sub-d modeler, I would be a very happy person. Such a lot of things are soooo much easier in MoI, but turning them into a sub-d suitable mesh is not so easy so kind of negates the benefits.

I'm sure there are many others who would also think the same :-)

Hi Tony, yup I'm sure it could be useful to have an alternate "sub-d oriented" mesher.

But unfortunately developing a new meshing engine from scratch is an extremely time consuming piece of work. For example it took me about 8 months of full time work to achieve the current one in MoI.

Developing a sub-d friendly export would require a very different approach from the current mesher. There would not really be much in common between them.

So it is difficult to figure out how I would come up with such a huge block of time that would be required to work on it...


> Such a lot of things are soooo much easier in MoI, but turning
> them into a sub-d suitable mesh is not so easy so kind of negates
> the benefits.

"negates the benefits" ? No, that's not correct at all for the more typical use where you are exporting meshes from MoI with the intent to render them.

Why are you trying to turn them into a sub-d suitable mesh? Is that what you did with your Brain Amplifer project? I was under the impression that you exported it into Modo to render it in Modo.... That's the much more "mainstream" and normal method for MoI exports - to render them, not to sub-d them. The current mesher is very good at producing renderable meshes, it's what it is designed to do.

Why would you convert stuff like your control panel machinery models into sub-d shapes? I don't understand why you would not just render the mesh that you got from MoI. That requires 0 extra steps and no negating of the benefits of NURBS modeling whatsoever...


Normally if you want to create a sub-d friendly mesh you will need to create the entire mesh in a sub-d program that has a sub-d specific workflow and UI.

When you apply sub-d smoothing to a mesh, it alters the shape, the subdivided result is kind of melted down from the original control hull. So it is a bit of a strange workflow to build your object out of smooth NURBS surfaces, but then intend to take that result, dice it into rough polygons (pretty big shift from NURBS at this point), then take it somewhere else and smooth it again in a different way to morph the shape some more... Of course it could be useful but it is a rather weird sequence of stuff to apply to your geometry.

To get the best results with sub-d you really need to have some specific kinds of topology layout to it and it tends to work best to guide that topology by hand, not by an automatic process. Of course, that's a big reason why sub-d modeling actually takes quite a bit of time and experience to become proficient in.

- Michael

You need some kind of artificial intelligence inside the mesher if you hope to build SDS ready cage.
You can allready discuss hours about 'what would be the best polyflow' for some simple objetcs, what about a complete car for example ?

Maybe the solution will come from this 'auto-quad mesh' tools like you can find in 3dcoat ...

Acutally if I need to convert a MoI objet into an sds one, I just rebuilt the topology with tools like topogun. It would be faster and more "accurate" than trying to clean MoI export. Just import you 10M poly mesh and think topology ... it's the same workflow when you model stuff in zbrush and retopo your stuff later.

Hi Michael,

You are right, I didn't do any of the brain amplifier stuff in sub-d. All straight MoI export (well nearly all)

What I have found is that manipulating objects is much better in MoI than any other app I have. By that I mean aligning, rotating, etc. You have made every other app look clumsy by comparison :-)

Because of this I like to work out my ideas using MoI. So If I was aiming for sub-d then being able to get closer to a sub-d version straight out of MoI would have been really nice. I guess that sometimes I'm not using MoI in the typical manner ;-)

However, 8 months is a lot of time out of the main development just for another mesher. I can see that this is not really viable.

No worries, MoI is really great as it is and I am looking forward to the next version.

Hi Paq,

Yes, re-topo is probably the best way for me to go if I want this kind of workflow. Need to learn more about that.

Hi PaQ , yup a retopologizing tool would be much more "the right tool for the job" for converting into a sub-d friendly mesh.

TopoGun only costs $100.

I mean I can understand that people think it would be cool if MoI could just magically pop out a sub-d friendly all quad topology the same as what would be guided by someone's judgement... but the feasibility factor is rather low on that.

- Michael

Hi Tony,

> I guess that sometimes I'm not using MoI in the
> typical manner ;-)

Well, you actually were for your Brain Amplifier project...

Do you have an example of a project that you did in MoI but that you intend to have as sub-d as the final result?

I can understand that you like the feel and way that MoI manipulates things, I mean I put a lot of effort into the overall UI of MoI to make it more fluid and fun to use...

But that still doesn't mean that it is the right tool for every single kind of job.

Say for example you have a really nice screwdriver that fits your grip perfectly and never slips... That still doesn't mean it is the right tool for the job if you currently need to pound in some nails instead.

- Michael

Hi Michael

>> Do you have an example of a project that you did in MoI but that you intend to have as sub-d as the final result?

No I don't have a specific project, just playing around with MoI and modo to see how much crossover there is.

>> I can understand that you like the feel and way that MoI manipulates things, I mean I put a lot of effort
>> into the overall UI of MoI to make it more fluid and fun to use...

And a d*mn fine job you did sir!

>> Say for example you have a really nice screwdriver that fits your grip perfectly and never slips... That
>> still doesn't mean it is the right tool for the job if you currently need to pound in some nails instead.

Yes, I definitely agree. Use the right tool for the job. But in software you can sometimes find uses for tools that the designer never really intended. I'm really just experimenting and your reply to Keris...

"In the future I'd like to try some experiments about that, but it will require a substantially different meshing process, one that tries to build polygons that radiate out from trim edges rather than one that starts with the underlying UV quad grid and then generates N-gons where trim boundaries intersect it like the current mesher is based off of."

...got me thinking how great it would be.

Not asking for it to be done - just saying it would be cool if it was :-)

"...I can understand that people think it would be cool if MoI could just magically pop out a sub-d friendly all quad topology the same as what would be guided by someone's judgement... but the feasibility factor is rather low on that..."

An all-quad mesh is not the only complex factor involved here. Subdividing a mesh will also modify it's volume in different ways depending on the surface shape in that region. For example convex areas which shrink, concave areas will expand, and planar areas will remain roughly at their respective elevations. This would also need to be accounted for for a true subd-ready mesh...

Also going back to the suggestions by the original poster. That is a trick known to many Rhino users to force tightness in problem areas when generating a mesh. It's still a good technique to get finer control over your exports, but I think in most cases not needed when exporting from MoI. The only time i think it's needed is when you wish to get a better sense of symmetry in the mesh...

jonah

Good thread. Lots here for nurb newbs like me.

Thanks for the time and effort, Keris.

Leonard

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