Hi Chipp,

> 3. I always use the Output: to Triangles only UNLESS Michael tells me quads are ALWAYS coplanar ;-)

Quads on curved surfaces will typically not be coplanar. But usually most rendering programs can handle nonplanar quads by simply splitting them into 2 triangles at render time. It's an easy job to triangulate a quad, it's much more difficult to triangulate a complex n-gon with possibly hundreds of vertices and complex concavities in it. So if your rendering program has not invested a lot of effort in making robust n-gon triangulation you want to avoid n-gons but it's not very typical to need to avoid quads.


> Michael, do you set the smoothing on OBJ polys based on the Angle setting or do you just smooth all polys?

MoI's OBJ export uses vertex normals to control all the smoothing - each polygon gets vertex normals emitted in the OBJ file at its vertices and the normals come from the original NURBS surface data, so the shading will look the same as the original NURBS model.

A "break angle" type mechanism is only used for smooth shading when vertex normals are being created by averaging the face normals of adjacent polygon faces. That does not apply for MoI's case since MoI can get the normals from the original NURBS surface rather than from any polygon face averaging process.

So the angle setting controls just the density of the tessellation, it doesn't control whether smooth shading will happen or not, you will just get creases at areas where your original NURBS model is actually creased and smooth junctures where your original model is smooth.

- Michael

I would say that is pretty much spot on Chip, much more elegant than what i said in the previous thread. The only thing i would add (if that's ok ?) is that if you have close-up shots to do then export those parts as seperate polygon files with higher density settings, you can then import them into Keyshot and hide/show the low/high density mesh objects as and when needed.

It's a good how to though Chip :)

Martin Spencer-Ford

Michael,

Since Keyshot never shows triangles, then I suspect the only chance I get to see what the mesh looks like is your preview-- so I'll keep on exporting TRIs.

Pretty cool about the normals. I understand what you're saying is that because you have the ACTUAL representation of the surface (and not a fake poly rep), then you can easily calculate the exact normals on export. To test I went ahead and made a very simple model which would give Keyshot fits if exported from Lightwave (or other poly modeler) if not set up correctly with smoothing angles.

1. The model in MoI
2. The export tesselation.
3. The rendering in Keyshot. Works great!!!



Martin,

Yes, you are mostly correct about close up shots. But I don't believe even in extreme closeups you need a higher Divide larger than density on surfaces, only a smaller Angle setting (move slider farther right). Michael, am I correct in assuming you will subdivide accurately a curved surface at an even higher angular density (lower angle) if the Divide larger than setting requires it?

Assuming the definition of curve vs plane is geometric and not determined by the Angle setting.

So, even if you have an angle setting of 8, a Divide larger than setting which subdivides a mesh across a surface (curve) which has an angle of 4 degrees will still get subdivided. Is this the correct understanding?

Hi Chipp,

> I understand what you're saying is that because you have the ACTUAL representation of the surface
> (and not a fake poly rep), then you can easily calculate the exact normals on export.

Yup, that's exactly right - that can be one of the advantages of NURBS modeling, that you basically have an underlying master accurate version of the object that can be used as a reference for various calculations. It especially helps when there are things like exact spheres or cylinders involved in the model.

The shading working in this way can help in other cases too like generating rough low polygon versions of objects, even rough polygons tend to shade nicely since the shading comes from the accurate original surface and not just averaged between polygons that are themselves approximations.


> Michael, am I correct in assuming you will subdivide accurately a curved surface at an even
> higher angular density (lower angle) if the Divide larger than setting requires it?

Yup, that's correct - "Divide larger than" can be used to force further subdivisions than what the angle parameter would do by itself.

Just one thing to note is the drop-down on the right side of "Divide larger than" plays a role too, it controls whether that will be applied to just curved surfaces, or whether it will be applied to all surfaces.

Using "Divide larger than" can especially help for shapes that are fairly wide but only very shallowly curved, often times if the shape has a big yet very shallow curvature it tends to require a very tight angle to get a lot of subdivisions on it, that's when the distance based "Divide larger than" can be used to chop things up additionally.

- Michael

The values I use on the export dialogue are entirely dynamic, based off the model I'm meshing...

The meshing angle is used first to approximate the density. The divide larger than and avoid smaller than are then manipulated together to attempt to produce the "most uniform mesh"......

The values entered in the divide and avoid fields are based entirely on the size of the object being meshed.....

then Poly count goals are looked at. The mesh angle is adjusted then the divide and avoid values adjusted again, until uniform and poly count goals are acceptable....

Hi Chip

** Since Keyshot never shows triangles, then I suspect the only chance I get to see what the mesh looks like is your preview-- so I'll keep on exporting TRIs. **

If you check the Miscellaneous materials there are two wireframe materials in there so you can view the underlying mesh. Keyshots meshing only generates triangles so even if it was fed quads it wouldn't make any difference, and KS has a sissy fit with N-Gons or did with v3 which is when i last tested it with them.

Martin Spencer-Ford