 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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"?
POV-Ray for Windows: Version 3.5.icl.win32
POV-Ray for Linux: Version 3.5 Unix (.Linux.gcc)
Looking at the statiscics shows that different numbers of rays were
reflected/refracted (see below).
Ok, here's the test-scene, I've rendered it with "povray -F +D +P +H216 +W384
test.pov" on both machines.
/*-------------------------------------start----------------------------------*/
global_settings {
max_trace_level 8
}
#local glass = material {
texture {
pigment { transmit 1 }
finish {
specular 10 roughness 0.001
conserve_energy
reflection { 1 fresnel }
}
}
interior {
ior 1.5
caustics 5
fade_distance 1
fade_power 2
}
}
camera {
location <0,0,-15>
look_at <0,0,0>
up y
right x * 16/9
}
light_source {
<-100,100,-100>
color rgb 1
}
difference {
cylinder { <0,-5,0>,<0,5,0>,5.5 }
cylinder { <0,-5,0>,<0,5,0>,5 }
material { glass }
}
plane {
-z,-10
pigment { color rgb 1 }
finish { ambient 0.5 diffuse 0.5 }
}
/*-------------------------------------end----------------------------------*/
Statistics from linux version:
==============================
Statistics for test.pov, Resolution 384 x 216
----------------------------------------------------------------------------
Pixels: 82944 Samples: 82944 Smpls/Pxl: 1.00
Rays: 855752 Saved: 213640 Max Level: 8/8
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Cone/Cylinder 2757604 1257284 45.59
CSG Intersection 1378802 777524 56.39
Plane 1378802 391676 28.41
----------------------------------------------------------------------------
Calls to Noise: 0 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 1515460 Succeeded: 384732
Reflected Rays: 386404
Refracted Rays: 386404
----------------------------------------------------------------------------
Smallest Alloc: 14 bytes Largest: 12296
Peak memory used: 155640 bytes
----------------------------------------------------------------------------
Time For Trace: 0 hours 0 minutes 11.0 seconds (10 seconds)
Total Time: 0 hours 0 minutes 10.0 seconds (10 seconds)
Statistics from windows version:
==============================
Statistics for F:\test\test.pov, 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
----------------------------------------------------------------------------
Smallest Alloc: 25 bytes Largest: 12056
Peak memory used: 153837 bytes
----------------------------------------------------------------------------
Time For Trace: 0 hours 0 minutes 7.0 seconds (7 seconds)
Total Time: 0 hours 0 minutes 7.0 seconds (7 seconds)
----------------------------------------------------------------------------
CPU time used: kernel 0.08 seconds, user 6.87 seconds, total 6.95 seconds
Render averaged 11934.40 PPS over 82944 pixels
POV-Ray finished
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 12 Nov 2003 16:34:21 +0100, sascha <sas### [at] users sourceforgenet>
wrote:
> reflections ... produce different output!
>
> POV-Ray for Windows: Version 3.5.icl.win32
> POV-Ray for Linux: Version 3.5 Unix (.Linux.gcc)
Well, icl is not gcc. Intel compiler could utilize dedicated CPU/FPU commands
related to single floats used as color components which determine
reflection/refraction.
ABX
Post a reply to this message
|
|
| |
| |
|
|
From: sascha
Subject: Re: linux and windows version produce different output
Date: 12 Nov 2003 11:03:11
Message: <3fb259bf@news.povray.org>
|
|
|
| |
| |
|
|
Yes, but in this case the windows version shoots reflected rays where the linux
version does not,
and the results look completely different - the problem disappears if you change the
term
reflection { 0,1 fresnel }
to
reflection { 0,1 falloff 2 }
for example. In this case both versions produce absolute identical results...
Btw, in my test-scene the 'difference' produces coincident surfaces by accident, but
this is not related to the problem described, linux and windows versions output will
still look different if this is fixed...
-sascha
ABX wrote:
> On Wed, 12 Nov 2003 16:34:21 +0100, sascha <sas### [at] userssourceforgenet>
> wrote:
>
>
>>reflections ... produce different output!
>>
>>POV-Ray for Windows: Version 3.5.icl.win32
>>POV-Ray for Linux: Version 3.5 Unix (.Linux.gcc)
>
>
> Well, icl is not gcc. Intel compiler could utilize dedicated CPU/FPU commands
> related to single floats used as color components which determine
> reflection/refraction.
>
> ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Nicolas Calimet
Subject: Re: linux and windows version produce different output
Date: 12 Nov 2003 11:41:45
Message: <3FB262C9.6070200@free.fr>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: linux and windows version produce different output
Date: 15 Nov 2003 00:56:40
Message: <3fb5c018$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: linux and windows version produce different output
Date: 17 Nov 2003 17:38:07
Message: <3fb94dcf$1@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?
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
|
|
| |
| |
|
|
|
|
| |
