Looking at the code and testing a bit it's now extremely clear why this
artifact happens. It's not a bug, it's just a side-effect of normal
perturbation in smooth triangles.

  One possible solution is to invert the normal if the angle between the
incoming ray and the unmodified triangle normal is <90 and the angle between
the modified normal and the incoming ray is >90, or the other way around.
That is, for example in the heighfield function which returns the normal
vector for a certain point, in the block where it is calculated for a smooth
heightfield, something like this is done:

  if(dotProduct(incomingRay,unmodifiedNormal)*dotProduct(incomingRay,Result)<0)
    invert(Result);

  The effect of this is that when the problematic case happens, the normal
is inverted inside the heightfield code. Then it's inverted again at the upper
level, thus nullifying the inversion.

  However, there's one big problem here: As far as I can see, the normal
calculation function has no access to the incoming ray.
  Any ideas?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message