POV-Ray : Newsgroups : povray.bugreports : Reflection bug? Server Time
31 Oct 2024 21:26:43 EDT (-0400)
  Reflection bug? (Message 1 to 8 of 8)  
From: Markus Becker
Subject: Reflection bug?
Date: 27 Nov 1998 06:23:58
Message: <365E8CBF.741436D3@zess.uni-siegen.de>
Hello,

here's another one that someone postet over there on c.g.r.r:

The following scene consists of an opaque, reflective plane with
a normal applied to it. The underlying plane with a checker
pigment seems to come through the upper plane.

camera { location <-1,20,-20> look_at <0,12,0> }

light_source {
  <300,500,100>
  color rgb <1,1,1>
}

background { color rgb <0,1,0> }

plane {
  y, 0
  texture {
    pigment { color rgb<.5,.5,.5> }
    normal { wood 0.5 scale 10 }
    finish { reflection 1}
  }
}

plane{
  y,-1
  texture {
    pigment {
      checker
        color rgb<1,0,0>
        color rgb<0,1,0>
      }
    scale 10
  }
  finish { ambient 1 }
}

//----------------- cut here ----------------------


Markus


Post a reply to this message

From: Nathan Kopp
Subject: Re: Reflection bug?
Date: 29 Nov 1998 19:29:18
Message: <3661E5BE.1F6120DC@Kopp.com>
I was able to produce a fix for this bug.  I submit it here to the
POV-Ray team.  If you'd like a copy of my LIGHTING.C file, just let
me know and I'll send it.

-Nathan Kopp

=================

The cause of the bug is kind of tricky.  Imagine a bumpy surface:
        _______
       /       \
       |       |  <--- these don't have to be exactly vertical
______/         \________     (object X)

In POV, the faked bump really looks like this:

______/|/_____\|\________     (object Y)
       A       B

Reflecting rays don't have much of a problem unless they hit the
parts where the slope is almost perpendicular to un-perturbed normal
(for example, points A or B).  In this case, if you have a faked
normal, rays coming straight down towards the object just "fall
through the cracks."  In real life, they would really get reflected
two (or more) times:

__    ray in
##\  /
##| /
##|/     ray out (if the surface was shaped like this)
##|\    /
##| \  /
###\_\/_______
##############
##############

With a faked normal, you don't get the second intersection:

      ray in
     /
    /
__\|\________
    \
     \
      \ ray out


So here's how I fixed it.  The bug occurs when the direction of the
reflection ray is going the opposite direction of the non-perturbed (raw)
normal.  (Note that this version of the raw normal has been flipped to point
towards the camera.)

So when this situation arises, I reflect the ray's direction across
the non-perturbed surface of the object.

===============

Here are the changes (all are in LIGHTING.C):
These changes HAVE been tested. (Of course, only to a limited extent.)

First, I fixed some redundant and buggy code in compute_lighted_texture()
The code
------------------
  /* If the surface normal points away, flip its direction. */
  VDot(Normal_Direction, RawNormal, Ray->Direction);
  if (Normal_Direction > 0.0)
  {
    VScaleEq(RawNormal, -1.0);
  }
------------------
appears in some radiosity-related stuff at the beginning of the funciton,
and then again (in a slightly different form) when the normals are being
perturbed.  I simply consolidated this code and moved it to the beginning
of the function (outside of all if statements) so that it always gets
executed.

Now that I was sure that RawNormal had been properly flipped in all
situations, I added a vector parameter "Raw_Normal" to both Reflect()
and Refract(), passed the "RawNormal" variable to it.  When Refract()
calls Reflect(), it just passes on the same "Raw_Normal" that it recieved.

Then, right after the line
------------------
  VLinComb2(NRay.Direction, n, Normal, 1.0, Ray->Direction);
------------------
in Reflect(), I added:
------------------
  /* NK 1998 - Reflection bugfix
    if the new ray is going the same direction as raw normal, we
    reflect it across the un-perturbed surface. */
  VDot(NRay_Direction, NRay.Direction, Raw_Normal);
  if (NRay_Direction < 0.0)
  {
    /* subtract twice the projection of NRay.Direction onto Raw_Normal
       from Raw_Normal */
    DBL Proj;
    Proj = NRay_Direction * -2;
    VAddScaledEq(NRay.Direction, Proj, Raw_Normal);
  }
  /* NK ---- */
------------------

This should fix the problem, and should not cause any un-wanted side
effects.  Of course, it needs further testing.

-Nathan Kopp


Markus Becker wrote:
> 
> Hello,
> 
> here's another one that someone postet over there on c.g.r.r:
> 
> The following scene consists of an opaque, reflective plane with
> a normal applied to it. The underlying plane with a checker
> pigment seems to come through the upper plane.
> 
> camera { location <-1,20,-20> look_at <0,12,0> }
> 
> light_source {
>   <300,500,100>
>   color rgb <1,1,1>
> }
> 
> background { color rgb <0,1,0> }
> 
> plane {
>   y, 0
>   texture {
>     pigment { color rgb<.5,.5,.5> }
>     normal { wood 0.5 scale 10 }
>     finish { reflection 1}
>   }
> }
> 
> plane{
>   y,-1
>   texture {
>     pigment {
>       checker
>         color rgb<1,0,0>
>         color rgb<0,1,0>
>       }
>     scale 10
>   }
>   finish { ambient 1 }
> }
> 
> //----------------- cut here ----------------------
> 
> Markus


Post a reply to this message

From: Nathan Kopp
Subject: Re: Reflection bug?
Date: 29 Nov 1998 20:02:37
Message: <3661ED8D.17A334EE@Kopp.com>
>     /* subtract twice the projection of NRay.Direction onto Raw_Normal
>        from Raw_Normal */

This comment should be:

     /* subtract twice the projection of NRay.Direction onto Raw_Normal
        from NRay.Direction */

-Nathan Kopp


Post a reply to this message

From: Nathan Kopp
Subject: Re: Reflection bug?
Date: 1 Dec 1998 11:10:30
Message: <366413CF.67C36788@Kopp.com>
I posted a modified version of this code which (makes the bug obvious) in the
povray.text.scene-files group. Rendered images from that file can be found in
povray.binaries.images.

-Nathan


Post a reply to this message

From: =Bob
Subject: Re: Reflection bug? (fix?)
Date: 1 Dec 1998 17:53:53
Message: <36647381.0@news.povray.org>
Say, uh, Nathan?
You may not like what I'm about to say after all the work you've put into that 
reflection bug-fix there, but... well, um, you see it's like this.
If the 'inverse' keyword is put at the end of a texture statement containing a 
reflection finish, there is no problem. The reflection works as it should, 
same as what your fixed code does apparently.
I knew there was something amiss about this thing too though after someone 
(Buk### [at] aolcom) mentioned "missing" reflection when 3.1 was being beta'd.
I don't understand why it would work this way. Seems obvious the correct way 
would be *without* the keyword inverse, and used if you wanted a change from 
default. Sounds about right huh?
So, maybe it should still be called a bug of sorts.

Message <366413CF.67C36788@Kopp.com>, Nathan Kopp  typed...
>
>I posted a modified version of this code which (makes the bug obvious) in the
>povray.text.scene-files group. Rendered images from that file can be found in
>povray.binaries.images.
>
>-Nathan

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.html
=Bob


Post a reply to this message

From: Nathan Kopp
Subject: Re: Reflection bug? (fix?)
Date: 1 Dec 1998 23:00:57
Message: <3664BA3F.DC68E210@Kopp.com>
The inverse keyword does seem to make a difference, but it doesn't fix the
problem.  I assume that you mean 'inverse' in the object (it is a syntax error
if you put it inside the finish or inside the texture).  Also, on a plane,
inverse has the same effect as switching the direction of the normal vector.

Go grab my test scene (in the povray.text.scene-files group) and render it. 
Then add 'inverse' to the plane.  The problem is still there.  At least it was
on my machine. Actually, 'inverse' has a really weird effect that I didn't
expect... maybe I'll look into that...

Thanks for telling me about the 'inverse' keyword, though.  Even if it had made
my bugfix null & void, it would be good to know!  :-)

-Nathan Kopp


Post a reply to this message

From: =Bob
Subject: Re: Reflection bug? (fix?)
Date: 2 Dec 1998 01:17:00
Message: <3664db5c.0@news.povray.org>
Just looked again. Yep, right about the inverse, I could have sworn I had it 
working within texture{}, turns out I had failed at putting it elsewhere 
(finish{} etc.) and thought I succeeded at putting it there in texture. I 
mistakenly read the braces of course.
I've looked at reflecting planes more and found a "wrong look" to the thing, 
partly mirrored and partly not at all, about like your test images but it has 
to do with filter or transmit and if they're used or not.
I was trying ior and it makes a lot of difference in the look, however, it 
comes down to the fact that reflection fades with increasing transparency. A 
known fact of the sort that causes 'finish' to fade away until none exists if 
filter or transmit is 1, otherwise no "invisible" container objects could be 
made since default diffuse, etc. would prevent them from being possible. 
Except that reflection does not allow 100% disappearence in case of 100% 
transparency, and refraction makes it all look further intertwined.
All in all I think the reflection_exponent is something to look into. You can 
set it to zero and get a transparency-based reflection it seems unless 
refraction is on, instead of the other way around (whatever).

I'm going to get your test file and try it too, btw.

So anyway, to review:

 filter [0...1] and/or transmit [0...1]
 reflection [0..1] and/or reflection_exponent [0..1]
 ior [1...?]
 inverse (or not)

These all seem to be doing a strange thing together; like I even need to say 
that.

Message <3664BA3F.DC68E210@Kopp.com>, Nathan Kopp  typed...
>
>The inverse keyword does seem to make a difference, but it doesn't fix the
>problem.  I assume that you mean 'inverse' in the object (it is a syntax 
error
>if you put it inside the finish or inside the texture).  Also, on a plane,
>inverse has the same effect as switching the direction of the normal vector.
>
>Go grab my test scene (in the povray.text.scene-files group) and render it. 
>Then add 'inverse' to the plane.  The problem is still there.  At least it 
was
>on my machine. Actually, 'inverse' has a really weird effect that I didn't
>expect... maybe I'll look into that...
>
>Thanks for telling me about the 'inverse' keyword, though.  Even if it had 
made
>my bugfix null & void, it would be good to know!  :-)
>
>-Nathan Kopp

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.html
=Bob


Post a reply to this message

From: Nathan Kopp
Subject: Re: Reflection bug? (fix?)
Date: 2 Dec 1998 22:57:28
Message: <36660AEA.A475745C@Kopp.com>
Nathan Kopp wrote:
>
> on my machine. Actually, 'inverse' has a really weird effect that I didn't
> expect... maybe I'll look into that...
>

I take this comment back.  ;-)  I should have expected the 'weird effect'.
It is simply total-internal-reflection.

-Nathan Kopp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.