Anthony, the bigger problem is not lighting, it's texturing. That has little to do with normals, and everything to do with reduced precision math. Let me walk you through a typical 3d rendering, and you might see what I'm talking about. Let's do lighting first, though, since you seem to have some understanding of that. Assume the model has already been broken down into triangles. One "face normal" is calculated for each face. Now, for a "reasonable" triangle, one with no particularly sharp points (say no angle sharper than 10 degrees or so) you can take the verticies in pretty much any order and get a fairly accurate normal. But if one angle is very sharp, then two of the edges start to look like parallel lines. If you pick those two edges, all the dynamic range of the floating point calculations is used up dealing with the small angle, and there is a rather annoying amount of error in the normal. Now, you're right, for the vertex in the center of the big polygon, there are 64 face normals being averaged, so the errors tend to average out. For the 32 sided polygon, you're still dangerously close to being "too sharp". This depends on what you're doing the rendering on, of course. If you're doing everything in double precision (100 bit or more) floating point, you're probably fine. If you're doing it on a reduced precision math system (like the Poser renderere, or a hardware graphics accelerator) you're going to get artifacts. OK, so now you've got one reasonably good vertex in the center. There are still 64 around the edge to deal with. And each of those verticies gets its vertex normal calculated from just two face normals. So there's little hope the error averages out. Actually, the law of averages says 1/2 will have "destructive interferanc" and be left with less error. The other half will actually contribute to each other's errors. So the edge normals can be rather "wavey". Which is definitely going to show up in your lighting calculations. Remember, we're talking production rendering, not "game rendering", where we do such silly things as use vector quantizers on the normals to save memory. At least for the 512 face "original" these screwey normals are confined to a relatively small area of the center of the end cap. Now, as far as texturing. Most graphic toolkits have a variety of mapping modes. Cubic, cylindrical, cylindrical with end caps, spherical, etc. Since the object IS a cylinder with end caps, it makes sense to use that mapping mode. So each skinny pie wedge of the end cap maps to a skinny pie wedge of the texture map. Now, texture maps are low resolution, integer coordinate systems. Ad as we get close to the pointy edge of a triangle, it's very easy for the integer math to end up a whole pixel off. Even with texture interpolating filters, these errors are enough so that the edges of the texture wedges do not match up, giving rise to the classic "spider web" artifacts. One cure is to increase the integer precision. This means increasing the size of the texture map, to minimize the effect of a one pixel error in texturing. Of course, if you're worried about memory utilization in your model sizes, think of what kind of trouble you're going to get into by increasing texture map sizes. The tessilation I mentioned (which is a real tessilation, in use in my own graphics applications, today, and probably other peoples, since it's such a basic concept I can't believe I'm the first to "invent" it) only has 2 or 3 times the polygon count of yours for practical sized objects, yet will render with no texture or lighting artifacts, and works very well with any type of mesh deformer you care to throw at it. I hope I'm not misassessing your level of knowledge of these subjects, but you seem to be a relative beginner in 3D programming. Would you like me to recommend a couple of good books or places where you can dig for some information on the basics?