Hi,

I follow the progress of MoI for quite some time now and more and more it becomes indispensable for me.
First I was fascinated by the interface quality and speed, then with the quality and beauty of the polygon-export and now I more and more start to enjoy modeling with it as well, although I am not a NURBS-guy by default, but rather like to build semiorganic objects with Subdivision Surfaces in Softimage XSI.
I tried Rhino several times over the years but never really enjoyed it. I bought SolidThinking once for a job since it has a very userfriendly workflow (at least in theory) and a full history, but it has major quality/functionality and interface problems and the export is nothing to rave about.
But MOI makes NURBS fun. :-)

Michael, this Tool is simply brilliant! Congratulations and Kudos to you.

Inspired by a recent customer request for some illustrations with a "puzzle" or "jigsaw" theme, I came up with this object:



This is about 500,000 polygons rendered in Softimage XSI 6.5/Mental Ray with 6500x4876 pixels, 16bit RGBA. Rendertime was about 8 hours with heavy blurred reflections and ambient occlusion on the floor on my aging P4 3.0 Ghz Laptop with 2 Gig Ram & another machine with the same specs (via satellite rendering).

My only remaining problem with MoI is, that I often have a hard time getting poly exports (obj) without seams between the main surfaces and the (G3-) fillets. With Ngons, I get superb clean meshes but visible seams when rendering, with 3+4 point polygons the seams are less pronounced, but still not perfect, so one always has to clean up in photoshop after rendering. This would be my number-1-topic on the wishlist: The export is almost perfect, but the final 5% would make a big difference for me.
I don't know if this could be a solution, but I often wonder why the number of subdivisions between a surface and a fillet is so different, even for simple transitions where it "should" be possible to have the same pointcount on the fillet and the surface. Michael, if you can come up with some kind of "superclean" mode, even if the subdivision is changing over the model, but seams and changes in pointcount are minimized as much as possible, it would be a really big thing IMO.
I can go into more detail if needed.

But nonetheless: MoI is the most intuitive, userfriendly and fun NURBS tool I've ever encountered! And that without any compromise on quality.

Thank you very much Michael for all your hard work and support!

Thomas Helzle
www.screendream.de

Thanks Tommy, I'm glad that you are enjoying using MoI!

I really like your puzzle sculpture piece. That was a cool choice to have the interior sort of velvety like that.

re: Seams when rendering, and different point counts between fillets and surfaces - if possible could you please post a sort of minimal example of these, that would help me understand the problem (especially if you can include a not too complicated .3dm model file).


> but I often wonder why the number of subdivisions between a surface and a fillet is so
> different, even for simple transitions where it "should" be possible to have the same
> pointcount on the fillet and the surface.

Often times the fillet and the surface can have fairly different internal structures to them. Things like the UV parameter space of each one can be spaced differently, and that has an effect on breaking up the surface into smaller pieces during subdivision.

I have some ideas on possible ways to improve this in the future, but it is a pretty difficult area of work. Having some examples definitely helps me to better visualize the problem and then also test solutions.

- Michael

Hi Michael, thanks for your reply.

I didn't want to sound arrogant - sorry, my english isn't up to the finer tunes sometimes :-(

I am actually quite aware of how difficult this area is, so I am more looking for a kind of "prefer seam point alignment over poly reduction" or something along this line, not for a "perfect" solution which may be impossible anyway.
For the puzzle object, I created one puzzle-spline and copied it three times, then scaled the middle one smaller, then lofted those three. So the mesh is very clean, since the splines are all three exactly the same, created from one continuous splinedrawing.
But when I fillet the top and bottom with G3 and then export the result, I get this - the points are not aligned:



If I create a default cylinder and fillet the top edge, the polys are aligned perfectly.

So if you should happen to have a clever idea that could reduce this problem I would be very happy. :-)
I do a lot of conversions to polygons for clients lately and this is the main problem I run into.

Another idea to solve this problem: Since a G3 fillet is supposed to have the same surface angle on both sides of the seam, would it be possible to create two small rows of polygons (one on each side of the seam) that are "flat"/have the same normal direction as a buffer zone for the normal-algorithm of the rendering software?
So instead of just angle based calculation, there would be another layer that makes sure that joined edges between NURBS patches get a special treatment?

But maybe it is just XSIs obj import? I'm not sure it handles the imported "user normals" correctly?
Anyone else using XSI?

I'll send you the object via email.

Thank you very much!

Thomas Helzle

Hi Tommy!

> I didn't want to sound arrogant - sorry, my english isn't up to the finer
> tunes sometimes :-(

I didn't find anything in your post that sounded that way to me, sorry if I gave that impression!

I just wanted to describe that it may take me some time before I am able to improve this particular thing - sometimes for other problems I try to fix them up faster than that.

Normally one of the difficulties with aligning a UV quad mesh is when you have surfaces on different sides sort of applying pressure for alignment at the same time. However maybe I can do something special for this case where there is a plane all one one side, that could kind of "relieve the pressure" from that side and let me focus on alignment to the non-plane edge...

Doing this means creating a kind of "order of meshing" dependency on the meshing process - it's a big enough change that I think it is too risky for me to attempt it right now just before releasing V1 (I've got to be careful not to introduce any nasty bugs at this point) but I think I should be able to experiment with it for V2.


> But maybe it is just XSIs obj import? I'm not sure it handles the imported "user normals" correctly?

There should be a checkbox during OBJ import in XSI that says something like "Import Normals as User Normals" - make sure that is checked and you should then have good normals working.

There was some discussion of that in this thread: http://moi3d.com/forum/index.php?webtag=MOI&msg=656.15

There have also been reports of XSI not fully handling more complex N-gons with a lot of points in them. If you're running into that issue you may need to either use "Divide larger than" to force some additional subdivisions on complex n-gons (you may want to set the drop-down to just divide planes only, which is one technique mentioned in the above thread), or switch the Output to Quads & Triangles instead of n-gons.


One thing that may be causing you additional problems - there are some pretty tight bends in your outline, and it looks like the radius of the bend is quite close to the radius of the fillet. This tends to create a kind of bunching effect, sort of like this:



It looks like this may be happening on some of those tighter corners, which is messing up the quality of the surface continuity right in those tight corner areas.

- Michael

Michael, thank you very much.

Yes, this special case scenario could be helpful for fillets from a plane to a bent area.
It could be also interesting for the N-Gons setting to have a checkbox that gives "mesh-cleanness" a higher priority than the angle, so the algorithm would try to maintain a certain subdivision throughout one NURBS patch to get more quad polys.
This could also lead to a Subdivision-Surface enabled output in the end, which would be just great to have. ;-)

Or the other way around: Obj-cage import to something like t-splines ;-)

My problems are almost always with the seams between fillets and surfaces, but I just found that if you import an obj into XSI and let it make separate objects out of the obj-groups, it will not import the user-normals at all (XSI 6.5). If you let it create clusters out of the groups it seems to work better, but I'm not sure if the result is really correct. I will further test it and report if I find a route that really works reliable.

EDIT: XSI does the user normal import just fine, no matter if I select groups as objects or groups as clusters. I can no longer reproduce the above problem, so it must have been some kind of user error I guess. Sorry for that.

That other thread you linked to is really cool and very helpful - sorry I missed that.
XSI is basically perfect for this kind of export since it handles millions of polygons without much problem. But some parts of the software are really aged - One of the programmers once admitted that their IGES importer is over 10 years old <LOL> OMG
It messes up trims all the time so I no longer try to use NURBS directly...

I fully understand your point about introducing new bugs into 1.0, but I hope you will continue to develop MoI in this kind of open manner, so that registered users can always get the latest beta to try out the new stuff and give some feedback and don't have to wait all the way up to Version 2.0 ;-)

Thank you very much!

Thomas Helzle

P.S. One question: When I first write a message, I have no formating toolbar on the top of the message window (for things like image links etc.) but if I edit an existing message, there is a full featured formating toolbar above the test field. Is it possible to enable that toolbar always? Thanks!

Hi Tommy,

> It could be also interesting for the N-Gons setting to have a checkbox that gives
> "mesh-cleanness" a higher priority than the angle, so the algorithm would try to
> maintain a certain subdivision throughout one NURBS patch to get more quad polys.

Yeah this is kind of another tricky area. Most of the time an irregular surface will have different levels of hierarchy in it when it is refined. To not have any refinement hierarchy would generally mean having an extremely dense initial grid, but that can get out of hand pretty easily with a really huge quantity of little tiny polygons in areas that don't really need them.

Also, even with an extremely dense initial grid you still aren't going to get quads only (instead of N-Gons) along the edges of the surface if you have done operations like trims or booleans that generate more complex trim curves on the surface. Here is a thread that illustrates what happens with trim curves: http://moi3d.com/forum/index.php?webtag=MOI&msg=1016.1

It would take a significantly different approach to only generate quads along trim edges instead of N-Gons.

I have some idea of adding in some other control to try and let you override the regular angle subdivision. I was thinking of possibly another angle parameter. If this was specified, I would make a pass through the mesh after subdivision had happened, and try and glue divided pieces back into a larger piece if they were within this other angle. So maybe you could have a primary angle of 5 and a "glue back together" angle of 1, that might work as a way to try and reduce subdivisions.

But I also kind of worry about adding in so many elaborate parameters to the whole thing as well...


> but I just found that if you import an obj into XSI and let it make separate
> objects out of the obj-groups, it will not import the user-normals at all (XSI 6.5).

It's definitely worthwhile to get the proper normals in, that really makes a significant difference.



> but I hope you will continue to develop MoI in this kind of open manner, so that
> registered users can always get the latest beta to try out the new stuff and give
> some feedback and don't have to wait all the way up to Version 2.0 ;-)

Yup, this is definitely the plan. I hope it won't take too long after version 1 ships before I'll be back doing more beta releases for version 2.0 . The only difference from the current pre-version 1 betas will be that the 2.0 betas will probably only be available to version 1.0 customers instead of just freely available for anyone to use.


> One question: When I first write a message, I have no formating toolbar on the top
> of the message window (for things like image links etc.) but if I edit an existing
> message, there is a full featured formating toolbar above the test field. Is it possible
> to enable that toolbar always? Thanks!

Currently there isn't a way to enable it - I sliced out that toolbar along with several other things to simplify this forum from its initial configuration, but I forgot to strip it out of that Edit message page as well. After version 1 is out I should be able to tune up the forum a bit and I would like to add back in a simplified toolbar to the initial post page at that time as well.

- Michael

Well, I definitely would prefer to have that edit bar on ;-)
It would also be cool to be able to not by default only see the unread posts - I always want to refer to the context.

I really look forward to your experiments with other export options.

Here is another rendering of the "Puzzle-X" object:



Cheers,

Thomas Helzle

A great picture....

Hi Tommy, that new view is pretty nice too, it shows off the puzzle form of the top more.


> It would also be cool to be able to not by default only see the unread posts
> - I always want to refer to the context.

There's a View: dropdown in the upper-left corner, if you switch it to View: All discussions (instead of View:Unread discussions), does that do what you want?

Also if you scroll to the bottom of any thread there will be controls to navigate to different portions of the thread.

- Michael

Yes that dropdown does what I want, but I have to do it every time I visit the forum ;-)
It would be cool to have more Options like that in the user settings.

I guess I'm spoiled by other forums ;-)

Cheers,

Thomas

Another question:

How can I flip the surface normal in MoI? I haven't found this neither in the manual nor when searching the forum.

I get Rhino-Objects from someone else, convert them to polygons (obj) with MoI and then render them in XSI. But every now and then, the surface normals are inverted. Since I need to use the imported normals from MoI to get renderings without seams in XSI, I can not simply flip the polys in XSI.

Thank you!

Thomas Helzle

Hi Tommy, there currently isn't any way within MoI to flip the normals, there just isn't hardly anything within MoI itself right now that is sensitive to it.

If you can make a finished solid out of your object instead of an open surface, the normals should get oriented towards the "outside" automatically.

I really expected a polygon modeler to be able to handle flipping a mesh object correctly though. Instead of throwing out the vertex normals, XSI should just flip the normals as well as flipping the polygons. Is there any way you can submit a bug report to get this fixed up in XSI?

I do want to add a way to control flipping at export time from MoI in a future version though.

Until then it may be possible to use double-sided materials or something for these objects?

- Michael

Hi Michael,

no, XSI does it correctly IMO.

Since I need to use the "user defined normals" from MoI in XSI, it uses those very strictly.
Normal normals can be flipped easily in XSI, but not user normals AFAIK - which makes kind of sense.

There is a plugin to edit user normals for XSI, which includes the inversion of the normal direction, but it is rather old and I couldn't get it to work on the already existing normals from MOI. (Anybody knows how to make that possible? The docs are no longer available for that tool in Netview)

For normal objects this wouldn't be much of a problem - as you said it would be possible to just use doublesided materials. But in this case I am doing glass/water renderings for bottle-designs and the surface normal has to point in the right direction for the Inside/Outside based glass refraction and reflection calculations to work correctly.

I will try closing the surface completely and see if that helps. That sounds like it could work (the bottles are open on the top where the cap covers them).

EDIT: Closing the bottles at the top worked! Thank you so much for the fast help!

EDIT2: I spoke too early. It seems that of 3 bottles in the scene, 2 are correct and one is wrong - and which one seems to be random...

I think this is a very important thing to have inside of MoI though - not only on export.

Thank you very much!

Thomas

Hi Tommy,

> no, XSI does it correctly IMO.

I thought the way it was doing it was causing a problem for you?

It is understandable that under a general edit operation such as moving a single point of the mesh around, that they would throw out the pre-calculated vertex normals for that since it is difficult to figure out how to re-orient them to adapt to the subtle change in shape.

However, for other operations that do not change the shape they should try to keep any custom vertex normals in place.

For example, moving or rotating the entire object - they should not discard precalculated normals in this case.

Flipping is the same kind of thing, flipping does not change the shape so it is easy to keep the precalculated normals in this case, just multiply them by -1 to flip their direction as well.

The problem is that XSI is treating flipping as a kind of "custom edit operation" when it is actually a "vertex normal preserving edit operation".

It would be great if they would fix this up in XSI - if they did you would not have run across a problem in this case.

I didn't really worry about flipping initially since I thought any advanced polygon modeler would be able to handle flipping without causing any problems since it is such a basic operation, but it turns out that is not the case. Actually Cinema4D has the same problem as well.


> EDIT2: I spoke too early. It seems that of 3 bottles in the scene, 2 are correct and
> one is wrong - and which one seems to be random...

Can you please send the model files to me at moi@moi3d.com, I'll take a look and see what's wrong.

My guess would be that the bottle didn't get quite fully sealed into a solid?

- Michael

Hi Michael,

I think this is a typical problem of perspective... ;-)
If I would ask Softimage to "fix" this, they would say something like: "How on earth can a 3D-Modelling Software have no way to flip surface normals" but this time targeted at MoI ;-)

User Normals are something I NEVER ever use in any other software, be it Lightwave, Cinema or XSI, with the latter being the most advanced. There is little need for this when you do normal polygon modelling. So from my (and propably Softimages) view, this is something rare and special.
I don't know how user normals are treated when you edit or deform the model, but this is a massive challenge to do right IMO as well.

So I guess it is me writing a script for XSI to invert the imported user normals for now.

But since this is a typical problem, especially when importing IGES files where normals are often completely wrong, a way to view and flip Normals in MoI is important.

Sorry, those bottles are under NDA, so I can't send them to you.
I "fixed" it by exporting them several times and grab the bottles with the correct normals from the different exports.

Cheers!

Thomas

Hi Tommy, I guess the difference is that MoI does not particularly have any operation within its own functioning that really depends on the normal direction right now.

However, XSI's rendering function does behave differently depending on the normal direction... So that makes a lot of sense for them to have a flip function as part of their toolbox. It would be nice if their flip function wouldn't discard this important model data though.


> There is little need for this when you do normal polygon modelling.

True, but it seems like rendering is a pretty big function of XSI as well... Isn't that what you are using it for in this case? For rendering CAD data having accurate vertex normals is a really significant thing.


> I don't know how user normals are treated when you edit or deform the
> model, but this is a massive challenge to do right IMO as well.

It is for a fully general edit like tweaking a single point. But for a full-object rigid body transformation like move, rotate, scale, mirror or flip, it is really easy.

At any rate, I do want to add the ability to flip inside MoI in the future it just won't be a part of version 1.0 .

- Michael

Michael, so far I found workable solutions and workarounds for all my problems with MoI thanks to your help, so all is well.
Your knowledge and help here on the forum are worth much more than some features, so please do as you see fit for your development.

Thank you so much!

Thomas

Hi Thomas, thanks! And I'm glad that you have been able to work around those problems.

It helps me a lot to hear about the problems here on the forum because that generally helps me figure out what to work on to make improvements, although sometimes it will take a little while before I can get it implemented.

So thanks very much for your feedback and for sharing your cool renderings too!

- Michael