Sunlight hours calculation in radiance

radiance-general
1

Dear List,

I was wondering if anybody could give me a hint on how to solve the
following problem: how to calculate sunlight hours hitting a surface
using Radiance.
My hunch is to use a modified version of gensky with -B set to 0 (no
diffuse component) and -R set to 1/179 and of course as many calls of
gensky as required to cover all the sunlight hours in the time period I
am interested in.
Of course it is a brute force approach but as I am just interested in
'hit or miss' type of results and -ab would beset to 0 it still seems
pretty fast.
The problem that I face is that each ray is weighted based on the angle
of incidence with the target surface. Is there a way of forcing radiance
to return only a yes/no type of value?

Thanks in advance for your help,

Best,

Giovanni

2

Hi!

The problem that I face is that each ray is weighted based on the angle
of incidence with the target surface. Is there a way of forcing radiance
to return only a yes/no type of value?

You may use pcomb to combine the images after applying a threshold to the pixel values (using the -e parameter to pass an expression) of each image.

Cheers, Lars.

3

Thanks Lars,
I see how that's a possibility but it would mean running separate images
and to filter each of them.
It might work on a run over a day in winter but it seems unpractical
over a longer period of time (if you where to do this over a year you
would end up with about 4k images!) I was planning to run only one
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?
Thanks,

Giovanni

···

-----Original Message-----
From: Lars O. Grobe [mailto:[email protected]]
Sent: 15 February 2011 11:01
To: Radiance general discussion
Subject: Re: [Radiance-general] Sunlight hours calculation in radiance

Hi!

The problem that I face is that each ray is weighted based on the

angle

of incidence with the target surface. Is there a way of forcing

radiance

to return only a yes/no type of value?

You may use pcomb to combine the images after applying a threshold to
the pixel values (using the -e parameter to pass an expression) of each
image.

Cheers, Lars.

4

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.

5

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:[email protected]]
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.

6

I would be interested as well in seeing how other people approached the

same problem though.

In the UK you have to calculate sunlight hours on the ground for planning
purposes.

We used a grid (as opposed to an image) and traced rays from each grid point
to the sun (direction was calculated from the gensky sun angle information).
We modified the rtrace command to print the material of the surface it hits
instead of the radiance. If the ray hits the sky (or nothing) it returns
"*", if it hits an obstruction it returns the material name. Then you just
need to count the "*"s in the output file to know your number of sunlight
hours.

For planning this is done on one day only, so we ran it with a 5 minute
resolution. It only took minutes for a reasonably sized grid and that
included all the preparation and evaluation in Lua (Ecotect). This method
generates a data array (x,y,n) which you have to visualise in a separate
step.

[On second thought you can probably combine this method with an vwrays based
preprocess to find all the surface points in the scene. For these scene
points you then evaluate the number of sunlight hours as above and return
the number as value for the image. Sounds like a longish simulation,
though.]

If you want pictures your idea with rtcontrib and optimised suns seems very
promising. A Tregenza subdivision is not optimal because the sun only
occupies about a quarter to a third of the sky. But you can run rtcontrib on
defined light sources so you just need to give all your suns a unique
identifier and you're set (the command line length might be somewhat
excessive, though). You can also interpolate between the sun positions
without loosing too much accuracy so you really only need to evaluate a few
hundred positions. It might be worth to split the summer from the winter.

If you want to read the sun light hours directly from the final image you
have to use a unified sun source and combine all the images with a cosine
corrected intensity for this particular surface which results in a 1 for
each bright pixel on that surface. The final image gives you a direct
representation of the sunlight hours. If you have more than one surface
(more than one surface orientation, that is) you should go with Lars'
recommendation and apply a threshold value to convert all bright pixels to a
1 value, regardless of the intensity.

Regards,
Thomas

···

On Tue, Feb 15, 2011 at 7:28 AM, Giovanni Betti < [email protected]> wrote:

7

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:[email protected]]
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
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

--
LF logo Daniel C. Glaser, PhD, LEED AP, IES
Principal
Light Foundry, LLC
T: 510.387.8890 | F: 315.410.2617
www.lightfoundryllc.com <http://www.lightfoundryllc.com>

8

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:[email protected]]
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:[email protected]]
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
[email protected]
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

9

For those of you using Daysim, there is a fast subprogram called
gen_directsunlight that you can use for this purpose. The program places
your scene in a glowing sphere and then shoot rays from your work
plane sensor towards the direction of the sun if the direct radiation
component is above 50WM/m2 (according to the annual climate file). The
resulting *.dir file reports a "1" if direct sunlight hits the sensor
and '0' otherwise for every hour in the year.

Christoph

···

From: Thomas Bleicher [mailto:[email protected]]
Sent: Tuesday, February 15, 2011 10:02 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] Sunlight hours calculation in radiance

On Tue, Feb 15, 2011 at 7:28 AM, Giovanni Betti <[email protected]> wrote:

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

In the UK you have to calculate sunlight hours on the ground for
planning purposes.

We used a grid (as opposed to an image) and traced rays from each grid
point to the sun (direction was calculated from the gensky sun angle
information). We modified the rtrace command to print the material of
the surface it hits instead of the radiance. If the ray hits the sky (or
nothing) it returns "*", if it hits an obstruction it returns the
material name. Then you just need to count the "*"s in the output file
to know your number of sunlight hours.

For planning this is done on one day only, so we ran it with a 5 minute
resolution. It only took minutes for a reasonably sized grid and that
included all the preparation and evaluation in Lua (Ecotect). This
method generates a data array (x,y,n) which you have to visualise in a
separate step.

[On second thought you can probably combine this method with an vwrays
based preprocess to find all the surface points in the scene. For these
scene points you then evaluate the number of sunlight hours as above and
return the number as value for the image. Sounds like a longish
simulation, though.]

If you want pictures your idea with rtcontrib and optimised suns seems
very promising. A Tregenza subdivision is not optimal because the sun
only occupies about a quarter to a third of the sky. But you can run
rtcontrib on defined light sources so you just need to give all your
suns a unique identifier and you're set (the command line length might
be somewhat excessive, though). You can also interpolate between the sun
positions without loosing too much accuracy so you really only need to
evaluate a few hundred positions. It might be worth to split the summer
from the winter.

If you want to read the sun light hours directly from the final image
you have to use a unified sun source and combine all the images with a
cosine corrected intensity for this particular surface which results in
a 1 for each bright pixel on that surface. The final image gives you a
direct representation of the sunlight hours. If you have more than one
surface (more than one surface orientation, that is) you should go with
Lars' recommendation and apply a threshold value to convert all bright
pixels to a 1 value, regardless of the intensity.

Regards,

Thomas