[Radiance-general] rtcontrib & daylight coefficients

[Greg Ward]

Hi Iain,

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

> From: Iain Macdonald <iain at 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?