This is the same problem I noticed some time ago. It also happens with
smooth heightfields for the exact same reason.

  The problem is that the rendering engine assumes that objects return
the *true* normal vector for the given point in their surface. For an object
to render correctly, it *must* give the exact normal vector (ie. a vector
which is exactly perpendicular to the surface at that point).
  Smooth meshes and heightfields don't do this. They return normal vectors
which are not perpendicular to the actual surface. This causes errors in the
rendering.

  What happens is that when the rendering engine shoots a ray and it hits
the surface of an object, the engine asks the object "what's the normal vector
at this point in your surface?".
  Now, if the angle between the returned normal vector and the ray vector
is less than 90 degrees (that is, the normal vector points away from the
point of view of the starting point of the ray), then the engine reverses
the returned normal vector. This is essential for the lighting to work
properly (if the normal is not reversed in this case, you would get all kind
of errors in lighting, ie. surfaces which are illuminated from behind when
they shouldn't, or surface which are not illuminated even though they are
facing a light source).
  This assumes that the normal vector returned by the object is a *true*
normal vector, and it works perfectly when this is so.
  However, if the object returns an erroneous normal vector, ie. a vector
which is not perpendicular to the surface, rendering errors can occur.
  Smooth triangles and heightfields do this, and the price to pay are the
artifacts in the lighting in certain situations.

  The artifact is produced when the *true* normal vector would have an angle
larger than 90 degrees with the ray, but the the actual vector returned by
the object has an angle smaller than 90 degrees with the ray.
  In this case the rendering engine reverses the normal vector even though
it shouldn't. This is because it assumes that it's the true normal vector
when in fact it isn't.

  You can get rid of the artifacts by making the mesh double_illuminated.
When a surface is double_illuminated, it doesn't matter which way its normal
points - it will always be illuminated regardless of which side the light
source is.
  Of course it shouldn't matter that the mesh is now illuminated in both
sides. If this is a problem, then there's little we can do.

  Another place where this problem can be seen is when using the slope pattern,
which also uses the normal vector to calculate the value of the pattern at
a certain point. If the normal is reversed when it shouldn't, the wrong
slope is calculated as well. double_illuminate will not fix this because it
is only related to lighting, not to patterns.
  If you are having this problem in a smooth heightfield, the solution is
to mirror the color_map (or whatever map you are using) around 0.5. This way
it doesn't matter if the normal is reversed.

  Perhaps I should add this text to the povQandA.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message