It’s a bit odd, really, but I’ve found that there really isn’t much good information about using NURBS in the polygon-dominated entertainment industry. Now, if all you want is to get really high density polygon meshes to an STL printer, life is easy; every program that can render NURBS can convert them to highly tessellated polygons for you. But if you want to actually create, say, a lightweight subdivision surface cage, the options are slim. Maya can convert, but its methods are far more geared toward converting untrimmed surfaces into its own multi-resolution subdivision surface format. If you want to do trimmed surfaces, I honestly think MoI is the only program that makes it doable without spending ages in cleanup. So, through trial and error and some rather old info from the early Maya years, I’ve pieced together the shaky bits of a system. I will share that here to both help others along, elicit comments and suggestions, and maybe to prod some features out of Michael if I’m lucky. ;)

I’m going to make a wild ass guess that if you’re reading this, you at least have some passing familiarity with NURBS and polygon modeling. And hopefully you understand something about Catmul-Clarke style subdivision surfaces as well, since my method is optimized to achieving polygon meshes that subdivide in a way that mimics the original NURBS objects. I’ll try not to go really basic, but won’t assume master level knowledge either. I’ll try to explain my “whys” as thoroughly as possible, but I might skip over something that is important; in that case, call me on it.

For an overview, I’ll be using this rather simple valve wheel I put together from concept to final build in literally about 10 minutes (I love that power of NURBS). The process was really just simple extrudes for the middle cylinder, a path sweep for the ring of the handle, a loft for the arms, and just Boolean unioning everything together with some fillets at the junctions. All simple operations in NURBS that would take me far longer planning proper poly flow to merge up if I did it in polygons.



The final goal of this thing was to be imported into ZBrush for creating surface detailing, then to make a low-poly game version to cast the details onto. All that process is not what I’m going to talk about, but what I did to get it there IS.

The main goal I had was to get a good quad poly flow out of it. Gleaning from the various posts I’ve read, the mesher in MoI works by getting an angle to split the edges on and then following the UV isoparams. As such, the density and quality of the surfaces are very important. But another concern is trims. I’ll explain more later, but for now let’s just toss the item as-is into the mesh output process.



This is the default settings that come up (for me) every time I restart MoI (I wish it would save the last used mesher settings between sessions). It’s in N-gons, with splitting at 12 degrees, and “Weld vertices along edges” off. N-gons output is the best for this kind of work because it keeps MoI from tessellating inconsistent edges into triangles (which are a pain to clean up). I also turn off the weld operation because it usually causes more pain in cleanup than help.

Now, these settings really are way too much for my goal. The mesh is far too dense. While I could just take this and then remove edges, MoI lets me do much more tweaking to get closer to my needs.



Now, with some toying around, we can get this mesh. It’s lighter, which will be a great help in cleanup. The “divide larger” is there to keep some polygon density on things like those arms, as well as adding more divisions on the outer ring to keep a good silhouette. The” avoid smaller,” going by its name, would allow you this it demolishes those small fillets, but it doesn’t; instead it often doesn’t do anything at all at this large of an angle. I’ve never found much use in the aspect ratio; for me, it often just adds far more density to the mesh than I want, while also introducing annoying T-junctions.

Now, while the last mesh was serviceable, there are some points to note about it. For one, if you were playing along at home, you’d notice that dialing around that angle would cause the way the round handle gets divided up to become strangely shaped.




Not only does the wheel look a bit strange, the odd divisions wreak havoc upon the way the arms flow into them. To avoid this kind of mess, we need to trim the mesh so that we can force edges where we want them.

This trimming process actually requires some forethought about where to put them and how dense you want the final polygon mesh to be. For now, I’m just going to hit the high points and go into more special cases in a bit.

The general rule of thumb I go by is “don’t have anything large than a 90 degree turn about the object.” That might sound complicated, but it just means that, even if it’s a smooth cylinder, I’ll divide it into at least four sections. This works in both the directions across a complex surface.

The reason for this really comes down to the way people see things. The human brain likes pairs, triplets, and quarters. It loves these simple sets because they’re fast to process. Multiples of them are also good because the brain can divide them out decently well. Fives are good only in the case that you’re using them as part of a decimal counting system, like having five items. Things divided into fifths are harder to parse. Unless you have other, more visually appealing items. Also, for large objects, at just about any time, one can always see a quarter of the object, thus nailing down the edges helps to control the way the form is seen.
So, to divide up this model, I look it over. It has four arms, so the outer wheel will be divided into four parts at the midpoint of the arms. Had the wheel had five arms, I’d divide it into five parts with the center at the arms because the arms dictate the way the eye sees the object more than the total sides. Each arm, the wheel, and the center will get divided into four parts around the object.



I can accomplish all of this with just three lines and a circle (hard to see there …). Draw the lines out over the parts, then just make sure you move them away from the object. Next, take the wheel solid and Separate it into surfaces. Now just Boolean Difference them. If things don’t work as you expect, you might need to extrude them without caps to Boolean right. It might not Join up into a Solid anymore, so you should only do this once you’re ready to output, and probably only to a copy of the object and not the original.



With the exact same settings as before, we now have a mesh with far more predictable points of flow. Now, the arms have a crapton more edges, but those aren’t too tough to remove later (sadly, “avoid smaller than” doesn’t seem to affect them at all).

At this point, I can now actually think about baking in the number of edges I want. This kind of goes into the thought about how many edges you need to properly show a round object. My thoughts are you need to think in multiples of four. The larger the object, the more you need. For this wheel, the center I want to have at least eight in the low poly, while the outer wheel needs at least twelve. I personally think six sides looks off, and going to a low odd number also looks weird. And four just isn’t enough for something you can see the end of, no matter how far you turn the smoothing angles up to.

With those thoughts in mind, I actually decided to export out an object with twice that much density. The reason was that, based upon the way the mesh looks at those settings in the MoI mesher, there was just too much distortion where the arms meet up on both sides.



By doubling the amount of sides (and a lot of toying around with settings), it looks far better.



Now, this is where I mention the next important trick. If you end up in this kind of situation where you want some parts to be at one amount of an angle and others to be at a different one, the best method is to export the various parts separately with their own settings. It’s faster, ends up with less odd things (like those T-junctions on the outer ring). I’m not doing that here because it’s harder to illustrate the whole object without composting images together.

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