sky definition

hello everyone,

Thanks to u�all �the gurus� I have not only started getting better results,
but know better what I am doing. However the sky still completely baffles me,
especially since it is defined so easily even though it is so complex.

Here are the questions:
1. All I do to specify the sun is write the following one line for the sun :
does gensky model the sun as a light material using these definitions?
!gensky 4 11 13:0 +s -a (latitude) -o (longitude) -m (meridian) �B (horizontal
diffuse irradiance) �R (horizontal direct irradiance, can direct normal be
used?)

2. Should skyfunc be defined by me before it is used as a modifier in the sky
definition, or does the skyfunc modifier take the input from the first line
(as above) to modify the glow command? (pg 355 of RWR)

3. Following parameters define the sky and I believe it is modified so as to
give a blue hue etc, but how is it determined as to what it should be for a
specific case?
skyfunc glow skyglow
0
0
4 .986 .986 1.205 0 (these values are modified, sometimes 4 .9 .9 1 0 is used
also for sunny skies)

skyglow source sky
0
0
4 0 0 1 180

4. Similarly while defining the ground, what is the best way to determine what
the ground values for RGB should be � I have been contemplating between using
one of the following case but what should I base the decision on? How do you
judge as to what values should be used for your specific case?
skyfunc glow ground_glow
0
0
4 1 .7 .25 0 (or 4 1 1 1 0 is used, I am guessing, for a uniform glow!)

ground_glow source ground
0
0
4 0 0 -1 180

I would really be grateful if someone could help me with this or guide me to a
specific text material which I may have missed when trying to look for the
answer to the above questions.

Thanks and have a great day!

Amarpreet

Graduate Student
Arizona State University

Hi Amarpreet,

Good timing, I was just eating lunch here...

[email protected] wrote:

... However the sky ... is defined so easily even though it is so complex.

Well said; I wish more of our clients understood this very simple truth!

Here are the questions:
1. All I do to specify the sun is write the following one line for the sun : does gensky model the sun as a light material using these definitions?
!gensky 4 11 13:0 +s -a (latitude) -o (longitude) -m (meridian) �B (horizontal diffuse irradiance) �R (horizontal direct irradiance, can direct normal be used?)

Gensky is very flexible, and simple, but added complexity is available. =8-) The manpage explicitly lists all the options, but I don't believe specifying direct normal irradiance is an option. You can specify the sun radiance, however. Others can probably give better info on these options, as I tend to use the lat/long/timezone/TOD method.

2. Should skyfunc be defined by me before it is used as a modifier in the sky definition, or does the skyfunc modifier take the input from the first line (as above) to modify the glow command? (pg 355 of RWR)

You've got it, skyfunc is *defined* by gensky, and *applied* by you in your subsequent source statements. When you use skyfunc as a modifier right after the inline !gensky command, the sky glow is modeled using your input parameters from that gensky command.

3. Following parameters define the sky and I believe it is modified so as to give a blue hue etc, but how is it determined as to what it should be for a specific case?
skyfunc glow skyglow
0
4 .986 .986 1.205 0 (these values are modified, sometimes 4 .9 .9 1 0 is used also for sunny skies)

skyglow source sky
0
4 0 0 1 180

By specific case you mean sky color? The color is totally arbitrary, however this is very important, the weighted average RGB must add up to 1! If you pick values that give you a pleasing sky color but add up to greater or less than 1, your sky luminance will be incorrect. It will be factored by the deviation from 1 in your average. And, .9 .9 1 (which is used as an example blue sky on the gensky manpage) is just such a combination! I mentioned this to Greg a little while ago, and I think it got fixed in the distribution, but the radiance website still has the error:

http://www.radiance-online.org/pipermail/radiance-general/2003-May/000789.html

(hmm, Schorsch, yours still has this error as well: http://www.schorsch.com/rayfront/manual/htmlman/gensky.html\)

4. Similarly while defining the ground, what is the best way to determine what the ground values for RGB should be � I have been contemplating between using one of the following case but what should I base the decision on? How do you judge as to what values should be used for your specific case?
skyfunc glow ground_glow
0
4 1 .7 .25 0 (or 4 1 1 1 0 is used, I am guessing, for a uniform glow!)

Colorwise, the same thing applies for grounds and skies. Use a color that makes sense and don't over saturate it, and make sure its weighted average equals 1. As for ground reflectance, just make sure you specify the average ground reflectance in your gensky command with the -g parameter. When skyfunc sees the negative z component to your ground hemisphere it will modify the reflectance of that glow by whatever factor you used in -g. When you use this feature, as long as the -g reflectance matches whatever material you use for your local ground plane, you will get a very good match (except at certain shallow viewing angles) between the local plane and the distant horizon.

···

----

      Rob Guglielmetti

e. [email protected]
w. www.rumblestrip.org

Rob Guglielmetti wrote:

Here are the questions:
1. All I do to specify the sun is write the following one line for the sun :
does gensky model the sun as a light material using these definitions?
!gensky 4 11 13:0 +s -a (latitude) -o (longitude) -m (meridian) �B (horizontal
used?)

Just type the command into a shell (console window), and you'll
get a better idea about what you still need to add yourself.

  And, .9 .9 1
(which is used as an example blue sky on the gensky manpage) is just
such a combination! I mentioned this to Greg a little while ago, and I
think it got fixed in the distribution, but the radiance website still
has the error:

http://www.radiance-online.org/pipermail/radiance-general/2003-May/000789.html

(hmm, Schorsch, yours still has this error as well:
http://www.schorsch.com/rayfront/manual/htmlman/gensky.html\)

That will be updated when I integrate a more current version
of Radiance with Rayfront.

Btw: Rayfront users don't need to worry about this. They can just
set the sky/ground color with the standard Rayfront color selector,
and the software will normalize the values to a weighted average
of 1 internally. The original deviation is remembered though,
so that you won't get confused too much when you reopen the same
dialog later.

-schorsch

···

[email protected] wrote:

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Very nice response, Rob. You're correct that gensky doesn't offer an option for specifying the direct normal solar irradiance, only the direct horizontal irradiance (-R) and solar radiance (-r). To compute the solar radiance from direct normal irradiance, divide the normal irradiance by 5.98e-5, which is the number of steradians in a 0.5 degree source like the sun.

To confuse matters further, you should probably consider the solar efficacy if you are working from true irradiance measurements and attempting to get absolute photometric results out of Radiance. As I explained at the workshop, Radiance uses a conversion of 179 lumens/watt to go back and forth between photometric and radiometric units. Since the same constant is used for the forward and reverse conversions, it usually drops out and is of no concern. However, no such conversion occurs on the input to gensky, so you should probably intervene with your own correction if you are working from physical data. Therefore, I recommend multiplying values to the -r and -R options by:

  208/179 the ratio between the sun's efficacy and the standard Radiance factor

Likewise, values to the -b and -B options should be multiplied by:

  110/179 the ratio for sky radiation efficacy over the standard Radiance factor

This way, when 179 gets applied on the output conversion to photometric units, you will get closer to the correct absolute results.

If folks think I should add these factors directly into gensky, I would be happy to. My principal hesitation in making such a correction is the confusion it may cause users whose scripts have been running one way for years when they get different results in the next version.

-Greg

Thank you all. This was extremely helpful.

Thanks Rob, for all the detail answers for so many of my questions.
  
Greg, I was using 120/179 multiplying factor for both sky and sun brightness
values. Hence, will switch to what you mentioned, which is seperate for the
sky and sun brightness.

Regarding the Direct normal radiation - I found that this value was specified
as the amount of solar radiation received within a 5.7� field of view centered
on the sun (during the 60 minutes preceding the hour indicated), would I still
be dividing by 5.98e-5 as you mentioned to get the -r? or is this a different
value all together?

Thanks very much.

best regards,
Amarpreet

Quoting Greg Ward <[email protected]>:

···

Very nice response, Rob. You're correct that gensky doesn't offer an
option for specifying the direct normal solar irradiance, only the
direct horizontal irradiance (-R) and solar radiance (-r). To compute

the solar radiance from direct normal irradiance, divide the normal
irradiance by 5.98e-5, which is the number of steradians in a 0.5
degree source like the sun.

To confuse matters further, you should probably consider the solar
efficacy if you are working from true irradiance measurements and
attempting to get absolute photometric results out of Radiance. As I
explained at the workshop, Radiance uses a conversion of 179
lumens/watt to go back and forth between photometric and radiometric
units. Since the same constant is used for the forward and reverse
conversions, it usually drops out and is of no concern. However, no
such conversion occurs on the input to gensky, so you should probably
intervene with your own correction if you are working from physical
data. Therefore, I recommend multiplying values to the -r and -R
options by:

  208/179 the ratio between the sun's efficacy and the standard
Radiance factor

Likewise, values to the -b and -B options should be multiplied by:

  110/179 the ratio for sky radiation efficacy over the standard
Radiance factor

This way, when 179 gets applied on the output conversion to photometric

units, you will get closer to the correct absolute results.

If folks think I should add these factors directly into gensky, I would

be happy to. My principal hesitation in making such a correction is
the confusion it may cause users whose scripts have been running one
way for years when they get different results in the next version.

-Greg

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Greg Ward wrote:

  Therefore, I recommend multiplying values to the -r and -R
options by:

  208/179 the ratio between the sun's efficacy and the standard
Radiance factor

Likewise, values to the -b and -B options should be multiplied by:

  110/179 the ratio for sky radiation efficacy over the standard
Radiance factor

Is that the clear sky?
DIN 5034 has 115 for the overcast sky. Not sure if that's
really a significant amount of difference, though.

This way, when 179 gets applied on the output conversion to photometric
units, you will get closer to the correct absolute results.

If folks think I should add these factors directly into gensky, I would
be happy to. My principal hesitation in making such a correction is
the confusion it may cause users whose scripts have been running one
way for years when they get different results in the next version.

Not only that, but people will probably want to use different
values for different types of skies. I suspect that using any
specific conversion doesn't make much sense, unless you know
exactly under what conditions your measurements were taken.
Or are the above figures widely accepted to be "close enough"?

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Hi Amarpreet,

The fact that the direct normal measurement covers a 5.7 degree field of view doesn't change the actual angular size of the sun. There should probably be some small correction added for the circumsolar that is included by the measurement, but it would vary so much with atmospheric turbidity, that the errors associated with such a correction would probably be so large as to make it a next to pointless fudge factor. I wouldn't bother with it, myself.

-Greg

···

From: [email protected]
Date: Tue Oct 14, 2003 2:52:02 PM US/Pacific

Regarding the Direct normal radiation - I found that this value was specified
as the amount of solar radiation received within a 5.7� field of view centered
on the sun (during the 60 minutes preceding the hour indicated), would I still
be dividing by 5.98e-5 as you mentioned to get the -r? or is this a different
value all together?