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

Hi Steve (STEVE_HOME), here's an example of the kind of thing that I'm talking about re: spheres - here I have taken the original block and cut some sphere pieces out of it and have some fillets and another cut as well. Not a whole lot of stuff but it looks like this now:



Rendering this with exported vertex normals will render all those sphere pieces as perfect spheres, including absolutely no wavering in the reflections.

Good luck trying to create a polygon topology that recreates the same level of crispness in the reflection in the boundary areas... The problem gets more and more difficult when the boundaries become even more irregular like with a some more trims cut out or little holes in the middle of larger faces, stuff like that.

Particularly when you have a mixture of little features like a little hole or notch next to broader surfaces, it becomes quite difficult to get an evenly spaced and sized polygon topology to go on such things. And any kind of unevenness in the polygon topology will affect automatically created vertex normals done by averaging facet normals.

- Michael

Hi Michael,

>>Good luck trying to create a polygon topology that recreates the same level of crispness in the reflection in the boundary areas...<<

Interesting little challenge. I will have a bit of spare time later, so will see what the results look like.


- Steve

If you try to do that with poly modelling and automatic smoothing normals, you are going to have to put a small ring of polygons to protect each flat surface as it transitions to a curved surface or you will get artefacts on the flat surface. In Modo, you would do a small inner bevel on each flat surface to do this or a loop slice. However this model is quite complex and I think you will struggle.

Hi Steve (SteveMacc),

> However this model is quite complex and I think you will struggle.

And even though the model is difficult to handle for that kind of task, it's not really that complex of a model itself overall. For example it only took me something like a minute to create it.

The other kind of thing that tends to be difficult to apply a quad-only topology to is when there are some holes bored through things, particularly when the holes are of different sizes or are nearby each other or nearby boundary edges. When that happens the technique of adding a ring around each feature edge is hard to maintain because the rings are colliding with each other too rapidly.

- Michael

Hi Michael,

>>The other kind of thing that tends to be difficult to apply a quad-only topology<<

So you want my example to be only quads,... OK, I will do that if you can output a mesh of this model from MOI with no tri`s


- Steve

Hi Steve,

> So you want my example to be only quads,...

Do whatever you wish with your example - your previous one that you posted here: http://moi3d.com/forum/index.php?webtag=MOI&msg=3869.48 seemed to be constructed with all quads, so I thought that was what you were going for.

But if you produce one with triangles in it I wonder if you will consider it to be a "bad topology" yourself though?

- Michael

Hi Michael,

To me, tris would only be classed as bad topology if they where isolated, surrounded by quads/terminating at edges forcing bad flow. In the model where you have cut partial spheres, then you have poles, yes, the poles can be terminated with quads, but the quads would need to be extremely small due to you wanting correct reflection rather than just stopping rendering artefacts.

As I do not haver a lot of spare time, I will just make a section of the model from quads.

Does that mean you will not be making a mesh output from MOI with no tris? :)


- Steve

Hi Steve,

> Does that mean you will not be making a mesh
> output from MOI with no tris? :)

Well, I'd like to but it probably won't be happening anytime too soon... I've looked into various techniques for possibly doing that, and it would be possible to make something that worked ok for some simple kinds of cases but very difficult to make one that would be very robust.

- Michael

Hi Steve,

> due to you wanting correct reflection rather than
> just stopping rendering artefacts.

A reflection that looks wavery and jittery _is_ a type of rendering artifact. But of course you won't notice it if you do a rendering without any reflection in it.

Reflection tends to substantially amplify any problems like little wiggles in geometry or irregularity in normals.

It's just another area that you don't have to worry about if you render with the NURBS vertex normals being used.

- Michael