daylight factor and rtrace cmd

Hello,

I'm trying to do daylight factor calculation. I am observing a 1 meter
height offset between my workplan point file which is already at 0.85m above
the floor (*.fld) and the rtrace result (*.irr).
Someone would tell me why?

the command used is:
rtrace -ab 7 -ad 2048 -oodv -I
rcp.oct<numeric/plan_de_travail.fld>numeric/090715_BU_Rennes_07_vitrage_irra
diance.irr

four first lines sample of the files:

plan_de_travail.fld:
x y z o
0.50 -0.25 1.84 0 0 1
0.50 0.00 1.84 0 0 1
0.50 0.25 1.84 0 0 1
0.50 0.50 1.84 0 0 1

090715_BU_Rennes_07_vitrage_irradiance.irr
x y z
o r
g b
5.000000e-001 -2.500000e-001 2.840000e+000 0.000000e+000
0.000000e+000 -1.000000e+000 1.406147e-001 1.406147e-001
1.406147e-001
5.000000e-001 0.000000e+000 2.840000e+000 0.000000e+000
0.000000e+000 -1.000000e+000 1.581891e-001 1.581891e-001
1.581891e-001
5.000000e-001 2.500000e-001 2.840000e+000 0.000000e+000
0.000000e+000 -1.000000e+000 1.765201e-001 1.765201e-001
1.765201e-001
5.000000e-001 5.000000e-001 2.840000e+000 0.000000e+000
0.000000e+000 -1.000000e+000 1.890535e-001 1.890535e-001
1.890535e-001

I am afraid my daylight factor result are not valid at the height of 1.84m
but at 2.84m, am I wrong?

Thanks,
Valere.

I believe the -I option to rtrace automatically takes the trace point
one unit in front of the point to avoid conflict with a surface (in case
your point is defined co-planar with a wall, floor, etc.). This would
probably be fine if you model was set up in inches or mm. Maybe you can
scale your model to millimeters using xform -s?

A question to the list, would the -i (lowercase) be appropriate to get
the value for the exact point as defined?

-Chris

···

________________________________

the command used is:
rtrace -ab 7 -ad 2048 -oodv -I
rcp.oct<numeric/plan_de_travail.fld>numeric/090715_BU_Rennes_07_vitrage_
irradiance.irr
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

As Chris wrote, -I implies an observer point 1m above the 'point of interest'.
But it also turns around the view vector (your output shows -1.000000e+000).

Basically rtrace introduces a virtual plane of lambertian properties and looks
down onto this plane to calculate the irridance from the reflection (which is
identical).

The offset of 1m is only a problem if you want to use the output to anchor
your results in a model or if your workplane is close to an obstruction that's
lower than 1m above the plane. Then the rtrace rays would hit the back
of the obstruction and not the ideal reflector.

But then, perhaps Greg has anticipated this case and added some magic to
avoid it ...

Thomas

···

On Thu, Jul 16, 2009 at 5:17 PM, PAUPELIN-HUCHARD Valere<[email protected]> wrote:

Hello,

I'm trying to do daylight factor calculation. I am observing a 1
meter height offset between my workplan point file which is already at 0.85m
above the floor (*.fld) and the rtrace result (*.irr).
Someone would tell me why?

the command used is:
rtrace -ab 7 -ad 2048 -oodv -I
rcp.oct<numeric/plan_de_travail.fld>numeric/090715_BU_Rennes_07_vitrage_irradiance.irr

four first lines sample of the files:

plan_de_travail.fld:
x y z o
0.50 -0.25 1.84 0 0 1
0.50 0.00 1.84 0 0 1
0.50 0.25 1.84 0 0 1
0.50 0.50 1.84 0 0 1

090715_BU_Rennes_07_vitrage_irradiance.irr
x y z
o
r g b
5.000000e-001 -2.500000e-001 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.406147e-001
1.406147e-001 1.406147e-001
5.000000e-001 0.000000e+000 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.581891e-001
1.581891e-001 1.581891e-001
5.000000e-001 2.500000e-001 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.765201e-001
1.765201e-001 1.765201e-001
5.000000e-001 5.000000e-001 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.890535e-001
1.890535e-001 1.890535e-001

I am afraid my daylight factor result are not valid at the height of 1.84m
but at 2.84m, am I wrong?

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

Valere, as Chris and Thomas have mentioned, you want to use the -i option for that field.

Honestly, I've never noticed this -I option before. The man page doesn't mention the 1m offset, either. Frankly, I don't understand the point of this option. If I want irradiance, I usually want it on some surface or virtual plane (a uniform grid on the front of a library stack, for example), and I just make a field of points normal to that surface and use the -i option to compute irradiance at that point. If for some reason I wanted irradiance offset from some surface (dark sky / light pollution calc or something), I would just arrange the points offset from the surface, and oriented at the surface, and still use the -i. What are people generally using the -I option for? I'm curious.

Robert Guglielmetti IES, LEED AP
Building Energy Efficiency Engineer
National Renewable Energy Laboratory (NREL)
1617 Cole Blvd, MS-5202
Golden, CO 80401
[email protected]
303.275.4319

···

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Bleicher
Sent: Thursday, July 16, 2009 10:46 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] daylight factor and rtrace cmd

As Chris wrote, -I implies an observer point 1m above the 'point of interest'.
But it also turns around the view vector (your output shows -1.000000e+000).

Basically rtrace introduces a virtual plane of lambertian properties and looks
down onto this plane to calculate the irridance from the reflection (which is
identical).

The offset of 1m is only a problem if you want to use the output to anchor
your results in a model or if your workplane is close to an obstruction that's
lower than 1m above the plane. Then the rtrace rays would hit the back
of the obstruction and not the ideal reflector.

But then, perhaps Greg has anticipated this case and added some magic to
avoid it ...

Thomas

On Thu, Jul 16, 2009 at 5:17 PM, PAUPELIN-HUCHARD Valere<[email protected]> wrote:

Hello,

I'm trying to do daylight factor calculation. I am observing a 1
meter height offset between my workplan point file which is already at 0.85m
above the floor (*.fld) and the rtrace result (*.irr).
Someone would tell me why?

the command used is:
rtrace -ab 7 -ad 2048 -oodv -I
rcp.oct<numeric/plan_de_travail.fld>numeric/090715_BU_Rennes_07_vitrage_irradiance.irr

four first lines sample of the files:

plan_de_travail.fld:
x y z o
0.50 -0.25 1.84 0 0 1
0.50 0.00 1.84 0 0 1
0.50 0.25 1.84 0 0 1
0.50 0.50 1.84 0 0 1

090715_BU_Rennes_07_vitrage_irradiance.irr
x y z
o
r g b
5.000000e-001 -2.500000e-001 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.406147e-001
1.406147e-001 1.406147e-001
5.000000e-001 0.000000e+000 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.581891e-001
1.581891e-001 1.581891e-001
5.000000e-001 2.500000e-001 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.765201e-001
1.765201e-001 1.765201e-001
5.000000e-001 5.000000e-001 2.840000e+000
0.000000e+000 0.000000e+000 -1.000000e+000 1.890535e-001
1.890535e-001 1.890535e-001

I am afraid my daylight factor result are not valid at the height of 1.84m
but at 2.84m, am I wrong?

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

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

Well now I've gone and confused everyone. You are right, -i (lowercase) is used for picking out illuminance at scene points, and so works as Raphael has described. -I (uppercase) is what I normally use for computing illuminance at a point. I simply use -I with -ov which gives me illuminance at that point. I have not used those other output fields and I'm still a little confused as to how this "1 meter offset" happens with -oodv.

Here's a thread-concluding post from a couple years ago that I have consulted in the past:

http://www.radiance-online.org/pipermail/radiance-general/2007-March/004213.html

- Rob

···

-----Original Message-----
From: [email protected] [mailto:radiance-
[email protected]] On Behalf Of Compagnon Raphaël
Sent: Thursday, July 16, 2009 11:30 AM
To: Radiance general discussion
Subject: RE : [Radiance-general] daylight factor and rtrace cmd

The rtrace -i behaves differently: rtrace will trace a ray for each input
point in the specified direction. Then it will compute the irradiance at
the first instersection point found in the scene. In your case, with the
same input file you would get the irradiance on the ceiling... which is
probably not what you really need.
This explains why the most useful -I option exists!

Yes, the -oo option combined with -I doesn't really work properly in rtrace, as it "fakes" an intersection with an ideal diffuse surface a tiny amount (about 1e-6) in front of the point you specified, while setting the ray origin arbitrarily one unit before it. No actual intersection calculation is done, so no worries about intervening rays. This is something I should fix, but since you give the origin on input, it hasn't come up very often where people want the same origin on output.

-Greg

···

From: Thomas Bleicher <[email protected]>
Date: July 16, 2009 9:45:58 AM PDT

As Chris wrote, -I implies an observer point 1m above the 'point of interest'.
But it also turns around the view vector (your output shows -1.000000e+000).

Basically rtrace introduces a virtual plane of lambertian properties and looks
down onto this plane to calculate the irridance from the reflection (which is
identical).

The offset of 1m is only a problem if you want to use the output to anchor
your results in a model or if your workplane is close to an obstruction that's
lower than 1m above the plane. Then the rtrace rays would hit the back
of the obstruction and not the ideal reflector.

But then, perhaps Greg has anticipated this case and added some magic to
avoid it ...

Thomas

Yes, the -oo option combined with -I doesn't really work properly in rtrace,
as it "fakes" an intersection with an ideal diffuse surface a tiny amount
(about 1e-6) in front of the point you specified, while setting the ray
origin arbitrarily one unit before it. No actual intersection calculation
is done, so no worries about intervening rays.

So the 1 unit offset is only a fake to make the output options happy
and does not interfere with the scene geometry. That's good.

This is something I should
fix, but since you give the origin on input, it hasn't come up very often
where people want the same origin on output.

It's a bit inconsistent to throw a file at rtrace specifying what you want
and getting back from rtace what it actually did. Like ordering a door
and getting delivered some planks and a saw. (Should we call this
'IKEA rendering'?)

While we're at it, I think that this virtual intersection also swallows one
bounce out of your '-ab' specs. That only becomes obvious when you
try to eliminate indirect contributions ('-ab 0' and '-ab 1') but then it's
rather annoying when you don't remember it.

What's the community's opinion? Should rtrace raise the bounce count
for '-I' internally or should it just be well document? I'm not sure what's
more consistent with the way Radiance behaves now or if there are any
side effects.

Thomas

···

On Fri, Jul 17, 2009 at 3:45 AM, Greg Ward<[email protected]> wrote:

Hi Thomas,

I agree that the -oo output is odd behavior. I'm a bit afraid to change it, though, because there might be someplace in the code where zero ray lengths are problematic, and the initial "false primary" ray is needed for consistency for rtrace's reporting routines. I suppose I can try it and see if anything bad happens.

I'm not sure what you mean, though, about the -I option changing the effect of -ab. I suppose it depends on how you think about it. With -ab set to 0, only direct illumination arriving at that position is considered. Setting -ab 1 sends out sample rays over the hemisphere to gather indirect contributions. Is this other than what you would expect?

-Greg

···

From: Thomas Bleicher <[email protected]>
Date: July 16, 2009 10:40:33 PM PDT

On Fri, Jul 17, 2009 at 3:45 AM, Greg Ward<[email protected]> wrote:

Yes, the -oo option combined with -I doesn't really work properly in rtrace,
as it "fakes" an intersection with an ideal diffuse surface a tiny amount
(about 1e-6) in front of the point you specified, while setting the ray
origin arbitrarily one unit before it. No actual intersection calculation
is done, so no worries about intervening rays.

So the 1 unit offset is only a fake to make the output options happy
and does not interfere with the scene geometry. That's good.

This is something I should
fix, but since you give the origin on input, it hasn't come up very often
where people want the same origin on output.

It's a bit inconsistent to throw a file at rtrace specifying what you want
and getting back from rtace what it actually did. Like ordering a door
and getting delivered some planks and a saw. (Should we call this
'IKEA rendering'?)

While we're at it, I think that this virtual intersection also swallows one
bounce out of your '-ab' specs. That only becomes obvious when you
try to eliminate indirect contributions ('-ab 0' and '-ab 1') but then it's
rather annoying when you don't remember it.

What's the community's opinion? Should rtrace raise the bounce count
for '-I' internally or should it just be well document? I'm not sure what's
more consistent with the way Radiance behaves now or if there are any
side effects.

Thomas

I have modified the HEAD distribution with a version of rtrace that doesn't add 1.0 in the surface normal direction to the value reported by the -oo option. I sure hope this doesn't break anything. It still adds a small quantity (1.1e-4) so as to prevent any possible intersection with surfaces that are not quite where the user thinks they are, and this is as before.

I hope we are reaching the end of this thread...

-Greg

Hi Greg. Still awake or are you traveling again?

I'm not sure what you mean, though, about the -I option changing the effect
of -ab. I suppose it depends on how you think about it. With -ab set to 0,
only direct illumination arriving at that position is considered. Setting
-ab 1 sends out sample rays over the hemisphere to gather indirect
contributions. Is this other than what you would expect?

Perhaps it's me being extremely blond about the meaning of "-i" vs "-I".

Consider a scene with a sky and a plane just below z=0.
I am now looking down from z=1 onto the plane and get:

$ echo "0 0 1 0 0 -1" | rtrace -h -i -ab 0 scene.oct
2.541776e+01 2.541776e+01 2.541776e+01

$ echo "0 0 1 0 0 -1" | rtrace -h -i -ab 1 scene.oct
7.457800e+01 7.457800e+01 7.457800e+01

$ echo "0 0 1 0 0 -1" | rtrace -h -I -ab 0 scene.oct
0.000000e+00 0.000000e+00 0.000000e+00

$ echo "0 0 1 0 0 -1" | rtrace -h -I -ab 1 scene.oct
2.033156e+01 2.033156e+01 2.033156e+01

Why do I get different values for "-i" for "-ab 0" and "-ab 1"?
There is nothing in the scene to bounce light off.

And why do I get "0 0 0" for "-ab 0" when i use "-I" but not
when I use "-i". For "-ab 0" I would have expected both of them
to be zero.

Thomas

···

On Fri, Jul 17, 2009 at 7:02 AM, Greg Ward<[email protected]> wrote:

Hi Thomas,

From: Thomas Bleicher <[email protected]>
Date: July 17, 2009 12:05:19 AM PDT

Hi Greg. Still awake or are you traveling again?

Slept, thanks.

I'm not sure what you mean, though, about the -I option changing the effect
of -ab. I suppose it depends on how you think about it. With -ab set to 0,
only direct illumination arriving at that position is considered. Setting
-ab 1 sends out sample rays over the hemisphere to gather indirect
contributions. Is this other than what you would expect?

Perhaps it's me being extremely blond about the meaning of "-i" vs "-I".

Consider a scene with a sky and a plane just below z=0.
I am now looking down from z=1 onto the plane and get:

$ echo "0 0 1 0 0 -1" | rtrace -h -i -ab 0 scene.oct
2.541776e+01 2.541776e+01 2.541776e+01

$ echo "0 0 1 0 0 -1" | rtrace -h -i -ab 1 scene.oct
7.457800e+01 7.457800e+01 7.457800e+01

$ echo "0 0 1 0 0 -1" | rtrace -h -I -ab 0 scene.oct
0.000000e+00 0.000000e+00 0.000000e+00

$ echo "0 0 1 0 0 -1" | rtrace -h -I -ab 1 scene.oct
2.033156e+01 2.033156e+01 2.033156e+01

Why do I get different values for "-i" for "-ab 0" and "-ab 1"?
There is nothing in the scene to bounce light off.

The sky dome and the distant ground for a standard sky description are considered as part of the "indirect" calculation, so you only get those contributions with -ab 1 (or higher).

And why do I get "0 0 0" for "-ab 0" when i use "-I" but not
when I use "-i". For "-ab 0" I would have expected both of them
to be zero.

I'm guessing this is because your sun is above the horizon and your -I usage has the normal facing the ground. Using -i, a ray is sent that hits the ground then looks skyward, where it sees the sun again. The sun doesn't need -ab 1 to contribute.

Does this make sense, yet?

-Greg

···

On Fri, Jul 17, 2009 at 7:02 AM, Greg Ward<[email protected]> wrote: