I've just purchased MoI after researching the field a bit, and I just wanted to say what an awesome piece of software it is (thank you Michael)!

Whenever I purchase new software, I always look for reviews as well as try to do some hands-on testing myself. So part of my reason for writing this post is both to give Michael a nice pat on the back and also hopefully to provide some google-grist for other people looking for package reviews.

In this case, the packages I was looking at were: MoI, Bonzai 3D, Rhino and ViaCAD 2D/3D (which I actually already own). My experience is mostly with 3D apps like modo, XSI, LightWave, etc., but I was interested in adding some of the capabilities that a NURBS-based modeler brings to the table. Now this is not meant to be a detailed review of each app, but at the end of the day I decided that MoI was the one to buy (and use). My top reasons for making this choice were:

1) The mesher (I love it! It absolutely blows away everything else out there. I love the clean meshes it creates, and the fact that you can see the mesh and dial the polys up or down and tweak the slicing and dicing before committing, even though 90% of the time the defaults are perfect).

2) The simplicity and ease of use (I think the "tablet" orientation pays off for mouse users as well. Nice non-cluttered interface, simple work-flow, "smart" tools, fun to use).

3) Good price (Lots of bag for the buck).

4) Good tool set (Most of the other packages have more extensive tool sets, but MoI gives you about 80% of the function with a much smaller set of well thought out tools).

5) Michael Gibson (An experienced, motivated developer who listens to his customers...priceless).

Now, this is not to say that MoI is perfect. In fact, I really liked Bonzai 3D a lot, but it's mesher currently knocks it out of the competition for non-CAD work (produces ugly geometry with lots of flipped polys and other problems).

The other "intangible" thing about MoI is that it is just a lot of fun to use. I spent hours and hours yesterday creating all kinds of "doodles", exporting them into modo (not a single glitch) and rendering them out. I finally forced myself to go to bed at 4:00 AM. Too much fun isn't good for you :-)

Anyway, enough preaching to the choir here. Like I said, I'm hoping this will turn out to be of some use to people googling for comparative information about some of the different NURBS-modelers out there. Now, back to having fun with MoI...

Dave Morrill

Thats only 5!!!

6: The customizable UI has some very interesting possibilities. MoI wont be left out of the future!

7) the mesher not only create nice meshes, the mesher is incredible fast and allow to mesh complex files within a short time. (it create meshes from models that let Rhino 4 crash after more than an hour of mesh calculation) The multicore support it great!

Hi Dave, thanks very much for your order! I'm really glad that you are enjoying using MoI. Don't forget to get some sleep though... ;)

Yeah, getting nice meshing results is a really critical thing for a lot of people.

When I started MoI, I knew that there were quite a lot of people who use rendering/polygon tools that had previously tried NURBS modeling but bailed out exactly because they could not get good mesh results, and they needed to work with mesh data for their final use of the model.

It tends to be very frustrating to have your object destroyed at the final step! It can really nullify many of the useful parts of NURBS modeling.

That's one of the reasons why it was not unusual that people in the polygon modeling world were saying "NURBS are dead" for a while there.


Because it is such a major problem, I really wanted to make it a high priority in MoI to deal with this area in a much better way. So far I think I've invested about 8 months of full time work just on this area of producing better meshes. It's been a huge investment (by far the most time spent on any 1 single feature aside from possibly overall UI design), but I think it has been well worth it since it helps to make MoI fit in so much better when working with other applications.


Also in MoI version 2.0 mesh export has been tuned up substantially for speed improvement as well, and it now takes advantage of multiple CPU cores. This really helps to make it even more convenient.


> The other "intangible" thing about MoI is that it is just a
> lot of fun to use. I spent hours and hours yesterday creating
> all kinds of "doodles", exporting them into modo (not a single
> glitch) and rendering them out.

Yeah, it is hard to quantify this precisely but it is basically the result of numerous little workflow tune-ups, trying to make things be more fluid rather than getting in your way. Fewer irritations ends up helping to make things more fun.

It's really been a major goal to try and make simple things happen in this kind of fluid way so that you can make stuff happen quickly.

I'm happy that you're picking up on this part, that is encouraging for me! :)

Thanks very much for the feedback,

- Michael

> It tends to be very frustrating to have your object destroyed at the final step! It can really nullify many of the useful parts of NURBS modeling.

> That's one of the reasons why it was not unusual that people in the polygon modeling world were saying "NURBS are dead" for a while there.

Definitely. Like I said in my post, I think Bonzai 3D is a really nice app as well, but drops the ball completely on that last step, making it completely unusable (at least for users like me). I left a note complaining about that fact on their public forum. I even suggested that they try and license your mesher code from you :-)

> Also in MoI version 2.0 mesh export has been tuned up substantially for speed improvement as well, and it now takes advantage of multiple CPU cores. This really helps to make it even more convenient.

Yes, I just installed the June beta today, but it wasn't until I read your statement just now that I realized how the meshing delay had disappeared (on my Quad 4 3.0 GHz Mac Pro running Vista 64). I guess you only notice the things that hurt, not the ones that have stopped hurting :-) Nice job!

> Thanks very much for the feedback,

Sure, you're welcome. I hope to provide more. In fact, now that you mention it...

The only problem I've had with the mesher so far has been in a couple of cases where, with "ngons" turned on, its created an ngon that modo doesn't handle correctly. It seems to have something to do with non-convex ngons, but I'm not completely sure what is causing modo to hiccup. The symptom in modo is usually a missing face where the ngon should be, and some kind of weird poly which is probably what modo thinks the ngon is. Usually the easiest fix is just to remesh it with "ngon" turned off. But since this tends to create lots of "ugly" triangles both on that face, and others in the model, I was wondering if it would be possible to provide some kind of additional option to only output convex ngons, and then drop back to quads and tris for the non-convex ones (or something like that). That way I could still get ngons for some faces. Of course this is probably a useless idea since a lot of ngons come up when you cut holes into flat faces, and those will never be convex. There's probably an algorithm for reducing a non-convex ngon into the smallest spanning set of convex ngons. Or maybe it would be easier to just get Luxology to fix the "bug" in modo :-) But given that they just released modo 401, it will probably be two years before the fix would be available.

Anyway, it's not a big problem since it has a trivial work-around.

Another thing that might be useful for MoI noobs like me would be some kind of message display which explains why an operation can't be performed. More than a couple of times I've set up an operation, then clicked the final "Done" button...and nothing (seems to) happens. Obviously I've violated some essential geometry constraint, but often I don't know what that is (especially since you make so many things "just work" that don't seem like they necessarily ought to :-) ). A message saying what is wrong would probably go a long way toward helping with those problems. Right now I usually back up and try again a couple of times to make sure I did what I thought I was trying to do. Then, if it still doesn't seem to do anything, I shrug and try something else. Of course, this can create a certain amount of "negative reinforcement", since it might lead a user to conclude that some operations are "buggy" or don't work the way they ought to, when in fact it's probably just some simple step the user omitted (e.g. like joining two open curves before doing some other operation that wants a closed curve).

This is probably not new news to you, but would probably be very useful I think.

Anyway, thanks for listening...

Dave Morrill

Post an example (in 3dm format zipped) of your Ngon object who don't work with Modo
That will be a big help for Michael!

The 2d engine is incredibly efficient!

Hi Dave,

> The only problem I've had with the mesher so far has been
> in a couple of cases where, with "ngons" turned on, its created
> an ngon that modo doesn't handle correctly.

Yeah, I've seen some occasional cases where Modo's n-gon triangulator has problems generating its own triangulation from an n-gon, particularly if it is a complex n-gon which has numerous 90 degree corners in it. Probably if you try to manually trace such n-gons with a new polygon in Modo, you'll see that it is a Modo bug where that shape is just not handled right.

Until MoI was around, there basically was not really any way to easily get an enormous number of complex n-gons generated, so some programs still have some lingering bugs in this area which hopefully will get tuned up over time as they get more bug reports and examples sent to them of failure cases.

But generally Modo is pretty good in this area, its n-gon triangulation failures tend to be pretty rare, and small in number.

If you can isolate it down to a small example, it would probably be good to send it to luxology so they could do something to fix it up.


> Of course this is probably a useless idea since a lot of ngons
> come up when you cut holes into flat faces, and those will
> never be convex.

Yeah basically after you have done a few booleans it will be pretty normal for there to be quite a large number of non-convex n-gons.

One other thing you might try when you run into this (which should hopefully be only an occasionally seen thing rather than the norm) is to use the "Divide larger than" parameter in MoI to dice polygons up and alter their structure. If you enter in a distance for "Divide larger than", any polygons larger than that size will be diced down, which tends to also cut complex n-gons into less complex n-gons.


> Another thing that might be useful for MoI noobs like me would
> be some kind of message display which explains why an operation
> can't be performed.

Yeah, I would like to have this in the future... It's unfortunately not always so easy for me to get this information, often times the operation that failed is some low level thing way deep down in one of the geometry library's algorithms and it is not easy to try and record the specific problem all the way from the "top level view" from the code...

- Michael

8: You can write your own "CUSTOM COMMAND". (I guess is more script existing commands), and MG conjours things together when appropriate.

Hi Dave, also re: n-gons into Modo.

From a different post you mentioned that you were using .obj format to go into Modo?

I'd recommend using .lwo format instead - that will likely eliminate the problems you are currently seeing.

Modo's OBJ importer has some issues with n-gons specific to the OBJ importer itself.

If you use LWO format to go from MoI into Modo, you will avoid those problems that are specific to the OBJ importer and you should see better results with big n-gons especially.

You still can occasionally get an n-gon that Modo's core n-gon handler does not like (which is what I was referring to previously), but that is pretty rare.

Sorry I didn't mention this earlier, I just assumed you were using LWO format.

There are some other details about this problem with Modo's OBJ importer on the Modo forum here:
http://forums.luxology.com/discussion/topic.aspx?id=34774&page=1

- Michael

> But generally Modo is pretty good in this area, its n-gon triangulation failures tend to be pretty rare, and small in number.

> If you can isolate it down to a small example, it would probably be good to send it to luxology so they could do something to fix it up.

Well, after reading Frenchy Pilou's suggestion, I decided to try a create a simple failure case to send you. The good news is that everything I tried worked fine (sort of). So it is not what I thought it was (simple non-convexity). The "sort-of" qualifier refers to the fact that I could consistently create cases where the ngons were there, but in some kind of a strange "flipped" state. I say "strange" because selecting the bad ngon and flipping it did not fix the problem. But if you flipped it a second time, then everything was OK. That's not such a horrible problem, because it only takes a couple of seconds to fix (once you know to "flip it" twice). However, I'll try and send the example to Luxology to look at.

So then I went back to the original, more complex, MoI file that I had observed having a real problem when loaded into modo. Well, the file had a problem when loaded back into MoI as well. There were some strange faces sticking out of the geometry in a couple of places. Zooming into the nook and crannies, I noticed that I had probably applied a slightly too large fillet around the edges of some text I had booleaned into an object, and in some of the corner creases it was causing some problems. Didn't really see it when I applied the fillet though. So I guess it was my bad after all.

> One other thing you might try when you run into this (which should hopefully be only an occasionally seen thing rather than the norm) is to use the "Divide larger than" parameter in MoI to dice polygons up and alter their structure. If you enter in a distance for "Divide larger than", any polygons larger than that size will be diced down, which tends to also cut complex n-gons into less complex n-gons.

Yes, this is a great feature that I have already had occasion to use. I had created a surface with a very subtle curve that ended up being a single ngon on export. Since I didn't want it to appear to be perfectly flat, I began experimenting with some of the "slice and dice" features in the dialog and quickly solved the problem. Like you said, you probably don't need to use them often, but it's really nice having them there when you do.

> Yeah, I would like to have this in the future... It's unfortunately not always so easy for me to get this information, often times the operation that failed is some low level thing way deep down in one of the geometry library's algorithms and it is not easy to try and record the specific problem all the way from the "top level view" from the code...

Oh, I see. I had forgotten that most of your code is sitting on top of a 3rd party library. Well, you can always give an error similar to one that one of the C compilers back in the 80's used to give me: "Syntax Error: Program expected." ;-)

Dave Morrill

> I'd recommend using .lwo format instead - that will likely eliminate the problems you are currently seeing.

OK, I'll definitely give that a try. The .obj format seemed to work for 90% of the stuff I tried, so I never got around to trying .lwo.

Thanks for the tip!

Dave Morrill

Hi Dave, just a note on this part:

> I say "strange" because selecting the bad ngon and flipping
> it did not fix the problem. But if you flipped it a second time,
> then everything was OK.

Yeah, getting that result is due to one of the bugs in Modo's OBJ importer.

In Modo's core functions, it is sensitive to which vertex of a polygon is set to the first one in the list of vertices.

Modo's core polygon normal calculator only looks at the edges radiating out from the very first vertex of the polygon in order to determine the polygon's normal. So with a complex n-gon, the first vertex must be set to a convex vertex in order to get the proper result.

As far as I can tell, Modo's OBJ importer fails to do that, which may result in an improperly oriented polygon in Modo.

When MoI exports to LWO format, it does this work to set the starting point of the n-gon to a good location for Modo/LightWave's orientation mechanism. So that's why this problem is avoided when using LWO export instead currently.


Since Modo has this sensitivity to which point is the first point, it would be a good idea for their OBJ importer to be aware of that and set the first point to match what their core engine expects...

But also another good improvement would be for them to tune up the core normal calculation so that it is not so sensitive to which point happens to be the first one in the list.

The reason why doing the flip twice works, is that there is a mechanism in Modo's flip function where if you do it the second time it will do some work to figure out a good start vertex for the ngon and rotate the points in the list so that one is first.

Some other discussion on this here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2039.5

- Michael

Hi Dave,

You should be lucky with the .obj in modo, because I've got thousands of n-gones problems when using this format.
As Michael said, .lwo is much better, I can't remember when I had a flipped poly using it ... but still it may happends.

So I'm still doing an geometry>poly>align when importing .lwo object ... it works as a double flip you descibe, but it's an 'autmaic' way
so it will resolve normal problem on area you don't always notice at first sight. (Can be frustrating to discover a wrong poly after an hires rendering of 4 hours for exemple).

Hi PaQ,

> As Michael said, .lwo is much better, I can't remember when
> I had a flipped poly using it ... but still it may happends.

Right now I don't have any reports of improper flipped polygons when using LWO format...

So I'd think that extra geometry>poly>align step should not be needed if you are using LWO format, but by all means if it makes you feel better... ;)


There are a couple of issues that can come up which are not actually bugs though, like if you export an open surface rather than a closed solid, it may not have the normal orientation like you expect because only solids have an automatic "outside" direction applied to them.

Also if you have 2 independent surfaces in MoI that are sitting side by side and not actually joined to have a common edge, then the meshes are generated separately and may not have the same normal orientation between them. When objects have joined edges, the polygons will have a consistent direction between them though.


What I have seen on a couple of rare occasions is a triangulation failure where Modo did not handle splitting up a certain n-gon into display triangles properly. This is a different problem than a normal orientation one, but it is also very unusual to run into it.

- Michael

In general, exporting from MoI is going to be fine for stills. However, if you expect to animate and deform your meshes you will have to get a good topology tool. Bang for the buck going MoI + SILO, or MoI+3DCoat would allow you to get your NURBS models into a program that you can tailor the polygons by retopologizing.

Hi Michael, ... well indeed maybe I have developed some OCD about poly normals :o)

I'm not quite sure what kind of mesh I will build in MOI if I know I have to do some deformation/animation with ... until ... I tried to export a model in ngone + divide larger than option ... the result is quite cool Oo

the original model was less funny =O)

Hi Jason, yeah like PaQ shows you can use the "Divide larger than" function in MoI's exporter to ensure that large polygons are diced up into smaller evenly sized pieces.

That can make a result that should be suitable for non-rigid-body type animations without necessarily needing to retopologize.

Certainly if you have a very specific kind of animation where you want one individual piece to move in a certain way it could be a good idea to retopologize that area though...

- Michael

Good point, good to try first without doing topo again.

What I like though is that MoI is getting to be an artists tool, so keeping in mind that MoI can play nice with modo, 3DC, SILO is a good thing.