Slime <slm### [at] slimelandcom> wrote:
>>   Yes, it would be difficult with the current implementation. I have
> looked
>> at the code myself.

> Oh, alright. =)

> I can't wait until the source comes out for 3.5...

  Of course "difficult" is not the same as "impossible".
  It should be possible to achieve the desired effect by making some ugly
hack. When I looked at the code I tried to find a clean and nice way of
doing it, but due to the structure of the code I didn't find any.

  One ugly hack would be making the triangle, mesh and heightfield objects
to write a flag to a global variable (forgive me for swearing in public)
stating that the normal they returned was not the true normal. The
normal-inverting code would first look at this flag, and if the flag states
that the normal was perturbed by the object itself and probably isn't the
true normal, then the code would request the true normal from the object.
Then it would make the decision whether to invert the first normal or not
according to the true normal.
  This of course causes a slight overhead in the rendering of these objects
as they will now have to return two normal vectors instead of one, but this
overhead might be irrelevant.
  Fortunately the "return the true normal" function would have to be
implemented only for these three objects, saving a lot of writing work,
I think.

-- 
#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