# incident ray angles

Hello,

I have a sensor and the sensor has different readings according to angle
between incident ray and normal. Theoretically, this readings should be
[cos(theta)*value of incident rays] hitting the sensor point (theta = angle
between ray hitting the surface and sensor normal). However,t our sensor
is not this relationship and I have to adjust the simualtion results to

- one of the methods I can think of is to get directions of all the
incident rays hitting the sensor point and then calculate all the angles
before using rtrac to calculate the actual illuminance values. Is that
feasible? I notice there is a "t" option in rtrace, but it will return
all the rays, not just rays hitting the sensor points.
- Radiance traces only 1 ray from the sensor points or sample a number
of rays from sensor point? (my understaning was that rtrace first traces a
number of rays to check DIRECT light source and get the results, and then
traces a SINGLE ray following the sensor normal and then sampling more when
hitting a surface? if in this case, how can I determine the anges of direct
and indirect rays?)

Thanks,

jia

Hi Jia,

you should check the rsensor program - that was developed by Greg to do
exactly what you want. The manpage describes well how to define your sensor
file and how to use rsensor.

Hope this helps,
best,
David

···

2014-02-20 8:45 GMT+01:00 Jia Hu <hujia06@gmail.com>:

Hello,

I have a sensor and the sensor has different readings according to angle
between incident ray and normal. Theoretically, this readings should be
[cos(theta)*value of incident rays] hitting the sensor point (theta = angle
between ray hitting the surface and sensor normal). However,t our sensor
is not this relationship and I have to adjust the simualtion results to

- one of the methods I can think of is to get directions of all the
incident rays hitting the sensor point and then calculate all the angles
before using rtrac to calculate the actual illuminance values. Is that
feasible? I notice there is a "t" option in rtrace, but it will return
all the rays, not just rays hitting the sensor points.
- Radiance traces only 1 ray from the sensor points or sample a number
of rays from sensor point? (my understaning was that rtrace first traces a
number of rays to check DIRECT light source and get the results, and then
traces a SINGLE ray following the sensor normal and then sampling more when
hitting a surface? if in this case, how can I determine the anges of direct
and indirect rays?)

Thanks,

jia

_______________________________________________

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

Have you investigated the program "rsensor"? It should be able to handle any distribution you like.

By default, the -I option of rtrace gives you a cosine-weighted irradiance value. If you need to add a cut-off, you can compute -I in the apex of a black cone of the appropriate size.

-Greg

···

From: Jia Hu <hujia06@gmail.com>
Date: February 20, 2014 8:45:33 AM GMT+01:00

Hello,

I have a sensor and the sensor has different readings according to angle between incident ray and normal. Theoretically, this readings should be [cos(theta)*value of incident rays] hitting the sensor point (theta = angle between ray hitting the surface and sensor normal). However,t our sensor is not this relationship and I have to adjust the simualtion results to fit the actual sensor readings.

one of the methods I can think of is to get directions of all the incident rays hitting the sensor point and then calculate all the angles between incident rays and sensor normal, and adjust the radiance values before using rtrac to calculate the actual illuminance values. Is that feasible? I notice there is a "t" option in rtrace, but it will return all the rays, not just rays hitting the sensor points.
Radiance traces only 1 ray from the sensor points or sample a number of rays from sensor point? (my understaning was that rtrace first traces a number of rays to check DIRECT light source and get the results, and then traces a SINGLE ray following the sensor normal and then sampling more when hitting a surface? if in this case, how can I determine the anges of direct and indirect rays?)

Thanks,

jia

Hi Greg and David,

That is great. I looked at the man page of rsensor program, that is what I
need. I have a few questions for which I am struggling.

1. you mentioned I still have to use a cone to cutoff light even if I
define the sensitivity data files? should I list all from 0-90 (row
degree) in the row or just view angle range (e.g., from 0 - 54 deg in row)?
does the program do some interpolation for angles are not defined in the
sensor files?
2. Our program was built based on Daysim, and use gen_dc to generate
daylight coefficient and us ds_illum to calculate the sensor readings. The
readings are cosine weighted, but it seems no way to integrate rsensor with
ds_ill or .dc files. I understand the 3 or 5 phase DC methods is good to
handle this. Since we already have the code from Daysim, it may be easy to
directly integrate resensor with current Daysim generated .dc files? Do you
have some suggestion?
3. If we use three phase DC method, we have to generate the BSDF files,
genBSDF +f +b will double the time, so for blinds in the south wall
settings, I only need use deault (+b only, not +f), is tha right? +b will
generate Transmission From (Window 6 convention), is that right?

Thank you very much,

Jia

···

On Thu, Feb 20, 2014 at 4:29 AM, Greg Ward <gregoryjward@gmail.com> wrote:

Have you investigated the program "rsensor"? It should be able to handle
any distribution you like.

By default, the -I option of rtrace gives you a cosine-weighted irradiance
value. If you need to add a cut-off, you can compute -I in the apex of a
black cone of the appropriate size.

-Greg

*From: *Jia Hu <hujia06@gmail.com>

*Date: *February 20, 2014 8:45:33 AM GMT+01:00

Hello,

I have a sensor and the sensor has different readings according to angle
between incident ray and normal. Theoretically, this readings should be
[cos(theta)*value of incident rays] hitting the sensor point (theta = angle
between ray hitting the surface and sensor normal). However,t our sensor
is not this relationship and I have to adjust the simualtion results to

- one of the methods I can think of is to get directions of all the
incident rays hitting the sensor point and then calculate all the angles
before using rtrac to calculate the actual illuminance values. Is that
feasible? I notice there is a "t" option in rtrace, but it will return
all the rays, not just rays hitting the sensor points.
- Radiance traces only 1 ray from the sensor points or sample a number
of rays from sensor point? (my understaning was that rtrace first traces a
number of rays to check DIRECT light source and get the results, and then
traces a SINGLE ray following the sensor normal and then sampling more when
hitting a surface? if in this case, how can I determine the anges of direct
and indirect rays?)

Thanks,

jia

_______________________________________________

Hi Jia,

I put my answers inline, and included your second e-mail at the bottom...

From: Jia Hu <hujia06@gmail.com>
Date: February 20, 2014 7:37:42 PM GMT+01:00

Hi Greg and David,

That is great. I looked at the man page of rsensor program, that is what I need. I have a few questions for which I am struggling.
you mentioned I still have to use a cone to cutoff light even if I define the sensitivity data files? should I list all from 0-90 (row degree) in the row or just view angle range (e.g., from 0 - 54 deg in row)? does the program do some interpolation for angles are not defined in the sensor files?

The cone is an easy (but computationally wasteful) alternative to using rsensor if all you need is a cut-off. There is no reason to use such a device with rsensor.

Our program was built based on Daysim, and use gen_dc to generate daylight coefficient and us ds_illum to calculate the sensor readings. The readings are cosine weighted, but it seems no way to integrate rsensor with ds_ill or .dc files. I understand the 3 or 5 phase DC methods is good to handle this. Since we already have the code from Daysim, it may be easy to directly integrate resensor with current Daysim generated .dc files? Do you have some suggestion?

I will leave this to the Daysim experts to answer. Using rsensor with the 3-phase method is more likely to succeed as you point out.

If we use three phase DC method, we have to generate the BSDF files, genBSDF +f +b will double the time, so for blinds in the south wall settings, I only need use deault (+b only, not +f), is tha right? +b will generate Transmission From (Window 6 convention), is that right?

Yes, that's correct.

Thank you very much,

Jia

Regarding your second question, the 10000 sensor samples are integrated to a single value, and this is the way it works. You can of course change this with the rsensor -rd option, but your accuracy will suffer. In the scheme of things, 10000 rays is not too big a number of samples if your scene has a lot going on. Convergence of Monte Carlo approaches generally proceeds as 1/sqrt(N) for N samples.

Best,
-Greg

···

On Thu, Feb 20, 2014 at 4:29 AM, Greg Ward <gregoryjward@gmail.com> wrote:
Have you investigated the program "rsensor"? It should be able to handle any distribution you like.

By default, the -I option of rtrace gives you a cosine-weighted irradiance value. If you need to add a cut-off, you can compute -I in the apex of a black cone of the appropriate size.

-Greg

From: Jia Hu <hujia06@gmail.com>
Date: February 20, 2014 8:45:33 AM GMT+01:00

Hello,

I have a sensor and the sensor has different readings according to angle between incident ray and normal. Theoretically, this readings should be [cos(theta)*value of incident rays] hitting the sensor point (theta = angle between ray hitting the surface and sensor normal). However,t our sensor is not this relationship and I have to adjust the simualtion results to fit the actual sensor readings.

one of the methods I can think of is to get directions of all the incident rays hitting the sensor point and then calculate all the angles between incident rays and sensor normal, and adjust the radiance values before using rtrac to calculate the actual illuminance values. Is that feasible? I notice there is a "t" option in rtrace, but it will return all the rays, not just rays hitting the sensor points.
Radiance traces only 1 ray from the sensor points or sample a number of rays from sensor point? (my understaning was that rtrace first traces a number of rays to check DIRECT light source and get the results, and then traces a SINGLE ray following the sensor normal and then sampling more when hitting a surface? if in this case, how can I determine the anges of direct and indirect rays?)

Thanks,

jia

+++++++++++++

From: Jia Hu <hujia06@gmail.com>
Date: February 21, 2014 6:43:10 AM GMT+01:00

Hello,

There are 30 sensors in the space, each of which has sensor spatial response file and use rsensor to calculate illuminance values. If I use three phase method to conduct annual simulation. My current method is to use: rsensor -h -vf view.vf . to generate the 10000 rays and use these rays to calcualte V matrix. in other words, I am using three phase method to calculate 10000 sensor points. At the end, only a single sensor values are calculated. Is there any better way?

Thanks!

Jia

Hello Jia,

The DAYSIMps addon to Daysim by Penn State, "Considers photosensor spatial sensitivity, location, aiming, control algorithm, and calibration." You can see on page 11 it works by using some '.sen' files that describe the sensor sensitivity, and there is a new sim_photosensor program in the Daysim toolchain to enable this. The 2013 workshop presentation by Richard Mistrick is probably of use.

Best,
Alstan

···

On Fri, 21 Feb 2014 04:12:35 -0500, Greg Ward <gregoryjward@gmail.com> wrote:

Hi Jia,

I put my answers inline, and included your second e-mail at the bottom...

From: Jia Hu <hujia06@gmail.com>

Date: February 20, 2014 7:37:42 PM GMT+01:00

Hi Greg and David,

That is great. I looked at the man page of rsensor program, that is what I need. I have a few questions for which I am struggling.
you mentioned I still have to use a cone to cutoff light even if I define the sensitivity data files? should I list all from 0-90 (row >>degree) in the row or just view angle range (e.g., from 0 - 54 deg in row)? does the program do some interpolation for angles are >>not defined in the sensor files?

The cone is an easy (but computationally wasteful) alternative to using rsensor if all you need is a cut-off. There is no reason to use such a device >with rsensor.

Our program was built based on Daysim, and use gen_dc to generate daylight coefficient and us ds_illum to calculate the sensor >>readings. The readings are cosine weighted, but it seems no way to integrate rsensor with ds_ill or .dc files. I understand the 3 or >>5 phase DC methods is good to handle this. Since we already have the code from Daysim, it may be easy to directly integrate >>resensor with current Daysim generated .dc files? Do you have some suggestion?

I will leave this to the Daysim experts to answer. Using rsensor with the 3-phase method is more likely to succeed as you point out.

If we use three phase DC method, we have to generate the BSDF files, genBSDF +f +b will double the time, so for blinds in the >>south wall settings, I only need use deault (+b only, not +f), is tha right? +b will generate Transmission From (Window 6 >>convention), is that right?

Yes, that's correct.

Thank you very much,

Jia

Regarding your second question, the 10000 sensor samples are integrated to a single value, and this is the way it works. You can of course change >this with the rsensor -rd option, but your accuracy will suffer. In the scheme of things, 10000 rays is not too big a number of samples if your scene >has a lot going on. Convergence of Monte Carlo approaches generally proceeds as 1/sqrt(N) for N samples.

Best,
-Greg

On Thu, Feb 20, 2014 at 4:29 AM, Greg Ward <gregoryjward@gmail.com> >> wrote:

Have you investigated the program "rsensor"? It should be able to handle any distribution you like.

By default, the -I option of rtrace gives you a cosine-weighted irradiance value. If you need to add a cut-off, you can compute -I in >>>the apex of a black cone of the appropriate size.

-Greg

From: Jia Hu <hujia06@gmail.com>

Date: February 20, 2014 8:45:33 AM GMT+01:00

Hello,

I have a sensor and the sensor has different readings according to angle between incident ray and normal. Theoretically, >>>>this readings should be [cos(theta)*value of incident rays] hitting the sensor point (theta = angle between ray hitting the >>>>surface and sensor normal). However,t our sensor is not this relationship and I have to adjust the simualtion results to fit >>>>the actual sensor readings.

one of the methods I can think of is to get directions of all the incident rays hitting the sensor point and then >>>>calculate all the angles between incident rays and sensor normal, and adjust the radiance values before using rtrac to >>>>calculate the actual illuminance values. Is that feasible? I notice there is a "t" option in rtrace, but it will return all >>>>the rays, not just rays hitting the sensor points.Radiance traces only 1 ray from the sensor points or sample a number of rays from sensor point? (my understaning >>>>was that rtrace first traces a number of rays to check DIRECT light source and get the results, and then traces a >>>>SINGLE ray following the sensor normal and then sampling more when hitting a surface? if in this case, how can I >>>>determine the anges of direct and indirect rays?)
Thanks,

jia

+++++++++++++

From: Jia Hu <hujia06@gmail.com>

Date: February 21, 2014 6:43:10 AM GMT+01:00

Hello,

There are 30 sensors in the space, each of which has sensor spatial response file and use rsensor to calculate illuminance >>values. If I use three phase method to conduct annual simulation. My current method is to use: rsensor -h -vf view.vf . to >>generate the 10000 rays and use these rays to calcualte V matrix. in other words, I am using three phase method to calculate >>10000 sensor points. At the end, only a single sensor values are calculated. Is there any better way?

Thanks!

Jia