sascha wrote:
> When using the 'fresnel' keyword in reflections, Linux (Redhat 7.3) and 
> Windows (2000) versions of POV-Ray produce different output!
> This phenomenon caused a strange flickering in an animation rendered on 
> the IMP render-farm (which uses clients with different OS), after some 
> experimentation I discovered that it is caused by the fresnel reflection.
> I wrote a short scene to demonstrate the effect. An image showing both 
> outputs was posted to p.b.images (fresnel.jpg).
> For me the windows output looks "right". Any ideas what could case this 
> effect (a bug in the linux version?), or is something wrong with my 
> material definition?
> Is there a "workaround"?

To me the linux version seems right, it reflects the black background at 
  areas where the reflection coefficient is high.  But in fact if i 
should guess i'd say neither is correct.

The difference is most likely caused by a math function being called 
with parameters out of the allowed range.  Math libraries of Linux and 
Windows handle this differently.


Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 12 Nov 2003 17:03:10 +0100, sascha <sas### [at] userssourceforgenet>
wrote:
> Yes, but in this case the windows version shoots reflected rays where the linux
version does not

Somehow I missed 'fresnel' keyword, sorry. In case of 'fresnel' there was a
problem related to equation I also found. This is a line:

  g = sqrt(Sqr(ior) + Sqr(cos_angle) - 1);

in lighting.cpp (in determine_reflectivity()). For some cases (also official
benchmark) it caused evaluation of sqrt for negative values. Depending on
compiler it could behave different.

And this is _not_ fixed yet. Any ideas would be appreciated for sure.

ABX

Post a reply to this message

> POV-Ray for Windows: Version 3.5.icl.win32
> POV-Ray for Linux: Version 3.5 Unix (.Linux.gcc)

	I quickly tested your script with the current developmental version
of POV-Ray under Linux (compiled with gcc 3.3.1) and obtain the exact same
statistics as your windows binary compiled with icl:


Image Resolution 384 x 216
----------------------------------------------------------------------------
Pixels:            82944   Samples:           82944   Smpls/Pxl: 1.00
Rays:             917012   Saved:            223932   Max Level: 8/8
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Cone/Cylinder                  2972274         1354663     45.58
CSG Intersection               1486137          841641     56.63
Plane                          1486137          432504     29.10
----------------------------------------------------------------------------
Calls to Noise:                   0   Calls to DNoise:              10
----------------------------------------------------------------------------
Shadow Ray Tests:           1638610   Succeeded:                416873
Reflected Rays:              424768   Total Internal:            15468
Refracted Rays:              409300
----------------------------------------------------------------------------


	and the image looks like that you obtain under windows. On the other
hand, using a custom compile of 3.50c (with a gcc version I don't remember)
gives the same "wrong" image but with different statistics. I can't tell
whether it means gcc is the reason of these discrepancies. But at the end,
it seems that the next version of povray should give consistent results
between platforms  :-)  [well, the last post of ABX seems to pretend the
opposite though...]

	- NC

Post a reply to this message

ABX wrote:
>On Wed, 12 Nov 2003 17:03:10 +0100, sascha <sas### [at] userssourceforgenet>
>wrote:
>Somehow I missed 'fresnel' keyword, sorry. In case of 'fresnel' there was a
>problem related to equation I also found. This is a line:
>
>  g = sqrt(Sqr(ior) + Sqr(cos_angle) - 1);
>
>in lighting.cpp (in determine_reflectivity()). For some cases (also official
>benchmark) it caused evaluation of sqrt for negative values. Depending on
>compiler it could behave different.
>
>And this is _not_ fixed yet. Any ideas would be appreciated for sure.
>
>ABX
>

That line appears to be calculating the cosine of the angle of refraction
from the cosine of the angle of incidence - you can derive the expression by
writing Snell's law of refraction in terms of cosines. Negative values in
that sqrt will correspond to total internal reflection, I think. I don't see
a simple solution (unless you trap internally reflected rays somewhere
already?)

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:

>   g = sqrt(Sqr(ior) + Sqr(cos_angle) - 1);

That is cos(beta).

So if ior^2+cos_angle^2-1 < 0 total interreflection should occur.
But just setting F=1 would perhaps be the wrong solution (though it 
would still be much better than the current situation), since
that would still be clipped to [reflectionmin, reflectionmax].
There are some other references to total interreflection in that file so 
maybe this case is _supposed_ to be caught earlier?

Lutz-Peter

Post a reply to this message

Lutz-Peter Hooge wrote:

>But just setting F=1 would perhaps be the wrong solution (though it
>would still be much better than the current situation), since
>that would still be clipped to [reflectionmin, reflectionmax].
>There are some other references to total interreflection in that file so
>maybe this case is _supposed_ to be caught earlier?

TIR certainly is caught (detected in Refract_Guts() and flagged by return
value through Refract() and BackTraceRefract()) and the proper arrangements
made for reflected rays in compute_backtrace_texture() and
compute_lighted_texture(). However, determine_reflectivity() is called
before all this in both of the compute_*_texture functions, so the
information isn't yet available when determine_reflectivity is called and
the Fresnel calculations made.

I have no idea what the best solution would be. Is it such a bad idea to
obey the user-specified reflection_min/max even in the case of TIR?

Post a reply to this message

Tom York <tom### [at] compsocmanacuk> wrote:

> I have no idea what the best solution would be. Is it such a bad idea to
> obey the user-specified reflection_min/max even in the case of TIR?

After thinking about it, it is probably the best thing to do.
While it is not realistic to do so, it is also not realistic to use
reflection_min/max other then 0/1 for fresnel reflectivity, so the user 
specifically asked for it...

Btw, IMHO the docs should mention that for realistic reflection, the 
fresnel keyword should be used together with reflection_min/max of 0/1.
For someone who doesn't the fresnel function and/or it's implementation
in POV this isn't obvious.

Lutz-Peter

Post a reply to this message

In article <web.3fb90bc3df2bb6e4541c87100@news.povray.org>,
 "Tom York" <tom### [at] compsocmanacuk> wrote:

> I have no idea what the best solution would be. Is it such a bad idea to
> obey the user-specified reflection_min/max even in the case of TIR?

Well, there's a reason it's called *total* internal reflection...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <web.3fb90bc3df2bb6e4541c87100[at]news.povray.org>,
> "Tom York" <tom### [at] compsocmanacuk> wrote:
>
>> I have no idea what the best solution would be. Is it such a bad idea to
>> obey the user-specified reflection_min/max even in the case of TIR?
>
>Well, there's a reason it's called *total* internal reflection...
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>

Then surely the extinction keyword should never be allowed to take a value
other than unity, and the conserve_energy feature should always be on, and
reflection_min should always be forced to take a value less than
reflection_max ...

I understand that 100% reflection would be the physically correct value, and
I'm sure that there is a good argument for making it independent of
reflection_max, but I'm just not sure that physical correctness is that
argument - it could be taken to apply a lot more widely than it does.

Post a reply to this message

I altered lighting.cpp so that the sign of the sqrt is checked before use.
If it is negative, F is set to 1 (leading to Reflection_Max). Otherwise the
behaviour is unchanged. I ran the scene provided by sascha with the same
width and height and got this:

http://www.compsoc.man.ac.uk/~tomy/pov/tir.jpg

(~3K JPEG).

This was on a linux PC, gcc 2.95.3. The edges (where TIR is undoubtably
occurring) seem a bit cleaner to me.

Post a reply to this message