rtrace: strange behaviour

Hi!

While waiting for an answer to my first message, here is a second question.

I get a strange behaviour when I use rtrace to get irradiance/illuminance
values from sky patches described using the primitive "source" with modifier
"glow". Here is an example:

--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------
#file: patch1.rad = patch located at altitude gamma=30�; theta=90�-30�=60�
void glow skyglow
0
0
4 1 1 1 0

skyglow source skypatch
0
0
4 0.836516 0.224144 0.500000 11.500000
--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------
#file: patch2.rad = patch located at altitude gamma=90�; theta=90�-90�=0�
void glow skyglow
0
0
4 1 1 1 0

skyglow source zenith_skypatch
0
0
4 0.000000 0.000000 1.000000 11.500000
--------8<--------8<--------8<--------8<--------8<--------8<--------8<--------

The solid angles subtended by the patches are equal to 0.0316 steradians in
both cases.

Then I "oconv" the two files to get the octrees (respectively p1.oct and
p2.oct) and I want to get the direct daylight coefficients for the two
patches.
The patch radiance is 1 and the scene is made only by each patch and a
measurement point located at 0 0 0, direction 0 0 1. So ...

$ echo '0 0 0 0 0 1' | rtrace -h -w -I+ -ab 1 p1.oct | rcalc -e \
      '$1=$1/0.0316'
0.373048734

ok! in this simple case it should be equal to sin(30)=cos(60)=0.5
so I increase the -ad and -as values:

$ echo '0 0 0 0 0 1' | rtrace -ad 2048 -as 1024 -h -w -I+ -ab 1 \
p1oct | rcalc -e '$1=$1/0.0316'
0.497311709

that is very close to the correct value.

Let's make the same with the second patch (orthogonal to the measurement
point):

$ echo '0 0 0 0 0 1' | rtrace -h -w -I+ -ab 1 p2.oct | rcalc -e \
'$1=$1/0.0316'
1.1191462

uhm ok! let's increase the -ad and -as values:

$echo '0 0 0 0 0 1' | rtrace -ad 2048 -as 1024 -h -w -I+ -ab 1 \
p2.oct | rcalc -e '$1=$1/0.0316'
0.413590506

Hey! What happened?

If I set -as 0 I still get a good value ... is it a trouble with my way of
using it or something wrong with the code?
Should I use some other -a* switch?

Thank you!

···

--
Francesco Anselmo
[email protected]

Francesco Anselmo wrote:

[...]
$echo '0 0 0 0 0 1' | rtrace -ad 2048 -as 1024 -h -w -I+ -ab 1 \
p2.oct | rcalc -e '$1=$1/0.0316'
0.413590506

Hey! What happened?

If I set -as 0 I still get a good value ... is it a trouble with my way of
using it or something wrong with the code?
Should I use some other -a* switch?

Since this is the zenithal patch, that's the expected result.
Well, maybe not expected without seeing the code, but the ambient
ray distribution happens to have a small statistical irregularity
near the normal vector of the measuring plane. Any other patch
of your sky should give you a value very close to 0.5.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Hi!

Since this is the zenithal patch, that's the expected result.
Well, maybe not expected without seeing the code, but the ambient
ray distribution happens to have a small statistical irregularity
near the normal vector of the measuring plane.

Oh, thanks for showing me the truth!
So it is not possible to get the right result there ...

Now I understand that I should begin to study the code
and to read the second part
of the book (Rendering with Radiance) carefully ...

Thank you!

···

--
Francesco Anselmo
[email protected]

Francesco Anselmo responds to Schorsch:

> Since this is the zenithal patch, that's the expected result.
> Well, maybe not expected without seeing the code, but the ambient
> ray distribution happens to have a small statistical irregularity
> near the normal vector of the measuring plane.

Oh, thanks for showing me the truth!
So it is not possible to get the right result there ...

Actually, it should get the right result, but I wouldn't be surprised if the convergence was slow... The sampling irregularity is due to the use of polar coordinates, which causes a convergence of sample areas at the normal (pole). I should have adopted a different sampling strategy to maintain area aspect ratios, but this would have made the gradient calculation impossible.

More excuses as I am able to think them up.
-Greg