Hi Michael,

Thanks so much for your response! I really appreciate it!

Despite some problems MoI seems to have to export some objects (like the one
I've sent you before), it does far the best IGES to OBJ conversion I've ever
tried. I've always been looking for something like this. When it works well, it does
it so good that I've started to model some stuff in MoI, because it's easier than
do it in a 'polygonal way'.
I'm doing more test to check what kind of problems I'm finding, and if you don't mind,
I'll post them in this thread if they help you in some way. I would really love to see those
bugs fixed with the IGES importing - OBJ exporting. That would be really great!

By the way, I use tablet all the time, and I really appreciate the way MoI is created.
And it's very easy to use, confortable, and nice.


Thanks again!!

Jacobo.

Hi Jacobo,

> When it works well, it does it so good that I've started to model some stuff in
> MoI, because it's easier than do it in a 'polygonal way'.

Yeah, the meshing quality really seems to open up new possibilities, since you can now use CAD / NURBS models to generate high quality meshes without it degenerating into a big chaotic mess of triangles...

You can especially do clean mechanical type models really fast with this pipeline. For mechanical shapes, the results often times look like a lot of effort was spent hand optimizing the polygons, even though they were actually automatically generated... It's almost like cheating! ;)


> I'm doing more test to check what kind of problems I'm finding, and if you don't mind,
> I'll post them in this thread if they help you in some way.

That would be great! Especially if you can post the model files that are involved. When I can replicate the problem over here (instead of just looking at a screenshot) it helps me to debug and solve it.

That's how things get tuned up to become reliable!

But I wouldn't mind seeing a couple of screenshots of complex things that worked well too! :)


> I would really love to see those bugs fixed with the IGES importing - OBJ
> exporting. That would be really great!

I'll probably be able to work on fixing it tomorrow. I should be putting out a new beta pretty soon.

- Michael

Hi Michael,

Thanks again for all your work! This is great, I mean... when you're
testing a program you like, and you see the developers are so open
to users comments and stuff... Thanks for that!

> You can especially do clean mechanical type models really fast with this pipeline. For mechanical shapes, the results often
> times look like a lot of effort was spent hand optimizing the polygons, even though they were actually automatically generated... > It's almost like cheating! ;)

Yeah, I'm doing some mechanical stuff right now, and I'm finding the
advantages of CAD/NURBS. I don't know very well all the CAD world (Just
learnt some SolidEdge a few years ago).
I have to admit I've started to use MoI because I saw what its exporter
could do. I was dealing with some IGES objects, and I needed a clean
polygonal mesh (UVs, rigging, stuff like that... so working with a 'dirty' mesh
would be a pain), and I didn't have much time to clean it manually.
So I've been looking for different solutions, and trying a lot of
options, programs, converters, etc... until I've found MoI. And now,
as you said, there are so much possibilites since you can get a clean
polygonal mesh from NURBs.
People who do visualization for industrial design, or info-architecture
are going to love you! :O) I just showed MoI to some friends of mine who
work on that, and they are really impressed.

> I'll probably be able to work on fixing it tomorrow. I should be putting out a new beta pretty soon.

Great news!! :O)

I was doing some other tests. It's a shame I don't have more complex
objects here, but I have this guys already doing some hard testing on MoI :)

I've attached a RAR with some screen captures and the objects. The original
IGES, and 3 different OBJ versions. Here are some issues:

- Is there a way to specify the number of layers to be exported in OBJ?
I guess it depends on how you made or export the model from your CAD
program (in the case you just imported it from MoI, instead of model it
in there), but if you only have that IGES object, and you have to deal
with it, how do you change that in MoI?
As you can see in one of the screen captures, I've got 901 layers for that
object.

- Problems with some objects when you use n-gons. They look fine when
you see the polygonal preview in MoI, but when you import them into
any polygonal software, the object doesn't look right. You think that's
a MoI problem, or just it's the way other programs import OBJs?

- EDIT: One more thing... With some objects you can get a lot of flipped
polygons. Do you think that's something fixable?


Thanks so much!

Jacobo.

Hi Jacobo, thanks for the additional testing!

> It's a shame I don't have more complex objects here <...>

Well, that fan/turbine thing is pretty complex, that's a great test.


> - Is there a way to specify the number of layers to be exported in OBJ?

There aren't really "layers" in an OBJ file (or in MoI currently either), but there is a way to group polygons into different objects. That's what happening here, you're getting each different surface exported as an individual object.

That's because the original IGES file has got all the pieces stored as different surfaces - it's not unusual for CAD programs to export data to IGES in this way (as just unconnected surfaces).

So what you want to do to fix it up, is select everything and then run Edit / Join. That will glue together surfaces that have a common edge into a single solid object. Then when you export that one solid, it will result in just one single big object in your .obj file. Maybe I should do this automatically, but on complex objects it might take a couple of minutes or so - that's why I haven't set that up as an automatic process quite yet.

It's also a good idea to join pieces to get the best quality - if you have separate unjoined surfaces they aren't guaranteed to be meshed with an identical structure along their edges. If they are joined into one solid then MoI knows that those edges are shared and will do some extra work to make sure the meshes of each surface are aligned along those common shared edges. Also, joining will ensure that the generated meshes will all have a common normal direction.


> They look fine when you see the polygonal preview in MoI, but when you
> import them into any polygonal software, the object doesn't look right.

Well, it looks like you were loading them into Modo which unfortunately has problems with reading complex N-Gons.

There has been some discussion of it on the Modo forum here:
http://forums.luxology.com/discussion/topic.aspx?id=12649&show=moi3d
http://forums.luxology.com/discussion/topic.aspx?id=14281&show=moi3d

So I'm afraid that problem has to be solved by them...

Here's what what the n-gon obj file looks like when read into Cinema4D for comparison:



Unfortunately it is somewhat difficult to handle the triangulation of a complex n-gon properly - it is pretty easy to have bugs that cause triangulation to kind of "leak" outside of the polygon boundary like you are seeing in Modo.

- Michael

> - EDIT: One more thing... With some objects you can get a lot of flipped
> polygons. Do you think that's something fixable?

Joining should fix that.

One other note - some people have had better success with N-gon exports into Modo when dicing things up into smaller polygons. That tends to reduce the complexity of each individual N-gon and sometimes can help avoid the stuff that Modo has difficulty with.

If you want to try that, what you do is inside the Meshing options dialog, expand it to the full settings and then use the "Divide larger than" box, and check the "Planes" option.

You type a distance into that box and any polygon that is larger than that size will get diced down into smaller bits. So for instance if you put 1 in that box, anything larger than 1 unit in size will get diced. This won't be applied to planar surfaces unless you check the "Planes" box.

That will generate a much higher polygon count, but each one of those smaller polygons will have a less complex boundary.

Then the other option as you've seen is to use "quads and triangles" instead of n-gons.

- Michael

> There aren't really "layers" in an OBJ file (or in MoI currently either),
> but there is a way to group polygons into different objects. That's what
> happening here, you're getting each different surface exported as an
> individual object.

Yeah, sorry, I didn't say that correctly. It's just I was using Lightwave
and modo for to import the OBJ, and they store those different surfaces as
layers.
Using 'Join' it worked perfeclty, thanks!

Well, after read all those threads, and take a look to c4D capabilities,
it seems like it's the best to handle this thing. It's good to know.
Thanks for the info! I'm trying fill that big form to get a demo and try
it by myself :O).

I'm assuming that if I see the polygonal prev in MoI correctly, the
OBJ should be OK in other polygonal apps, and if it's not,
it's not a MoI problem... is that right?

> You type a distance into that box and any polygon that is larger than that > size will get diced down into smaller bits. So for instance if you put 1 in > that box, anything larger than 1 unit in size will get diced. This won't be > applied to planar surfaces unless you check the "Planes" box.

> That will generate a much higher polygon count, but each one of those > smaller polygons will have a less complex boundary.

Very interesting option. I've been playing with this, and it helped to
modo/LW to import the mesh in a better way. But still, they don't do it
OK yet. Probably I should play more with that... but after see how good
C4d does it, I want to try it first :O).


> Then the other option as you've seen is to use "quads and triangles" >instead of n-gons.

Yes, triangles or quads and triangles worked with no problems so far
(except for the Cubes I've sent you in the first message). I rather n-gons
option just because it's easier and cleaner to make the UVs, and
texturing process.



Again, thanks so much for your support and good work!

Did you also get N-gon problems with Lightwave as well? I don't remember hearing any complaints about that so far, so I was assuming that was working ok.


> I'm assuming that if I see the polygonal prev in MoI correctly,
> the OBJ should be OK in other polygonal apps, and if it's not,
> it's not a MoI problem... is that right?

Yup, as far as I know that seems to be right.

Certainly if it literally doesn't work with any polygonal app at all it would be more likely to be a MoI bug, but so far every case of this that I have examined (where it seems to be fine in the MoI preview but bad on the import into the poly app), has been a case of bugs in triangulating complex N-gons in the polygon app.


> Again, thanks so much for your support and good work!

You're welcome, and thank you for your bug reports, it will be good to fix up that cube one!

- Michael

> Did you also get N-gon problems with Lightwave as well? I don't remember hearing any complaints about that so far, so I was assuming that was working ok.

Yes, I did. Basically the same problems than modo, and a lot of flipped polygons.


> Yup, as far as I know that seems to be right.

Perfect then! I've already tested C4D by the way... Amazing... I mean, the fact of having exactly the same
mesh I see on MoI preview! That's great...


> You're welcome, and thank you for your bug reports, it will be good to fix up that cube one!

It'll be great!, and I really appreciate it!

Example imported in C4D


Example imported in modo:

Here's another object that shows some problems directly in the Moi preview.
Two screen captures... the IGES loaded in MoI, and the polygonal preview in MoI.
I'm not sure if it's related to the same bug of the cubes, so I post it just in case :O).

Unfortunately I can't post the object files... I'm not allowed to do it :(.





Thanks!!

It looks like that last one might be a different problem... But it is hard to tell.

If it helps, you can privately e-mail files to me at moi@moi3d.com, I will keep the ones that you send private and confidential.

- Michael

I don't have the model in the last screen captures I've shown you.
A friend of mine sent me those captures to see what was going on.
I'll talk with him to see if he can send you the object.

Thanks so much!

Jacobo.

Yes, I was noticing flipping in LW's Modeler the other day as well - I was going post some pics and the 3dm but I see that it's a LW/Modo codebase problem - I'm going to try my OBJs in XSI, hopefully I'll get the same (clean) results C4D is apparently returning...

I'll also test Ultimate Unwrap3d (unwrap3d.com) since Brad was kind enough to add the .3DM (OpenNURBS) format to his program for me; I use Unwrap3D a lot of times as a file translation tool and he grabs the NURBS mesh out of the 3dm and lets you work with it in the program...

I'm wondering if C4D does some special checks to look for flipped around normals and brings them back in line with the majority?

Anyway, good stuff - it is great that MOI creates clean meshes that can be pretty much used immediately in your poly app (well, sans LW & Modo - sigh...)

-Will

WillBellJr,

In XSI be sure to check "Import Normals as User Normals" in the Import dialog, and with the user-normals cluster XSI will display/render it perfectly! They will show up just as moi intended it to.

If you don't do that some of the flat areas with triangles might show messed up highlights, as it won't use any 'custom' normal information, only default normal smoothing.

Which brings me to another point... the rest of you in other apps might want to check some options in you app about importing this kind of normals information, as there really isn't anything special C4D has in displaying polygon meshes. If the thing imports correctly, including custom normals information (direction of the normals) it should display it correctly.

Otherwise if you let the app itself compute the vertex normals based on regular methods (normal averaging of face normals to calculate the vertex normal), these types of meshes that you get from MOI will not display correctly as they are very dense in some parts and empty in other areas which renders these 'automatic' methods useless. (unless you use really high settings, all quads, and even spacing between points)

Here's a picture of what I'm talking about, using an example of potential problem meshes. (where there are these kind of flat areas, large 'elongated' polygons)

And the difference between correctly importing the normals from MoI in the left, and letting the app itself compute the vertex normals based on regular methods in the right.

> Which brings me to another point... the rest of you in other apps might want to check some options in you app about importing this kind of normals information,
> as there really isn't anything special C4D has in displaying polygon meshes. If the thing imports correctly, including custom normals information (direction of the > normals) it should display it correctly.

Some applications don't have OBJ importing options available, and that's a problem.
I've been testing with XSI as well and I can't get a clean mesh like in C4D. I've trying with
different options and some objetcs still have problems. The same with other applications
I've tried. Even Deep Exploration doesn't read the OBJ properly.

I've attached one of the objects that is giving me those problems. MoI reads the IGES
perfectly, and exprot a nice and clean mesh (with n-gons.. you can check the included
OBJ). And then Cinema 4D is the only one that reads that object correctly. Blender does
it as well, I mean, it doesn't show problems in the geometry, but what it does is triangulate
everything when imports, so... not useful.

If you got the chance to test that object, and you can get a clean n-gons mesh in XSI
(or any other application), please, let me know. Maybe I'm missing something, or doing
something wrong.
I have a couple of friends who tested it in 3dsMax with no good results.
EDIT: I've just instaled Maya PLE (after all, where OBJ format comes from :O)), and tested it by myself, and it seems to work as well as Cinema 4D with this particular object.

Thanks!!

If MoI exported to LWO, I'd be sooo happy :O))).

Hi, I will try to give feedback on that object for apps that I have access.

The original .obj that's included doesn't display correctly in XSI. Actually only the large planar polygons like the outer ones and the inner ones in the circle (large continuous polygon) don't import correctly.

but by using these settings, which divide these large planar polygons(ngons) in at least 4 parts seems to solve it! (you can see the difference to your .obj, a grid-like pattern in the big planar polygons)



Here's how it imports in XSI now with these new settings (check "import normals as user normals" in XSI):



This looks like a problem particular to XSI though, so if you're using that make sure you use some value of "divide larger than" with "planes" checked, so that you don't get such large continuous polygons with high vertex numbers.


Silo:

In Silo the actual mesh imports correctly, no problem with those planar polygons, but the smoothing is totally fubared, seems it doesn't import normal information correctly.

Hi Will,

> I use Unwrap3D a lot of times as a file translation tool and he grabs
> the NURBS mesh out of the 3dm and lets you work with it in the program...

Depending on what he reads, this may not work with 3dm files from MoI, because MoI does not store the display polygon mesh for the NURBS surface inside the .3dm file in order to keep the file size smaller.

So unless he reads the actual NURBS surfaces directly (which is unlikely), it won't work, since there isn't any kind of polygon data stored in MoI's 3dm files. You'll likely need to use a polygon format like obj for that still.


> I'm wondering if C4D does some special checks to look for flipped around normals
> and brings them back in line with the majority?

No, it's not that, I haven't yet seen a file where MoI put out incorrect normals interior to one single object that needed to be flipped.

It's a combination of 2 different things that it does well. First, it uses the vertex normal smoothing information that MoI writes to the OBJ file. Gent gave a great description and comparison of that above. This smoothing information that MoI writes comes directly from the NURBS model itself so it is very accurate. When a polygon program tries to calculate its own smoothing just by averaging perpendiculars from surrounding facets, it doesn't work very well unless the polygons are all pretty evenly sized and distributed..

Then the second thing is that it can triangulate a complex concave n-gon correctly without trying to put in triangles between vertices that make the triangles go outside of the n-gon boundary. In order to render pretty much everything has to eventually triangulate the n-gon and if it doesn't produce a good triangulation you will get a mess. This is typically the main problem that prevents good n-gon imports in many applications. It's unfortunately somewhat difficult to code a really robust triangulation algorithm.

Unfortunately there isn't any way in the OBJ file to store the triangulation of an n-gon in addition to the n-gon itself - it's up to the application that reads the OBJ file to calculate the triangulation properly...

- Michael

> these types of meshes that you get from MOI will not display correctly
> as they are very dense in some parts and empty in other areas which
> renders these 'automatic' methods useless. (unless you use really high
> settings, all quads, and even spacing between points)

Hi Gent, thanks for the excellent description and comparison!

One other note I'd like to add - if for some reason you know that you will need to use an automatic normal calculation, there is one other thing that you can do to prevent the "shading bleeding" type problem, which is to turn welding off when you export the mesh.

With welding off, the polygons for each surface will have their own individual vertices along the common edges - they will be stacked on top of each other, but separate.

Since those unwelded polygons don't share vertices between each other, the automatic vertex normal averaging won't include polygons from the other surface. On the other hand even though it prevents bleeding it kind of causes a reverse problem that the edges will probably get slightly accented with a kind of slight shading break at a common edge that is supposed to be smooth, but it is probably preferable to the bleeding.

But anyway that option can have an effect on normal calculation as well.

Of course the best is to use the accurate normals and get the really nice shading!

- Michael

hmm... yes, XSI too seems to have problems with such complex concave n-gon's as you mention Michael.

You'll have to use "divide larger than" with "planes" checked when exporting to these applications, so that it divides it in a couple of parts.

So is it possible in the future for the obj export option to have a "divide larger than" value that is valid -only- for planar surfaces which would make it useful for such n-gons as you mentioned?

There wouldn't be much cases in MoI, where there would be complex concave n-gons that are -not- planar right?

This would be useful because it wouldn't divide other more 'organic' non planar surfaces further at all, because those will likely already have enough detail based on the angle parameter.

Oh, and thanks for clarifying these things.

PS. that might be too many questions for one post, sorry. :P

Hi,

Thanks Gent for taking some time to test the object. As Michael suggested me before, I've been
playing with the 'divide larger than' to reduce the n-gons size, and it helped LW and modo to
import the OBJ in a better way (but it still wasn't displayed properly).
It's good to know that it really helps in XSI, and it works good. I've been testing and it's imported
fine even with larger values in 'divide larger than', wich is nice. Thanks for that! :O)

By the way, did you try to export that mesh in LWO from XSI, using Point Oven? It's just I've been
trying but it freezes the XSI.


Michael...
The guy who sent me the screen captures of the object that looked wrong in MoI, sent me just
a part of the object, because it belongs to a client and he's not allowed to send it all. So, he just
send me the part he said looked worse... but the thing is, I've tried it here and it works perfeclty.
So it seems like the problem shows up with the whole original mesh only...
We got some big complex models to keep testing (like a detailed personal watercraft), and I'll post
here any problem we find. We want to put some pressure on MoI :O)).


Thank you guys!