# rtcontrib & daylight coefficients

Hi all,

I'm trying to get my head around calculating daylight coefficients with rtcontrib and then how to use them!

My observations/questions so far:

1) the tregenza cal files (one is mentioned in the man page) were not automatically installed for me using the latest release on linux (rad3R7P2all.tar.gz).

2) Using the example in the man page I calculated a set of daylight coefficients:
rtcontrib -I+ -b tbin -o sky.dat -m sky_glow -b 0 -o ground.dat -m ground_glow -ad 10000 -as 5000 -ab 1 -f tregenza.cal test.oct < test.dat
This results in two files sky.dat and ground.dat
In ground.dat there is one set of coefficients
In sky.dat there are 146 sets
I expected 145 in the sky file. My belief is that the first set is for solar elevations < 0deg and can be ignored (and will always be equal to zero?) - am I correct?

3) Some strange behaviour has been observed with different sets of input points. I'm assuming that as with rtrace the input points are given as 6 numbers representing x,y,z of the sample point and i,j,k representing the normal. Given this if the first point has a normal pointing to the zenith (say 1 1 6 0 0 1) then I get 146 sets for all points. If the normal faces another direction I'm getting different problems:
137 sets (1 1 6 0 -1 0)
139 sets (1 1 6 1 0 0)
rtcontrib crashes (1 1 6 0 1 0) - rtcontrib: Bad expression! rtrace: signal - Broken pipe.
and strangely enough if these points & normals are given after one that works all is OK. Something odd is going on - can anyone shed some light on this for me please?

regards,

Iain

···

--
****************************
Dr Iain A Macdonald
Energy Systems Research Unit
University of Strathclyde
Glasgow, UK
+44 141 548 3747
http://www.esru.strath.ac.uk
****************************

Hi Iain,

Thanks for giving rtcontrib a try. Here are some hints for you:

From: Iain Macdonald <iain@esru.strath.ac.uk>
Date: September 23, 2005 6:25:22 AM PDT

Hi all,

I'm trying to get my head around calculating daylight coefficients with rtcontrib and then how to use them!

My observations/questions so far:

1) the tregenza cal files (one is mentioned in the man page) were not automatically installed for me using the latest release on linux (rad3R7P2all.tar.gz).

Yes, I felt some more testing and work was needed on Tregenza.cal and its associated support. It works, but it's a bit painful to use right now and I'd like to create some scripts to make it more straightforward, particularly the combining of images at the end. I have done some experiments to good effect on this already, and when I create a script it will install Tregenza.cal appropriately.

2) Using the example in the man page I calculated a set of daylight coefficients:
rtcontrib -I+ -b tbin -o sky.dat -m sky_glow -b 0 -o ground.dat -m ground_glow -ad 10000 -as 5000 -ab 1 -f tregenza.cal test.oct < test.dat
This results in two files sky.dat and ground.dat
In ground.dat there is one set of coefficients
In sky.dat there are 146 sets
I expected 145 in the sky file. My belief is that the first set is for solar elevations < 0deg and can be ignored (and will always be equal to zero?) - am I correct?

Rtcontrib always writes out the earlier bin values starting from 0, even if they are all zeroes. If your sky material covers only the upper hemisphere, then yes, your first bin should all be zeroes indicating no contribution. I sometimes employ a script that checks for all zero values and removes such files after rtcontrib has finished.

3) Some strange behaviour has been observed with different sets of input points. I'm assuming that as with rtrace the input points are given as 6 numbers representing x,y,z of the sample point and i,j,k representing the normal. Given this if the first point has a normal pointing to the zenith (say 1 1 6 0 0 1) then I get 146 sets for all points. If the normal faces another direction I'm getting different problems:
137 sets (1 1 6 0 -1 0)
139 sets (1 1 6 1 0 0)
rtcontrib crashes (1 1 6 0 1 0) - rtcontrib: Bad expression! rtrace: signal - Broken pipe.
and strangely enough if these points & normals are given after one that works all is OK. Something odd is going on - can anyone shed some light on this for me please?

The different sets are due to the fact that rtcontrib outputs from bin 0 to the number of bins actually read from rtrace, and this will depend on the sampling pattern. If you're only sampling the sky and ground directly (no geometry to bounce light around), then you may only see some of the bins. However, I don't know why you would get a "bad expression" error. Let me give it a go here. (Hold on...)

Well, unfortunately for you, it works for me! This could be a side-effect of the bug I discovered earlier this week where rtcontrib wasn't writing (or allocating) the last bin, and could be writing over unallocated memory. This has unpredictable consequences, and will depend on your compiler, your machine, what else is running, the weather, etc. Make sure you're using version 1.27 or later of rtcontrib.c, which you can get from CVS if you don't have it. (See my posting earlier this week.)

Let me know if your problems persist.
-Greg

···

---------------------
Ice Cream Koan: If a ice cream drops on the sidewalk, and there is no one there to cry, does it melt?

Greg,

I'm now using version 1.28 of rtcontrib and its much better, but still not 100% I think. Here is my model:
# gensky 4 2 10.00 +s -g 0.25 -a 51.7 -o -0.5 -m -0.5
# Local solar time: 9.94
# Solar altitude and azimuth: 36.2 -39.4
# Ground ambient level: 16.6

void light solar
0
3 6.47e+06 6.47e+06 6.47e+06

solar source sun
0
4 0.512417 -0.623930 0.590034 0.5

void brightfunc skyfunc
2 skybr skybright.cal
0
7 1 8.98e+00 2.24e+01 4.56e-01 0.512417 -0.623930 0.590034

skyfunc glow sky_glow
0 0 4 .986 .986 1.202 0
sky_glow source sky
0 0 4 0 0 1 180
# define ground...
skyfunc glow ground_glow
0 0 4 1.276 .957 .319 0
ground_glow source ground
0 0 4 0 0 -1 180

Which is about as simple as you can get I think

rtcontrib command as below with the following test points (in test.dat):
0 0 1 0 1 0
0 0 1 0 -1 0
0 0 1 0 1 0

I would expect to get the same data for point one and four and for points two and three. However the data for the last few points is (I've transposed the numbers and the data in the first column is the field from the rtcontrib output):
421 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 422 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 423 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 424 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 425 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 426 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 427 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 428 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 429 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 430 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 431 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 432 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 433 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 434 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 435 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 436 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03 437 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03 438 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03

First of all do you get the same results? Or am I doing something wrong.

regards,

Iain

Greg Ward wrote:

···

Hi Iain,

Thanks for giving rtcontrib a try. Here are some hints for you:

From: Iain Macdonald <iain@esru.strath.ac.uk>
Date: September 23, 2005 6:25:22 AM PDT

Hi all,

I'm trying to get my head around calculating daylight coefficients with rtcontrib and then how to use them!

My observations/questions so far:

1) the tregenza cal files (one is mentioned in the man page) were not automatically installed for me using the latest release on linux (rad3R7P2all.tar.gz).

Yes, I felt some more testing and work was needed on Tregenza.cal and its associated support. It works, but it's a bit painful to use right now and I'd like to create some scripts to make it more straightforward, particularly the combining of images at the end. I have done some experiments to good effect on this already, and when I create a script it will install Tregenza.cal appropriately.

2) Using the example in the man page I calculated a set of daylight coefficients:
rtcontrib -I+ -b tbin -o sky.dat -m sky_glow -b 0 -o ground.dat -m ground_glow -ad 10000 -as 5000 -ab 1 -f tregenza.cal test.oct < test.dat
This results in two files sky.dat and ground.dat
In ground.dat there is one set of coefficients
In sky.dat there are 146 sets
I expected 145 in the sky file. My belief is that the first set is for solar elevations < 0deg and can be ignored (and will always be equal to zero?) - am I correct?

Rtcontrib always writes out the earlier bin values starting from 0, even if they are all zeroes. If your sky material covers only the upper hemisphere, then yes, your first bin should all be zeroes indicating no contribution. I sometimes employ a script that checks for all zero values and removes such files after rtcontrib has finished.

3) Some strange behaviour has been observed with different sets of input points. I'm assuming that as with rtrace the input points are given as 6 numbers representing x,y,z of the sample point and i,j,k representing the normal. Given this if the first point has a normal pointing to the zenith (say 1 1 6 0 0 1) then I get 146 sets for all points. If the normal faces another direction I'm getting different problems:
137 sets (1 1 6 0 -1 0)
139 sets (1 1 6 1 0 0)
rtcontrib crashes (1 1 6 0 1 0) - rtcontrib: Bad expression! rtrace: signal - Broken pipe.
and strangely enough if these points & normals are given after one that works all is OK. Something odd is going on - can anyone shed some light on this for me please?

The different sets are due to the fact that rtcontrib outputs from bin 0 to the number of bins actually read from rtrace, and this will depend on the sampling pattern. If you're only sampling the sky and ground directly (no geometry to bounce light around), then you may only see some of the bins. However, I don't know why you would get a "bad expression" error. Let me give it a go here. (Hold on...)

Well, unfortunately for you, it works for me! This could be a side- effect of the bug I discovered earlier this week where rtcontrib wasn't writing (or allocating) the last bin, and could be writing over unallocated memory. This has unpredictable consequences, and will depend on your compiler, your machine, what else is running, the weather, etc. Make sure you're using version 1.27 or later of rtcontrib.c, which you can get from CVS if you don't have it. (See my posting earlier this week.)

Let me know if your problems persist.
-Greg

---------------------
Ice Cream Koan: If a ice cream drops on the sidewalk, and there is no one there to cry, does it melt?

_______________________________________________

--
****************************
Dr Iain A Macdonald
Energy Systems Research Unit
University of Strathclyde
Glasgow, UK
+44 141 548 3747
http://www.esru.strath.ac.uk
****************************

Hi Iain,

I'm not sure what your rtcontrib command was as you didn't include it in your e-mail, but you can expect a degree of randomness in the results as you would see in any Monte Carlo calculation. Try increasing -ad and decreasing the -lw value to see if you get convergence.

-Greg

···

From: Iain Macdonald <iain@esru.strath.ac.uk>
Date: September 30, 2005 9:14:33 AM PDT

Greg,

I'm now using version 1.28 of rtcontrib and its much better, but still not 100% I think. Here is my model:
# gensky 4 2 10.00 +s -g 0.25 -a 51.7 -o -0.5 -m -0.5
# Local solar time: 9.94
# Solar altitude and azimuth: 36.2 -39.4
# Ground ambient level: 16.6

void light solar
0
3 6.47e+06 6.47e+06 6.47e+06

solar source sun
0
4 0.512417 -0.623930 0.590034 0.5

void brightfunc skyfunc
2 skybr skybright.cal
0
7 1 8.98e+00 2.24e+01 4.56e-01 0.512417 -0.623930 0.590034

skyfunc glow sky_glow
0 0 4 .986 .986 1.202 0
sky_glow source sky
0 0 4 0 0 1 180 # define ground...
skyfunc glow ground_glow
0 0 4 1.276 .957 .319 0
ground_glow source ground
0 0 4 0 0 -1 180
Which is about as simple as you can get I think

rtcontrib command as below with the following test points (in test.dat):
0 0 1 0 1 0
0 0 1 0 -1 0
0 0 1 0 1 0

I would expect to get the same data for point one and four and for points two and three. However the data for the last few points is (I've transposed the numbers and the data in the first column is the field from the rtcontrib output):
421 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 422 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 423 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 424 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 425 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 426 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 427 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 428 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 429 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 430 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 431 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 432 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 433 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 434 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 435 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 436 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03 437 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03 438 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03
First of all do you get the same results? Or am I doing something wrong.

regards,

Iain

Greg et all,

I've done a few more tests and with -ad set to 10000 and -lw set to 0.0001 the results are much more consistent (and all previous issues are no longer applicable). This seems a bit extreme but it works.

Iain

Gregory J. Ward wrote:

···

Hi Iain,

I'm not sure what your rtcontrib command was as you didn't include it in your e-mail, but you can expect a degree of randomness in the results as you would see in any Monte Carlo calculation. Try increasing -ad and decreasing the -lw value to see if you get convergence.

-Greg

From: Iain Macdonald <iain@esru.strath.ac.uk>
Date: September 30, 2005 9:14:33 AM PDT

Greg,

I'm now using version 1.28 of rtcontrib and its much better, but still not 100% I think. Here is my model:
# gensky 4 2 10.00 +s -g 0.25 -a 51.7 -o -0.5 -m -0.5
# Local solar time: 9.94
# Solar altitude and azimuth: 36.2 -39.4
# Ground ambient level: 16.6

void light solar
0
3 6.47e+06 6.47e+06 6.47e+06

solar source sun
0
4 0.512417 -0.623930 0.590034 0.5

void brightfunc skyfunc
2 skybr skybright.cal
0
7 1 8.98e+00 2.24e+01 4.56e-01 0.512417 -0.623930 0.590034

skyfunc glow sky_glow
0 0 4 .986 .986 1.202 0
sky_glow source sky
0 0 4 0 0 1 180 # define ground...
skyfunc glow ground_glow
0 0 4 1.276 .957 .319 0
ground_glow source ground
0 0 4 0 0 -1 180
Which is about as simple as you can get I think

rtcontrib command as below with the following test points (in test.dat):
0 0 1 0 1 0
0 0 1 0 -1 0
0 0 1 0 1 0

I would expect to get the same data for point one and four and for points two and three. However the data for the last few points is (I've transposed the numbers and the data in the first column is the field from the rtcontrib output):
421 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 422 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 423 7.479982e-03 0.000000e+00 0.000000e+00 4.986655e-03 424 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 425 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 426 0.000000e+00 2.493327e-03 2.493327e-03 0.000000e+00 427 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 428 0.000000e +00 1.246664e-02 1.246664e-02 0.000000e+00 429 0.000000e+00 1.246664e-02 1.246664e-02 0.000000e+00 430 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 431 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 432 0.000000e+00 4.986655e-03 2.493327e-03 0.000000e+00 433 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 434 4.986655e-03 0.000000e+00 0.000000e+00 4.986655e-03 435 4.986655e-03 0.000000e +00 0.000000e+00 4.986655e-03 436 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03 437 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03 438 2.493327e-03 0.000000e+00 2.493327e-03 2.493327e-03
First of all do you get the same results? Or am I doing something wrong.

regards,

Iain

_______________________________________________