[Radiance-general] Sunlight hours calculation in radiance

[Giovanni Betti]

Lars, 
the number of about 300 comes from subdividing each tregenza patch in 4
to increase angular resolution and then looking only at the occupied
patches, sorry for the confusion.

I would be interested as well in seeing how other people approached the
same problem though.

Thanks,

Giovanni

-----Original Message-----
From: Lars O. Grobe [mailto:grobe at gmx.net] 
Sent: 15 February 2011 12:16
To: Radiance general discussion
Subject: Re: [Radiance-general] Sunlight hours calculation in radiance

Hi Giovanni!

> I see how that's a possibility but it would mean running separate
images
> and to filter each of them.

I guess it would not be impossible, as renderings should complete very 
fast when considering only direct.

> simulation with multiple sun positions. Eventually as an optimization
> the sun position can be clustereed according to tregenza patches and
> each patch weighted based on the number of sun hours it represents (so
> you don't even need 4000 sun but maybe only 300...)
> Any hint on that?

The tregenza sky introduces limitations of the angular resolution. You 
may try a two-step approach:

First, for each patch, find out at how many time intervals the sun is 
covered by the patch. So a patch containing the sun solid angle 20 times

a year, you would set the patch value to 20.

Second, run rtcontrib to find out which patch contributes to which 
pixel. Here you can apply your threshold just as described in my former 
email, so any pixel that is lid by a patch is set to the value (in 
hours) for the patch from step 1.

With a Tregenza grid, you would end up with 145 images, each pixel value

corresponding to the number of hours of direct sun exposure from the 
related patch. Adding up all the 145 images in the third step should 
result in pixel values of direct sun exposure (hours) for all patches.

BTW if you follow an approach as typically used when working with 
Tregenza skies, and split the sun over n neighbouring patches, you would

of course set the pixel value to 1/n instead.

I am not sure about better ways to achieve what you want to do, this is 
just one idea... any other proposals? I am sure others have done that 
before...

Cheers, Lars.