Hey, Michael

thank you very much for all those suggestions and reads – I'll have a look into those.

Regards,
Sebastian

I remember a discussion on Modo forum, where someone qualify MoI mesher been "bad" because the topology was not sub-d friendly :)

Btw I dont know for C4D, by when you start messing with MoI topology in Modo (merging, flipping poly etc), you just introduce all kind of shading artefact because the vertex normal is not right anymore.
Otherwise, the rendering is just perfect with MoI ngones, I dont remember any glitches since one year or so ...

Hi PaQ,

> I remember a discussion on Modo forum, where
> someone qualify MoI mesher been "bad" because
> the topology was not sub-d friendly :)

Yes, some people seem to expect that it should magically create the same topology as a highly experienced sub-d modeler would do by hand... And no doubt, that certainly would be cool if it could optionally do that (optionally because as I mentioned previously sub-d friendly topology and sparse wireframe n-gon topology are actually different things).

Unfortunately that level of expectation is what I'd call "pretty highly unreasonable" though. It's very difficult for software to replicate things that require a kind of case-by-case human judgment to them.

There are some interesting new auto-topology tools in 3D-coat recently but that overall technique is more for a kind of all smooth blobby sculpted shape and not really for CAD solids so much, particularly with a mix of large and small features.


> Btw I dont know for C4D, by when you start messing with
> MoI topology in Modo (merging, flipping poly etc), you just
> introduce all kind of shading artefact because the vertex normal
> is not right anymore.

I'm not 100% sure but I think C4D will automatically delete the vertex normals if you do some editing operation that makes them invalid.

It would be good for Modo to do the same thing as well, just automatically delete the vertex normals if you do something that modifies the shape of the mesh like pulling some individual vertices around.

The vertex normals information is something that should be tied to the current particular shape of the mesh. If the shape changes it just does not make sense to apply the same normals from its previous shape to its shading, yet that is what happens in Modo currently I guess.

But it's also good for the vertex normals to be kept and transformed with operations where it is possible to do so, like if you transform the whole mesh (like by rotating or scaling it so the overall shape of it stays the same), or also flipping a chunk of mesh does not need to invalidate the normals it can just flip them as well. It's not really very complicated stuff, so it's kind of surprising and frustrating that this is often not handled well.

- Michael

**It's not really very complicated stuff, so it's kind of surprising and frustrating that this is often not handled well.**

Yes, thats true. I own Cheetah3d (MAC only, since I run MoI in Parralels) and was asking the developer over at the forums, what's happening. He told me, that vertex normals are recalculated automatically on import. So there's no chance I use this as a renderer without having to "polyflipweld" my ass off. :-)

Regards,
Sebastian

Hi Sebastian - that's unfortunate re: Cheetah3d not using the vertex normals from the file and instead calculating new ones, it's discarding some important data there. With CAD data, it's never going to be able to calculate the same normals since all it has to work with are a bunch of facets and not the original NURBS surfaces.

One thing that can help somewhat with that is to try and make a more finely diced up export from MoI, using the "Divide larger than" option to break polygons down to a more uniform size. But even then you're still going to see various imperfections in the shading. It's soooooooo very much better to have the true vertex normals - getting the true vertex normals over results in a super smooth and perfect looking render without any messing around at all.

Automatically calculated normals don't work very well with things like a large polygon face right adjacent to a bunch of small polygons for a rounded edge, it's too easy for the little poly on the rounded edge to overly influence the shading on the large polygon with stuff like that, and that kind of large flat face next to a rounded edge is a common kind of structure with CAD models. More organic sub-d models tend to work ok with automatically calculated normals because they're typically constructed out of all the same general sized polygons that kind of gradually bend around.

So some rendering programs that have become very focused just on dealing with sub-d models may not really know how to deal with CAD data that has a different structure than organic sub-d type models. But that's becoming fairly rare now, most renderers out there are able to import vertex normals these days.

- Michael

Hi Michael,

I've tried various settings with the MoI exporter to use the mesh with cheetah3d - nothing worked without glitches. The only semi-acceptable solution is turning off "weld" so you get phong breaks, where the faces meet, but the surface of single faces are completely smooth.

I think I don't get around buying modo for this. Theres actually no other software for MAC, that lets you edit UV, imports normals from CAD and has a great renderer...and won't make me beg for a credit at my local bank (like autodesk would)

;-)

Hi Sebastian, yes the "edit uv" part kind of narrows things down somewhat.

Although another possibility might be to use a dedicated UV editing utility for that part, like UVMapper http://uvmapper.com/downloads.html there seems to be a "classic" version there for the Mac which looks like it is free, so that may be worth checking out to see if it can do the uv editing that you want.

Then that would enable you to use something like Simlab Composer for rendering which also has a Mac version I believe.

But it sounds like Modo or Cinema4D would have all of what you are looking for in just one single package so that could definitely be useful.

- Michael

Ahh Ha! I found a quicker workflow to importing a model into 3DS Max without normals. It's v6 ;)
This model "Thank you to Steve, it's and excellent test" was imported as an obj using moi's output to ngons.

NGons came in great, but I knew I'd have to add smoothing groups. No biggy usually auto smooth at 45 degrees is great.
I added an edit poly, welded points as far as possible without damaging the model.
Then selected all polys and clicked the retriangulate button.
All that was left to do was less then 5 mins worth of edit triangulation, to turn some edges to eliminate sliver type polys.
Finally selected all polys and added auto smooth 45 degree. Any more bad smoothing errors will show up as to many smoothing
groups. This time however it created just 2 groups using auto. One flat grp, for the bottom, and the rest of the model for the other.



The moral of this story for me:
I think what I've learned from this thread is that you can't get away with not tweaking your model in some form or another
in your final rendering software. That is, it's very rare not to. ;) For me same has gone for C4D even 11.x. But being a well
seasoned veteran of polys, it's probably something I look at more closely then most CAD users. Although, you can see by my
3DS max version it hasn't been my full time career since at least 2005. ;)

To Steve's defense:
By the way yes slicing can take time to workout in Moi but can be a great way to force a sort of poly structure.
Although I can't get it anywhere near as clean as the radial sliced model shown earlier in this thread.

My Sliced model in Moi
Not meant to be for meshsmoothing just as a way to tidy things and force better smoothing groups in polygonal renders:


In retrospect, I'd say well over 75 percent of polygonal models I had created years ago with strictly 3DS Max required some
poly tweak or another. In particular when you had to use a boolean in that software. Booleans in polygonal software require hefty
point weld edge turn etc...

Hope I'm not hijacking

Hi FlashFire,

> The moral of this story for me:
> I think what I've learned from this thread is that you can't get
> away with not tweaking your model in some form or another
> in your final rendering software. That is, it's very rare not to. ;)
> For me same has gone for C4D even 11.x.

I'm kind of confused about how you ended up with this moral.

What is it that you are trying to use the model for in your final rendering software that forces you to tweak the model?

If you are actually rendering it (which is quite frequently the thing that many people do when importing models into rendering programs), then no there should not be any kind of tweaking required at all, just import the model, then render it and that's it....

Just make sure that you are importing vertex normals, that's the key thing that makes a great looking rendering _without any additional tweaking_ !!

Here is a simple example with that same block model.

You load the model into MoI, it looks like this:



You save from MoI to OBJ format, the polygons generated look like this:



You then import the OBJ into Cinema4D, and without needing to do anything special, you just render it and it looks like this:



So note there that the amount of extra tweaking is none! For rendering, that should be the normal thing, it is not required to do any additional poly tweaking if you want to produce nice looking renderings from your model.

If you want to reduce jaggies in silhouettes or something like that, then you do that by tweaking the export settings from MoI, which will usually involve just moving the slider over to the right some more to generate a larger number of polygons.


> For me same has gone for C4D even 11.x.

Do you have any example model that you can post that you were having a problem with rendering in Cinema4D ? If you post it, I can help show you how to get it rendered nicely in Cinema4D without needing to actually mess around with tweaking any polygons in C4D.

- Michael

Hi FlashFire,

> it's probably something I look at more closely then most CAD users.

I think the problem is that you're so used to things working in the poly modeler by smoothing groups, that you mistakenly jump to the assumption that any kind of extra triangulation will cause some kind of shading glitches.

The part that you're not used to is that it's a completely different scenario when you get the good vertex normals to be used in the rendering.

When you get vertex normals that come from the original NURBS surfaces to be used in the rendering, it causes the shading to look the same as the NURBS surfaces instead of being controlled only by averaging between adjacent facets like with smoothing groups.


Here is a simple example - here I simply moved the density slider to the right when exporting out from MoI, and then imported and rendered the result in Cinema4D without any poly tweaking:



What area in particular do you think needs improvement? Which thing in the rendering are you looking at more closely than most CAD users?

- Michael

Actually yeah sometimes even in C4D 11.5 i've had to fix smoothing glitches. Some polys even had to be flipped and
points get welded to eliminate wasted polys. It's like you mentioned, it's never perfect.

But this 3DS Max test was to see if I could find a faster method for use in Max. Since getting the model out of
C4D into max looses the normals as you know. Granted this version is old. I wanted to show that it's not that
bad to repair for those that might not have software that will import normals. As you pointed out even some newer
software can't do properly.

Wanted to also point out Steve's slice method was useful.

What I look at with scrutiny is the underlying wireframe. Since models created in the past were for resale.
I've been testing to be sure the wireframe will look great in all poly software such as 3DS, C4D, LW, etc.

Hopefully my testing is helpful to someone here.

Hi FlashFire,

> Actually yeah sometimes even in C4D 11.5 i've had
> to fix smoothing glitches

That should not be a normal thing to have happen, and it may mean that you need to adjust some settings when you export the mesh from MoI.

For example something that is pretty big but only shallowly curved will not get a lot of polygons put on it when using the angle setting alone, so if you have something like that you may need to use the "Divide larger than" setting to force additional refinement when exporting the mesh.


> Some polys even had to be flipped and points get welded
> to eliminate wasted polys.

"wasted polys" doesn't have anything to do with getting a perfect looking rendering, just as long as the good vertex normals are being used.

If you had some polys that needed to be flipped, that may mean that you have some individual surfaces that were not joined to each other - make sure they are joined together so that they can have a single unified mesh created for them instead of having them meshed individually.


> It's like you mentioned, it's never perfect.

You should normally get a perfect render, just like the example I posted above.

If you have a model that does not produce a perfect render without tweaking any polygons, please post the model so that I can test it and give you some feedback on things you can do to make the rendering look perfect without needing to tweak any polygons in it at all.

It should never be needed to tweak polygons or do manual splitting up just in order to get a perfect looking rendering.

What I was referring to earlier with C4D n-gon problems is a very rare thing, and I've only seen it actually be an issue if you started to tweak the n-gon points around and even then only in some particular situations. I have not seen one yet where it was a problem just rendering it directly without trying to pull polygon points around.

- Michael

Hi FlashFire,

> What I look at with scrutiny is the underlying wireframe.

That does not have much to do with the appearance of the rendered output when the true vertex normals from the original NURBS surface are being used.

That's what is different from what you may be accustomed to with using regular poly modeling and smoothing groups to have the vertex normals created just by averaging the normals of adjacent polygons.

- Michael

Well I should clarify, since the problem I once had was with a joined model. It needed some points/edges to be
edited in C4D. I too was shocked to see this from software that imported normals.

Would you not agree that in many cases CAD models are not poly efficient models? They tend to use to many polys at times
to describe a shape that could otherwise be shown even in a high poly res with less polys "after human editing".
In those cases it's nice to import ngons and be able to dissolve unwanted edges or even whole rings/loops, to create a much more efficient
mesh. Even older versions of 3DS have more poly editing functions then C4D. Which is why I tested the model in MAX. There are
many modeling scripts available for 3DS as it's far more popular.

This is what I've been after that a human can do, create efficient topology. Not had much luck with auto topology programs.
And honestly think they are overkill/re-inventing the wheel, for a cad model. They seem best for organic things. I'll use mudbox.

I think I may have made you feel I was re-inventing the wheel, which is not what I intended.

But I'm sure as time goes on more efficiency will be seen. As a matter of fact, customers at Turbo-squid are now voicing there opinions
on the lack of some artists poly efficiency.

The 3DS max render you saw earlier in the post could pass as somewhat efficient. Deleting a few edge rings would make for
a cleaner mesh.

Crossing fingers that C4D 12 will add even more poly editing.

I think what confuses the issue is the way that C4D and other poly modellers treat NGons.

If you create an NGon directly in C4D, the internal triangulation of that NGon is a bit arbitrary, particularly if it is non-coplanar. The smoothing algorithm then tries to smooth across those triangles, sometimes creating artefacts. Incidentally, the same thing can happen with non-coplanar quads.

However, when you IMPORT an NGon with vertex normals, each vertex has it's own normal, and the internal smoothing algorithm is turned off, resulting in artefact free rendering. In Modo this is even more evident. Where vertex normals exist, changing the smoothing angle for a mesh has no effect at all.

@flashfire - I'm not sure I understand your point about the models being "poly inefficient". The number of polys you use, whether manually or created by something like MOI, is dependent on how you want curved surfaces to look, and this is determined primarily by the angle at poly edges. The smoothing algorithm (Phong and others) can only cope effectively with small angles. Once you go above those angles, smoothing artifacts appear. Also additional edge loops are needed to cope with any transitions from curved to flat surfaces, which are not needed when vertex normals are present. Using sub-d with a low poly cage, is not the same thing as the sub-d is adding polys back in.

Hi FlashFire,

> Well I should clarify, since the problem I once had
> was with a joined model. It needed some points/edges
> to be edited in C4D. I too was shocked to see this from
> software that imported normals.

Could you post the model, or e-mail it to me at moi@moi3d.com ? I will check it to make sure it is joined.

There are also other kinds of problems than joining that are possible, for example things like self intersecting surfaces can then produce polygon output that has polygons folded back over top of themselves as well.

If you post the model it would enable me to analyze it and better describe what was wrong with it and what you can do to avoid that. For example if you had a kind of curly-cue loop in one of the original curves you used in construction that will then create a self-folded surface from it as well.


> Would you not agree that in many cases CAD models
> are not poly efficient models?

Sure, but the part that I can't seem to get across is that does not have anything to do with the rendered appearance.

If your main goal is to produce a good looking rendering, having a supremely poly efficient model does not particularly help towards that goal (when the true vertex normals are being used of course).


> In those cases it's nice to import ngons and be able to
> dissolve unwanted edges or even whole rings/loops, to
> create a much more efficient mesh.

Why? Why do you go through all this effort when you can get a completely perfect looking rendering with the original model before doing all this extra work?

Once again here is the example model from earlier in this thread:



What is wrong with the rendering that makes you want to tweak the polygons? By tweaking, you're much more likely to actually introduce a worse quality rendering than what you've already got without any extra work. That's what's pretty baffling to me about what you seem to be trying to do...

Why do a bunch of work for a lower quality rendered result? If you edit the polygons you're never going to get as perfectly smooth of a render that looks completely identical to the original NURBS model as that rendering above does.

- Michael

Hi Steve,


Yup, this is absolutely correct - imported vertex normals completely take the place of any kind of "break angle" or "smoothing group" type smoothing mechanisms.

Those other kinds of mechanisms like a break angle method only work by averaging together the normals of all the faces that share a vertex, which can be affected by the polygon topology.

A rendering with imported vertex normals does not have shading affected by topology at all - the imported vertex normals completely define how the polygon is being shaded, neighboring polygons don't have any influence on it.

Additionally with CAD model imports, the vertex normals are very accurate because they come from the original CAD data. Things like a part with a sphere in it will have the exact vertex normal from the original sphere surface, etc... There's no way for something that cooks up normals just by averaging already faceted data to come up with the precise original normals like that.

- Michael

>>Additionally with CAD model imports, the vertex normals are very accurate because they come from the original CAD data. Things like a part with a sphere in it will have the exact vertex normal from the original sphere surface, etc... There's no way for something that cooks up normals just by averaging already faceted data to come up with the precise original normals like that.<<

What?

The problems with smoothing of exported meshes from "nurbs surface->mesh" exporters is due to the bad topology, mainly around the boundary's of joined curved surfaces. If you export a sphere from MOI then render it with vertex normal info or with smoothing, then you would have to guess which was which, as there is no difference due to poly flow. It is the same with the model I showed sliced up. If I render that with vertex normal info or smoothing, the results are the same.

What vertex normal info is good for, is hiding the bad topology/ bad poly flow output from the conversion.

Hi Steve (STEVE_HOME),

> The problems with smoothing of exported meshes from
> "nurbs surface->mesh" exporters is due to the bad topology,
> mainly around the boundary's of joined curved surfaces.

It's not quite so simple as "bad topology" - doing shading by automatically creating vertex normals is sensitive to many kinds of topologies like just a big polygon next to some small ones.

You get easily get shading glitches with models purely created within the polygon environment with smoothing groups and break angles unless you have very regularly sized and distributed polygons. That's not just "good topology", it's kind of "restricted topology".


> mainly around the boundary's of joined curved surfaces

Yeah, it's also due to issues like a change in shape happening at the boundaries as well.


> If you export a sphere from MOI then render it with
> vertex normal info or with smoothing, then you would
> have to guess which was which, as there is no difference
> due to poly flow

If you had something that was only one portion of it as a sphere and then it transitions to some other shape adjacent to it, like a fillet or something like that, that's when you won't get the same kind of exact normals for each piece automatically cooked up just from facets.

You're right that just within the middle part of a the sphere that automatically generated normals are ok, that happens to be in an area where the polygons are going to be all regularly sized and distributed.

- Michael

Hi Steve,

> What vertex normal info is good for, is hiding the bad
> topology/ bad poly flow output from the conversion.

This is not quite accurate - the vertex normal info doesn't just hide bad topology, it ensures that the rendering is shaded using the exact same shading from the original CAD model.

But yes this happens regardless of topology.

It's not just about diffuse shading, using the exact vertex normals also gives reflections that will be true to the original NURBS geometry.

Normals that are cooked up automatically by averaging of facets can often have things like shimmery or wavering reflections in areas of shape transition. The normal generation gets affected by the topology in that case, and it's quite difficult to get the perfect polygon topology on many areas of transition.


> It is the same with the model I showed sliced up. If I render
> that with vertex normal info or smoothing, the results are
> the same.

Possibly not if you look at reflections in some areas where you've got some elongated diamond shape quads. Did you ever post any model file of the cut up version? If you can post that I'll see if I can find an area that shows a difference in reflections.

- Michael