> 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

Hi Michael,

Thanks for your response.

I think it may be their OBJ importer problem. I think they wouldn't have
those problems reading LWO format. An example is, I never got a problem saving
an LWO object in Lightwave and reading it in modo, and viceversa.
Another example is what is shown in the screen captures below.
I've exported a simple object from MoI. The first capture shows that object
loaded in modo. I've loaded the same OBJ in XSI, wich read it OK, and then exported
it in LWO via Point Oven. The second capture shows that LWO loaded in modo.





In any case, I'm just guessing. I don't know how those object formats work internally.
What do you think?

EDIT: By the way.. how do you do to see the attached images in the message?
(sorry for such a stupid question :S)


Thanks!!

Jacobo.

> In any case, I'm just guessing. I don't know how those object formats work internally.
> What do you think?

Hmm, well that's very interesting.

One of the things with OBJ is that it supports different attributes on each face. Like 2 faces can share a single 3d vertex point in common, but have different separate entries for uv coordinates or normals. MoI will normally export stuff like this in its OBJ files.

Possibly they do not internally support this type of different-attributes-per-face structure so they have to try to reconfigure the data and that has reconfiguration has some bugs in it.

Can you please try one experiment? Take that shape you show in your screenshot, and export it from MoI as an OBJ but set "Weld vertices along edges" to _off_ (not checked), and see if the OBJ with that setting works better.

When you turn off welding, it will make an OBJ with a somewhat more simple structure, there won't be faces that share a common 3d point but have a different uv for example - either everything (3d point, uv point and normal) will be shared or not. It should be closer to the structure that they seem to use.

Does that seem to work better than before or not?


> EDIT: By the way.. how do you do to see the attached images in the message?

You have to type a little HTML code in your message if you want your attachment to show up directly in your message, there are some details here: http://moi3d.com/forum/index.php?webtag=MOI&msg=68.118

- Michael

Hi,

I've tested what you suggested, and here's the result.
'Angle' value is 12, and 'Weld vertices along axes' is ON:



Keeping 'Angle' at 12, but turning 'Weld vertices along axes' OFF:



When I increase the resolution and n-gons size ('Angle' is 8), this is
what happens. 'Weld vertices along axes' is OFF:



The same but 'Weld vertices along axes' is ON now:




And here's a problem I've found editing this object in MoI. As you can
see in the images, I've just selected that edge, and then apply 'Fillet'.
And that's what happens to the surface:



I've attached the IGES by the way, so you can test it (housing_shf_60_l.rar).


Thanks!!

Jacobo.

I guess there just isn't much hope for the Modo OBJ reader, it just does not seem to be able to handle N-gons well. The denser and more complex they get, the more it gets messed up.

Modo does seem to be able to handle n-gons from LWO files a lot better for some reason (less bugs in that particular code I guess). I decided to test that by writing a new LWO exporter. Even when sending the exact same polygons, it works well with LWO and not well with OBJ. That seems pretty weird to me but that seems to be the case.

It's still not perfect even with LWO, I saw a couple of triangulation errors still on certain n-gons, but it is more like 2 errors instead of 100 errors. So it seems like that should help out a lot.

LWO does not support vertex normals for smoothing though, so you can't get the really accurate shading as Gent showed above. It seems like that style of shading is just not supported in Modo or LW. So it may not be possible to get quite as high of render quality as Cinema4D or XSI that do support the accurate vertex normals.

- Michael

Thanks Michael for looking into the import issues with the LWO codebase - Lightwave is my main app and being able to get MOI objects into it (even if a roundabout method is required) is important for speeding up my modeling workflow (through the use of MOI.)

-Will

Hi Michael,

First of all, thanks a lot for the LWO exporter! That is just great!

It's a shame what happens with some OBJ importers. After test
with different objects in different applications, it seems like the only
ones that import the OBJ right are Maya and Cinema4D.
Even converter programs like Polytrans or Deep Exploration have
problems.

It's funny what modo does with OBJs, because I've been trying to export
some objects with some kind of complex n-gons from modo to OBJ, and
then it imports that OBJ with no problems. But when you try to import
that OBJ in another different application (like Lightwave) the mesh is
messed up.
And the same things seems to happen to Lightwave if you export an
OBJ from it. It reads the object OK, but not other apps (like modo).

Again, thanks!! I can't wait to try the new beta (is the LWO exporter going
to be included on it?).

Jacobo.

Hi Jacobo,

> Again, thanks!! I can't wait to try the new beta (is the LWO exporter going
> to be included on it?).

You're welcome, yes I will include the LWO exporter in the next beta, it's going to probably delay the beta by a couple of days though. Probably the bugs that you reported earlier (the filleted box and that other fillet one) will have to wait until the next one after, but I figured that you would rather have LWO as a higher priority anyway.

Originally I wanted to focus just on OBJ because it is the most flexible format, it pretty much supports everything - n-gons, vertex normals, smoothing groups, per-face attributes... It would be really nice if other applications would provide OBJ importers that worked.

- Michael

Hi Will,

> Lightwave is my main app and being able to get MOI objects into it
> (even if a roundabout method is required) is important for speeding
> up my modeling workflow (through the use of MOI.)

The next beta with direct LWO export should make it much less roundabout. There still may be a few issues though, you may need to manually split a few n-gons that LightWave doesn't triangulate successfully but hopefully these should be small in number.

- Michael

Wow, next build will have a LWO exporter?

Michael that is great news!!!

We use SolidWorks at work, and used to translate to LightWave using STL. Problem was, being STL it triangulates everything, even if a quads or n-gons would be fine. The fact that MOI imports IGES files beautifully and can mesh to quads / triangles or n-gons meant mesh sizes (and poly flow) were great improved.

In previous versions of MOI I too have the polygon normal flipping issues, even joining surfaces in MOI didn't solve it.

The first attached image shows the problem I had.

The latest build seems to be much better, as you can see from the second attachment

But I must thank you for an excellent piece of software, it has transformed how we import from SolidWorks to LightWave.

Out of interest, what are the chances of being able to mesh to ALL quads? Or is that not possible in order to acheive a good mesh?

Best regards
Matt Gorner