> 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

Hi Matt,

> Wow, next build will have a LWO exporter?

Yup, I had not originally planned on doing this for v1, but it seems to be the only way to get n-gon polygon data into LightWave or Modo fairly reliably.

I'm glad MoI is useful to you for transferring 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?

It's theoretically possible, but it would require a substantially different approach to the meshing process.

The underlying NURBS surfaces are inherently quad based, so meshing just a plain surface generates quads nicely. The problem is with trimmed-away areas. Trim curves on surfaces generally go in any direction, they don't necessarily follow the same quad flow-lines of the surface.

So it's quite difficult to generate all quads with trimmed surface data, it just doesn't come very naturally, it would require a lot of complex code to try and squeeze little quads around trimming boundaries. I won't be able to dig into something that complex anytime too soon...

- Michael

Yes, exporting an all-quad mesh would be the holy-grail of polygon exports - something I wouldn't dare try to ask for - LOL (Just thinking of Indiana Jones with all the mess he went though over the Holy Grail! I don't need skeletons flying around the room whenever I'm performing a MOI export into Lightwave! :-p )

It's nice to see so many LW'ers around here!

I'd like to say again thanks Michael for the time you're putting in to help us out. MOI is really nice with what it does and I really want to use it within my workflow - this will help a lot.

THANKS!

-Will

No problem Michael! Even with all quads, MOI still produces the best meshes out of any converter I've seen.

I just tested an import of a more complex object, I'm still getting polys flipped, despite joining surfaces, see attached.