[Radiance-general] Sunlight hours calculation in radiance

David Smith David.Smith at BuroHappold.com
Tue Feb 15 08:15:22 PST 2011


I would suggest this:

 

[loop over timebounds (can have a sun above horizon check here too, also
if the day exists, like Feb 30)]
    [gensky with the day/time]

    [create/overwrite temp image making sure to have -ab 0]

    [pcomb -e 'lo=if(li(1)-100/WE,1,0' the image to make any value above
100 lux be 1, any value below be 0 > month.day.hour.hdr]

[loop over timebounds]

    [for every month]

        [for every day]

            [combine hours in day with pcomb > month.day.XX.hdr]

        [combine days in month with pcomb > month.XX.XX.hdr]

    [combine months in year with pcomb > sunhours.hdr]

 

The values in the final image will be in terms of sun-hours. It assumes
that any part of the image over 100 lux direct exterior illuminance is
in the sun. The key to speed here, I think, is to make the octree quick
to load. 

 

Bonus points if you can create multiple threads/processes and run
through the first loop in parallel...

 

 

 

From: Dan Glaser [mailto:daniel at lightfoundryllc.com] 
Sent: Tuesday, February 15, 2011 10:41 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] Sunlight hours calculation in radiance

 

Hi Giovanni and Lars!
  I think you guys have some good approaches.
  If # of images it produces is an issue for the original "brute force"
method you proposed for checking direct sun exposure on clear days, you
can overwrite the same image every-time after doing an image check and
incrementing a variable.  Below is pseudo-code:

[loop over timebounds (can have a sun above horizon check here too)]
    [create/overwrite image SunCheckImage]
    [if (pixel value of representative point in SunCheckImage >
threshold) 
        num_timesteps_in_sun++]
[print "I've been in the sun for " + num_timesteps_in_sun + " time
steps"]
[delete SunCheckImage]

  Sorry, I do not know off-hand an easy command for reading pixel values
of .hdr images with Radiance (pcomb ?...), but this can be done
elsewhere (e.g. ImageMagick...). 
  Thresholds can be tricky, so take into account reflected, ambient, low
angle, etc light (which is what you are doing with -ab...).  
  You can also try intersecting the line between the surface and sun
with the model geometry for each time-step...
  Good luck!

- Dan


On 2/15/2011 5:28 AM, Giovanni Betti wrote: 

 
 
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.
 
 
_______________________________________________
Radiance-general mailing list
Radiance-general at radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general
 
 

 

-- 

 

Daniel C. Glaser, PhD, LEED AP, IES 

Principal
Light Foundry, LLC
T: 510.387.8890 | F: 315.410.2617

www.lightfoundryllc.com

 

 

 



This message has been scanned by MailController - www.MailController.altohiway.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20110215/80bc7e9a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5569 bytes
Desc: image001.png
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20110215/80bc7e9a/attachment.png>


More information about the Radiance-general mailing list