> 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!

> 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?

I think that would be nice. The turbine shown before is a nice example where that would help to avoid subdivide unnecessary surfaces...

Great discussion guys, I'll try and nudge Softimage to see if I can get them to try and optimize XSI's input for these kinds of situations...

For me, I find myself having to _add edges_ in some places on certain ngons. So the speed of MOI ends up negated at times when I'm back in Silo or XSI editing edges and verts... Sometimes I just ending up creating the object in those apps after having "experimented in MOI" to get a concept going - not a good thing for what I desire to do (just use MOI!)

Just not sure what to say about all of this - I love what MOI brings to modeling - the speed and ease of getting ideas and concepts polygonated (is that a word?? :-p )

But Lightwave is my main rendering app (I'm more familiar with LW than XSI for now) so my whole reason to purchase MOI is to get exports into these apps with minimum fuss or rework (the main reason why my Rhino purchase went dusty on the hard drive...)

Funny, I'm glad to see Modo has the same probs as LW cause I can now drop it from my mind as a purchase consideration (I started to like Modo's modeling workflow) but I'm definitely not going to spend $700 just for some more import probs!


Today was sorta interesting - I was testing a MOI export for import into XSI and I was looking at the mesh differences between ngon and quad/tri; I sort of wished that right in the export dialog that I could click and add/remove/merge edges & verts to get the mesh exactly as I liked before the save - would have been a cool feature!

-Will

Hi Jacobo,

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

I don't think that would really make much of a difference though... Even if MoI wrote LWO files, LW or Modo would still need to do a proper triangulation of an n-gon from an LWO file as well.

LWO files aren't quite as flexible as OBJ files - they can contain n-gons (up to 1023 vertices), but it doesn't look like they are able to contain vertex normal information. Maybe LightWave and Modo just don't have the concept built into them of a precalculated vertex normal from CAD data...

The only reason there would be a difference with LWO files would be if there are additional bugs in their OBJ readers...

- Michael

Hi Gent,

Thanks for testing in these different apps!

I certainly wish that more of them would behave better... :( I guess the problem is that these apps haven't really been tested with complex n-gons very well because there wasn't any particularly easy way to generate really complex n-gons coming from CAD data until now with MoI. Every other CAD program until now has generated only triangle and quad meshes. < Ugh! :)>

Hopefully more of these polygon apps will get fixed up over time as they get bug reports and there is more of a demand for processing complex n-gons.


> 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.

This one is particularly frustrating because they nailed the triangulation really well which is by far the most technically difficult part.

Reading the normals out of the file is far more simple, unless they just didn't make any provisions to have predefined normals in the app at all...

- Michael

Hi Gent,

> 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?

Yup, this makes sense and should be easy to add. I'll try to add it for the next beta which I want to put out this weekend.

I've also nearly got Adobe Illustrator file import working, that should be part of the next beta too.


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

Not often, because like you mention curved surfaces already get subdivided by the angle parameter.

You would have to have a surface that started out curved on one side and then flattened into a plane on the other side of the surface, with a complex trim on that flattened region.


It seems like XSI is pretty close to having full support, they've got all the ingredients they just need to tune up their triangulator a little bit. If you have a chance, you might want to submit a bug report to them (did you say you did already?) so that they have a good example that they can work with for debugging. If you can try to give them an .obj that has just the one complex polygon in it that doesn't work right.

- Michael