trans material with sunless sky

hi,

I hope this isn't a stupid question..
I have a room with transluscent skylights.
When I simulated the room with clear sunny sky, the illuminance values
inside the room were reasonable and expected, around 400 Lux.
When I simulated a cloudy sky or a intermediate sky without a sun, the
illuminance values inside the room were way too low, <30 Lux.
Why is this? I usually use sunny sky and so never came across this
problem before.

Thus far I have changed the skylight material around several times to
make
sure that I didn't create a really bad example of a trans, I am running
mkillum
and surface normals are correct, and I have also increased the rendering

quality (to see if more light can be found) but nothing is working.

Any help for this would be great.
thanks,

judy

judy lai wrote:

hi,

I hope this isn't a stupid question..
I have a room with transluscent skylights.
When I simulated the room with clear sunny sky, the illuminance values
inside the room were reasonable and expected, around 400 Lux.
When I simulated a cloudy sky or a intermediate sky without a sun, the
illuminance values inside the room were way too low, <30 Lux.
Why is this? I usually use sunny sky and so never came across this
problem before.

Thus far I have changed the skylight material around several times to make
sure that I didn't create a really bad example of a trans, I am running
mkillum and surface normals are correct, and I have also increased the
rendering quality (to see if more light can be found) but nothing is working.

Hi Judy,

are those skylights the only windows in the room? Did the sun
actually hit the trans surfaces? In that case, what you're seeing
might be the expected result, even if you didn't expect it... :wink:

The typical irradiance caused by direct solar impact is
approximately ten times that of the completely unobstructed
diffuse sky, under most conditions during the day. If you have
any area of the sky obstructed by other building parts from the
view of the skylights, that do not also obstruct the sun, then a
relation of 400 to 30 sounds perfectly reasonable. Or do you have
any more specific reasons to assume that the results for the
cloudy sky should be higher?

-schorsch

···

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

In the immediate transition from bright sunlight to an inside location
I can agree it initially looks way dark.

But pupils dilate.

Shouldn't there be a hack on the final brightness to simulate the stable
post-transition *apparent* brightness of the inside room?

I mean, am I alone in initially thinking a 60 watt reading light is dim
but inside 5 minutes, its way bright?

Sure, some radiance users want to know what a light meter tells them. But
other radiance people want to know what a person will SEE.

cheers
  -George

judy lai wrote:

> hi,
>
> I hope this isn't a stupid question..
> I have a room with transluscent skylights.
> When I simulated the room with clear sunny sky, the illuminance values
> inside the room were reasonable and expected, around 400 Lux.
> When I simulated a cloudy sky or a intermediate sky without a sun, the
> illuminance values inside the room were way too low, <30 Lux.
> Why is this? I usually use sunny sky and so never came across this
> problem before.
>
> Thus far I have changed the skylight material around several times to mak

e

> sure that I didn't create a really bad example of a trans, I am running
> mkillum and surface normals are correct, and I have also increased the
> rendering quality (to see if more light can be found) but nothing is work

ing.

···

Hi Judy,

are those skylights the only windows in the room? Did the sun
actually hit the trans surfaces? In that case, what you're seeing
might be the expected result, even if you didn't expect it... :wink:

The typical irradiance caused by direct solar impact is
approximately ten times that of the completely unobstructed
diffuse sky, under most conditions during the day. If you have
any area of the sky obstructed by other building parts from the
view of the skylights, that do not also obstruct the sun, then a
relation of 400 to 30 sounds perfectly reasonable. Or do you have
any more specific reasons to assume that the results for the
cloudy sky should be higher?

-schorsch

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

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

--
George Michaelson | APNIC
Email: [email protected] | PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490 | Australia
  Fax: +61 7 3367 0482 | http://www.apnic.net

George Michaelson wrote:

In the immediate transition from bright sunlight to an inside location
I can agree it initially looks way dark.

But pupils dilate.

Shouldn't there be a hack on the final brightness to simulate the stable
post-transition *apparent* brightness of the inside room?

I mean, am I alone in initially thinking a 60 watt reading light is dim
but inside 5 minutes, its way bright?

Sure, some radiance users want to know what a light meter tells them. But
other radiance people want to know what a person will SEE.

pcond applies a post processing step on the final image to model eye
response.

-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

> Sure, some radiance users want to know what a light meter tells them. But
> other radiance people want to know what a person will SEE.

pcond applies a post processing step on the final image to model eye
response.

-Peter

sounds like *just* what I need. Many thanks.

-George

hi Georg,

The typical irradiance caused by direct solar impact is
approximately ten times that of the completely unobstructed
diffuse sky, under most conditions during the day. If you have
any area of the sky obstructed by other building parts from the
view of the skylights, that do not also obstruct the sun, then a
relation of 400 to 30 sounds perfectly reasonable. Or do you have
any more specific reasons to assume that the results for the
cloudy sky should be higher?

Thanks. No specific reason to assume it would be higher, I just
thought it would be because, having being inside during overcast
days, it doesn't always "feel" so dark. But that's the eye doing the
adaptation thing...
I replaced the skylights with 99% clear glass and the maximum
reading inside room for overcast was 160 lux, this helped me
proved to myself that everything was ok.

Another question. Pcond on a luminance image mimics what
the eyes sees. Pcond on an illuminance image mimics ... ?

judy

judy lai wrote:

Another question. Pcond on a luminance image mimics what
the eyes sees. Pcond on an illuminance image mimics ... ?

I don't think you really want to use pcond on an
illuminance image. If anything, then it might mimic
what the surfaces in your space would see if they
had the capabilities of the human eye, which sounds
quite unlikely...

-schorsch

···

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

Another question. Pcond on a luminance image mimics what
the eyes sees. Pcond on an illuminance image mimics ... ?

judy

can somebody tell me what is the purpose of illuminance images? am i correct in saying that these are created by using the -i option in rpict/rview?

quoting from the Radiance Reference manual, 'This only affects the final result, substituting a Lambertian surface and multiplying the radiance by pi'. so the numbers you end up with in these images are simply that, the reflected radiance multiplied by pi. what does this represent? it does not represent the irradiance falling on the surface. for any non-Lambertian surface, it does not represent the irradiance reflected off the surface either.

so, for Lambertian reflectors, the results are reflected irradiances, which are the incident irradiances multiplied by the reflectance of the surface. in a visualisation such as this, reflected irradiances are of very little interest. radiance and incident irradiance are actually much more useful.

too often have i seen Radiance images presented overlaid with iso-illuminance contours. according again to the Radiance Reference manual, under falsecolor, 'If the -i option of rpict was used to produce the image, then the appropriate label (for a falsecolor image) would be "Lux"'. this means that the illuminance values displayed in these images are some manifestation of reflected illuminance. from a photometric point of view, this is essentially meaningless.

if this is presented to a client to show them the illuminance distribution within their space, it really tells them very little. iso-illuminance contours are meant to represent the illuminance falling onto an imaginary sensor at that location. the -i option of rpict does not calculate this. the only real way of presenting illuminance information is on a plane, real or imaginary, horizontal, vertical or tilted, not overlaid on a visualisation.

i understand that people have a better understanding of illuminance, and so to present things in this manner makes it easier for clients to understand. but they should not be led to believe that these contours actually represent illuminances within their room which are to be compared with specifications, standards, etc.

can anybody correct me here? i don't mean to ruffle any feathers, but i think Radiance is generally used by people with a good knowledge of light, and so it should be used accordingly.

Phil Greenup

judy lai wrote:

Another question. Pcond on a luminance image mimics what
the eyes sees. Pcond on an illuminance image mimics ... ?

Presumably what you would perceive if you were spread over all surfaces.
Not unlike an LSD trip. Wouldn't try it if I were you. :^)

···

--
"Life is too boring for short videos" (TechVision)

Phillip Greenup wrote:

can somebody tell me what is the purpose of illuminance images?

The purpose is to map the illuminance/irradiance of one or
several surfaces. So far, it's easy... :wink:

am i correct
in saying that these are created by using the -i option in rpict/rview?

Yes.

quoting from the Radiance Reference manual, 'This only affects the final
result, substituting a Lambertian surface and multiplying the radiance by
pi'. so the numbers you end up with in these images are simply that, the
reflected radiance multiplied by pi. what does this represent? it does
not represent the irradiance falling on the surface. for any
non-Lambertian surface, it does not represent the irradiance reflected off
the surface either.

I think the description in the manual is a little obscure,
talking more about the implementation than its result. The effect
happens on the very first surface that a ray hits, unless it
has a transparent material, which delays this step by one bounce.
In the computation, the material of this surface is temporarily
replaced by a lambertian material of the reflectivity PI. This
means that the resulting value is indeed the irradiance resp.
illuminance at that point.

In practise, however, you shouldn't have to worry about this
mechanism, and I don't think it should be mentioned in the manual
at all. Just read the description of the -i parameter without the
technicalities, and its meaning will become crystal clear:

-i Boolean switch to compute irradiance rather than radiance
     values. Light sources still appear with their original
     radiance values, though the -dv option may be used to
     override this.

I had to check the sources myself to be sure (I just silently
assumed it worked like that until now), but the trickeries
involved really produce this simple and very useful result.

this means that the illuminance values displayed in these images
are some manifestation of reflected illuminance. from a photometric point
of view, this is essentially meaningless.

Not reflected illuminance. Simply illuminance at that point.
From a photometric point of view, this is very reasonable, from
an imaging point of view, it is rather surrealistic. You have to
know that what you see is not something you'd be capable to see
without smoking heavy stuff.

the only real way of presenting illuminance information is on a
plane, real or imaginary, horizontal, vertical or tilted, not overlaid on a
visualisation.

If you substitute "real" with "conventional", then I agree with
the first part. Saying that overlaying this information on a
visualization is "unreal"... well yes, maybe I agree with this too.
Fortunately, that doesn't make it less useful to those who
understand what it means!

-schorsch

···

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

Georg,

You have eased my mind a whole heap. After giving it a try for myself, i am now agreeing with you that the -i option of rpict does produce incident irradiance values. I haven't yet tried this out on a visualisation including specular highlights, but have no reason to believe that the specular highlights will appear and make the results meaningless.

Seems that, without looking into the source code, i was mislead by the (all-too-brief) explanation in the Radiance manual.

Thanks again,
Phil G.

···

> quoting from the Radiance Reference manual, 'This only affects the final
> result, substituting a Lambertian surface and multiplying the radiance by
> pi'. so the numbers you end up with in these images are simply that, the
> reflected radiance multiplied by pi. what does this represent? it does
> not represent the irradiance falling on the surface. for any
> non-Lambertian surface, it does not represent the irradiance reflected off
> the surface either.

I think the description in the manual is a little obscure,
talking more about the implementation than its result. The effect
happens on the very first surface that a ray hits, unless it
has a transparent material, which delays this step by one bounce.
In the computation, the material of this surface is temporarily
replaced by a lambertian material of the reflectivity PI. This
means that the resulting value is indeed the irradiance resp.
illuminance at that point.

In practise, however, you shouldn't have to worry about this
mechanism, and I don't think it should be mentioned in the manual
at all. Just read the description of the -i parameter without the
technicalities, and its meaning will become crystal clear:

-i Boolean switch to compute irradiance rather than radiance
     values. Light sources still appear with their original
     radiance values, though the -dv option may be used to
     override this.