sky visibility

[Patrick_Janssen]

Hi all,

I have an urban model with many windows, and I would like to calculate %
visible sky for each window. I define a point at the centre of the window
with a viewing direction normal to the window, and I would like to
calculate how much (i.e. what %) of the sky dome is visible from that
point, assuming a 180 degree cone of vision. Note that I do not want to
apply the cosine-law, and I want to treat each part of the sky dome
equally. For a vertical window, the maximum value should be 50%, which
would mean that there are no obstructions.

What is the best (i.e. fastest) way of calculating this?

I tried rtrace (1 bounce, uniform sky) but that applies the cosine law. I
have been looking at rsensor, but if I have lots of windows, it seems I
would have to run rsensor lots of times, which would be rather slow. Any
suggestions?

Patrick

[Lars_Grobe]

Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the rays that are above the treshold (0.00001 here) and total number of rays traced, and then get the fraction of rays over the treshold using rtrace again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total | rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit more efficient using proper -if3, -of options for all commands. The same can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the first ray intersection instead of e.g. the radiance value from rtrace and pass that through grep.

Cheers, Lars.

[Ji_ZHANG]

Hi, Lars,

I agree with your suggestion: calculating the number of rays shooting out
from a sensor that can reach the sky directly, and divide the value
obtained by the total number of rays shot. This will give us the percentage
of visible sky or sky exposure for a given sensor.

However, if I understand correctly, the output of rtrace is a file, within
which each row indicating the xyz coordinates and rgb irradiance of a given
sensor.

Is the output of rtrace which is supposed to be piped to rcalc as shown in
your script has only one column of data and each row is the irradiance
value of one of the sensors?

So, the script might be something like:

cat sensors.txt | rtrace -I -aa XXX -ab XXX -ad XXX -h -w scene.oct |
rcalc -e '$1=if($1-.00001,1,0); $2=1' | total | rcalc -e '$1=$1/$2' >
results.txt

If that's the case, you're calculating the percentage of sensors that can
see the sky (regardless of the size of sky visible to each sensor), am I
correct?

... or I miss something critical here ...

- Ji

···

On Sat, Oct 20, 2012 at 4:05 PM, Lars O. Grobe <[email protected]> wrote:

Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays
hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the
rays that are above the treshold (0.00001 here) and total number of rays
traced, and then get the fraction of rays over the treshold using rtrace
again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total |
rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit
more efficient using proper -if3, -of options for all commands. The same
can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the first
ray intersection instead of e.g. the radiance value from rtrace and pass
that through grep.

Cheers, Lars.

______________________________**_________________
Radiance-general mailing list
Radiance-general@radiance-**online.org<[email protected]>
http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>

[G11]

what about vwrays and an angular view?
then -av 1 1 1, no sky and total - positive = sky
g

···

On 20 Oct 2012, at 10:56, Ji Zhang <[email protected]> wrote:

Hi, Lars,

I agree with your suggestion: calculating the number of rays shooting out from a sensor that can reach the sky directly, and divide the value obtained by the total number of rays shot. This will give us the percentage of visible sky or sky exposure for a given sensor.

However, if I understand correctly, the output of rtrace is a file, within which each row indicating the xyz coordinates and rgb irradiance of a given sensor.

Is the output of rtrace which is supposed to be piped to rcalc as shown in your script has only one column of data and each row is the irradiance value of one of the sensors?

So, the script might be something like:

cat sensors.txt | rtrace -I -aa XXX -ab XXX -ad XXX -h -w scene.oct | rcalc -e '$1=if($1-.00001,1,0); $2=1' | total | rcalc -e '$1=$1/$2' > results.txt

If that's the case, you're calculating the percentage of sensors that can see the sky (regardless of the size of sky visible to each sensor), am I correct?

... or I miss something critical here ...

- Ji

On Sat, Oct 20, 2012 at 4:05 PM, Lars O. Grobe <[email protected]> wrote:
Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the rays that are above the treshold (0.00001 here) and total number of rays traced, and then get the fraction of rays over the treshold using rtrace again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total | rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit more efficient using proper -if3, -of options for all commands. The same can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the first ray intersection instead of e.g. the radiance value from rtrace and pass that through grep.

Cheers, Lars.

_______________________________________________
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

[Ji_ZHANG]

Dear Giulio, appreciate if you can kindly elaborate more on your
suggestions !

- Ji

···

On Sat, Oct 20, 2012 at 6:09 PM, giulio antonutto <[email protected]>wrote:

what about vwrays and an angular view?
then -av 1 1 1, no sky and total - positive = sky
g

On 20 Oct 2012, at 10:56, Ji Zhang <[email protected]> wrote:

Hi, Lars,

I agree with your suggestion: calculating the number of rays shooting out
from a sensor that can reach the sky directly, and divide the value
obtained by the total number of rays shot. This will give us the percentage
of visible sky or sky exposure for a given sensor.

However, if I understand correctly, the output of rtrace is a file, within
which each row indicating the xyz coordinates and rgb irradiance of a given
sensor.

Is the output of rtrace which is supposed to be piped to rcalc as shown in
your script has only one column of data and each row is the irradiance
value of one of the sensors?

So, the script might be something like:

cat sensors.txt | rtrace -I -aa XXX -ab XXX -ad XXX -h -w scene.oct |
rcalc -e '$1=if($1-.00001,1,0); $2=1' | total | rcalc -e '$1=$1/$2' >
results.txt

If that's the case, you're calculating the percentage of sensors that can
see the sky (regardless of the size of sky visible to each sensor), am I
correct?

... or I miss something critical here ...

- Ji

On Sat, Oct 20, 2012 at 4:05 PM, Lars O. Grobe <[email protected]> wrote:

Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays
hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the
rays that are above the treshold (0.00001 here) and total number of rays
traced, and then get the fraction of rays over the treshold using rtrace
again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total |
rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit
more efficient using proper -if3, -of options for all commands. The same
can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the
first ray intersection instead of e.g. the radiance value from rtrace and
pass that through grep.

Cheers, Lars.

______________________________**_________________
Radiance-general mailing list
Radiance-general@radiance-**online.org<[email protected]>
http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>

_______________________________________________
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

[Hu_Jia]

Hi Ji:

What Lars might want to say is to pipe the following output into
rtrace: genklemsample -vd 0 -1 0 window.rad, where vd is the normal of
window.

Best,
Jia

···

On Sat, Oct 20, 2012 at 8:46 AM, Ji Zhang <[email protected]> wrote:

Dear Giulio, appreciate if you can kindly elaborate more on your
suggestions !

- Ji

On Sat, Oct 20, 2012 at 6:09 PM, giulio antonutto <[email protected]>wrote:

what about vwrays and an angular view?
then -av 1 1 1, no sky and total - positive = sky
g

On 20 Oct 2012, at 10:56, Ji Zhang <[email protected]> wrote:

Hi, Lars,

I agree with your suggestion: calculating the number of rays shooting out
from a sensor that can reach the sky directly, and divide the value
obtained by the total number of rays shot. This will give us the percentage
of visible sky or sky exposure for a given sensor.

However, if I understand correctly, the output of rtrace is a file,
within which each row indicating the xyz coordinates and rgb irradiance of
a given sensor.

Is the output of rtrace which is supposed to be piped to rcalc as shown
in your script has only one column of data and each row is the irradiance
value of one of the sensors?

So, the script might be something like:

cat sensors.txt | rtrace -I -aa XXX -ab XXX -ad XXX -h -w scene.oct |
rcalc -e '$1=if($1-.00001,1,0); $2=1' | total | rcalc -e '$1=$1/$2' >
results.txt

If that's the case, you're calculating the percentage of sensors that can
see the sky (regardless of the size of sky visible to each sensor), am I
correct?

... or I miss something critical here ...

- Ji

On Sat, Oct 20, 2012 at 4:05 PM, Lars O. Grobe <[email protected]> wrote:

Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays
hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the
rays that are above the treshold (0.00001 here) and total number of rays
traced, and then get the fraction of rays over the treshold using rtrace
again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total |
rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit
more efficient using proper -if3, -of options for all commands. The same
can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the
first ray intersection instead of e.g. the radiance value from rtrace and
pass that through grep.

Cheers, Lars.

______________________________**_________________
Radiance-general mailing list
Radiance-general@radiance-**online.org<[email protected]>
http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>

_______________________________________________
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

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

[G11]

ok,
setup a view out of the window, with -a.
save the view file.
use vwrays to generate the vectors and starting point to sample the sky
shoot with rtrace
use -av 1 1 1 so that you do not need to have a sky but all glows.
then pipe the rtrace to rcalc and use if($1,1,0) then total.
the overall number of hits that are recorded is the number of intersection to the model
you need then to check the overall resolution of your image and account for the fact that you should be considering the inner 180 deg. circle.
Sorry have no time to write up this for you,
but to be fair there is already (and below too) a lot that you could try.
If you have no time to experiment or are simply looking for the easy copy/paste solution amen.
I meant differently.
in any case, all the best
G

···

On 20 Oct 2012, at 13:46, Ji Zhang <[email protected]> wrote:

Dear Giulio, appreciate if you can kindly elaborate more on your suggestions !

- Ji

On Sat, Oct 20, 2012 at 6:09 PM, giulio antonutto <[email protected]> wrote:
what about vwrays and an angular view?
then -av 1 1 1, no sky and total - positive = sky
g

On 20 Oct 2012, at 10:56, Ji Zhang <[email protected]> wrote:

Hi, Lars,

I agree with your suggestion: calculating the number of rays shooting out from a sensor that can reach the sky directly, and divide the value obtained by the total number of rays shot. This will give us the percentage of visible sky or sky exposure for a given sensor.

However, if I understand correctly, the output of rtrace is a file, within which each row indicating the xyz coordinates and rgb irradiance of a given sensor.

Is the output of rtrace which is supposed to be piped to rcalc as shown in your script has only one column of data and each row is the irradiance value of one of the sensors?

So, the script might be something like:

cat sensors.txt | rtrace -I -aa XXX -ab XXX -ad XXX -h -w scene.oct | rcalc -e '$1=if($1-.00001,1,0); $2=1' | total | rcalc -e '$1=$1/$2' > results.txt

If that's the case, you're calculating the percentage of sensors that can see the sky (regardless of the size of sky visible to each sensor), am I correct?

... or I miss something critical here ...

- Ji

On Sat, Oct 20, 2012 at 4:05 PM, Lars O. Grobe <[email protected]> wrote:
Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the rays that are above the treshold (0.00001 here) and total number of rays traced, and then get the fraction of rays over the treshold using rtrace again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total | rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit more efficient using proper -if3, -of options for all commands. The same can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the first ray intersection instead of e.g. the radiance value from rtrace and pass that through grep.

Cheers, Lars.

_______________________________________________
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

_______________________________________________
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

[Ji_ZHANG]

Thank you very much, Giulio! will digest ur suggestions and give it a try
on the combined use of vwray + rtrace + rcalc.
- Cheers, Ji.

···

On Sun, Oct 21, 2012 at 6:09 AM, giulio antonutto <[email protected]>wrote:

ok,
setup a view out of the window, with -a.
save the view file.
use vwrays to generate the vectors and starting point to sample the sky
shoot with rtrace
use -av 1 1 1 so that you do not need to have a sky but all glows.
then pipe the rtrace to rcalc and use if($1,1,0) then total.
the overall number of hits that are recorded is the number of intersection
to the model
you need then to check the overall resolution of your image and account
for the fact that you should be considering the inner 180 deg. circle.
Sorry have no time to write up this for you,
but to be fair there is already (and below too) a lot that you could try.
If you have no time to experiment or are simply looking for the easy
copy/paste solution amen.
I meant differently.
in any case, all the best
G

On 20 Oct 2012, at 13:46, Ji Zhang <[email protected]> wrote:

Dear Giulio, appreciate if you can kindly elaborate more on your
suggestions !

- Ji

On Sat, Oct 20, 2012 at 6:09 PM, giulio antonutto <[email protected]>wrote:

what about vwrays and an angular view?
then -av 1 1 1, no sky and total - positive = sky
g

On 20 Oct 2012, at 10:56, Ji Zhang <[email protected]> wrote:

Hi, Lars,

I agree with your suggestion: calculating the number of rays shooting out
from a sensor that can reach the sky directly, and divide the value
obtained by the total number of rays shot. This will give us the percentage
of visible sky or sky exposure for a given sensor.

However, if I understand correctly, the output of rtrace is a file,
within which each row indicating the xyz coordinates and rgb irradiance of
a given sensor.

Is the output of rtrace which is supposed to be piped to rcalc as shown
in your script has only one column of data and each row is the irradiance
value of one of the sensors?

So, the script might be something like:

cat sensors.txt | rtrace -I -aa XXX -ab XXX -ad XXX -h -w scene.oct |
rcalc -e '$1=if($1-.00001,1,0); $2=1' | total | rcalc -e '$1=$1/$2' >
results.txt

If that's the case, you're calculating the percentage of sensors that can
see the sky (regardless of the size of sky visible to each sensor), am I
correct?

... or I miss something critical here ...

- Ji

On Sat, Oct 20, 2012 at 4:05 PM, Lars O. Grobe <[email protected]> wrote:

Hi Patrick,

Did you consider genklemsamp?

If you just want to not apply the cosine but get either 1 or 0 for rays
hitting the sky or not, pipe the output from rtrace to rcalc. E.g. sum the
rays that are above the treshold (0.00001 here) and total number of rays
traced, and then get the fraction of rays over the treshold using rtrace
again:

<your rtrace command> | rcalc -e ´$1=if($1-.00001,1,0); $2=1´ | total |
rcalc -e ´$1=$1/$2´

That could be done using binary floats instead of ascii to make it a bit
more efficient using proper -if3, -of options for all commands. The same
can be done on e.g. fisheye images using pcomb.

A general hint, you can also get the surface identifier (-os) at the
first ray intersection instead of e.g. the radiance value from rtrace and
pass that through grep.

Cheers, Lars.

______________________________**_________________
Radiance-general mailing list
Radiance-general@radiance-**online.org<[email protected]>
http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>

_______________________________________________
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

_______________________________________________
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

[Lars_Grobe]

Hi!

However, if I understand correctly, the output of rtrace is a file, within which each row indicating the xyz coordinates and rgb irradiance of a given sensor.

I'd suggest to any Radiance user to thoroughly read the rtrace manpage. Especially the part about output (-o...). rtrace is NOT only returning radiance, irradiance or contribution coefficients. It can output information about the first ray intersection, as well as intersection of daughter rays, with geometry in your scene. This may be coordinates, directions, lengths, surface identifiers, materials and modifiers, ... And the output is not a file but a stream of data, which, piped into other tools such as rcalc, grep, sed, ... can be processed further. Maybe even into input for the next rtrace process.

Giulio was proposing something similar, but relying on an image format. You could, again, use my rcalc line with his approach to get both the number of rays intersecting with geometry and the total number of rays:

$1=if($1,1,0) sets all pixels (rays) to one if they are above 0 (meaning they hit some geometry, as you have no light source but only self-glowing geometry).

$2=1 sets the second value to 1 for any pixels (rays) regardless they hit geometry or not.

So rcalc -e ´$1=if($1,1,0); $2=1´ | total would result in two values, first the number of pixels (rays) hitting geometry, second the total number of pixels sent. The fraction is what you need. The input for this rcalc command can be from vwrays | racalc, rpict or anything else shooting rays into a hemisphere...

The more interesting question may be whether it is enough to trace from only one point on your window. Maybe you want several random sampling positions on the window pane.

Cheers, Lars.

[Santiago_Torres]

Hi all,

I found the reply below from an old thread (12-15-2011). Would this help?

Also, how about defining a sensor with all coefficients 1, and getting the weighted illuminance, would that work?

Regards,
Santiago

···

=========

Hi Minki,

If this quantity is equal to the integral of luminance over the full sphere, then it would be the same as 4*PI times the average luminance in all directions. You can compute the latter quantity by averaging the output of an appropriate rtrace calculation of random rays over the sphere. Something like the following should work:

set N=10000

set orig=(0 0 0)

cnt $N | rcalc -of -e 'Dz=1-2*($1+rand(.77-.61*recno))/'$N -e 'phi=2*PI*($1+rand(-.10+.39*recno))'/$N \

            -e 'rxy=sqrt(1-Dz*Dz);Dx=rxy*cos(phi);Dy=rxy*sin(phi)' \

            -e "Ox:$orig[1];Oy:$orig[2];Oz:$orig[3]" \

            -e '$1=Ox;$2=Oy;$3=Oz;$4=Dx;$5=Dy;$6=Dz' \

      > rtrace -h -ff [options] scene.oct \

      > total -if3 -m \

      > rcalc -e '$1=179*4*PI*($1*.265+$2*.670+$3*.065)'

This should take ray samples in a stratified random spiral over the sphere. The 3 averaged radiance values (RGB) output should be multiplied by 179 and 4*PI as above, unless I misunderstand the definition of spherical illuminance.

Best,

-Greg

From: Patrick Janssen [mailto:[email protected]]
Sent: 2012年10月20日 15:45
To: [email protected]
Subject: [Radiance-general] sky visibility

Hi all,

I have an urban model with many windows, and I would like to calculate % visible sky for each window. I define a point at the centre of the window with a viewing direction normal to the window, and I would like to calculate how much (i.e. what %) of the sky dome is visible from that point, assuming a 180 degree cone of vision. Note that I do not want to apply the cosine-law, and I want to treat each part of the sky dome equally. For a vertical window, the maximum value should be 50%, which would mean that there are no obstructions.

What is the best (i.e. fastest) way of calculating this?

I tried rtrace (1 bounce, uniform sky) but that applies the cosine law. I have been looking at rsensor, but if I have lots of windows, it seems I would have to run rsensor lots of times, which would be rather slow. Any suggestions?

Patrick
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

[Ji_ZHANG]

Thank you very much, Lars and Giulio!

I did some test and seem to be able to make it work following your
suggestion.

However, my major concern is that this is NOT the so called Sky Exposure
Factor we'd like to calculate, and the value thus obtained may vary as the
view type changes (e.g. -vts or -vta) which is not suppose to happen if the
scene geometry remains the same.

Allow me to explain the script, and pls kindly help to verify if it is
doing what you suggested.

The bash script below calculate the proportion of visible sky based on
counting pixels in a "virtual fisheye rendering":

#### the script #####################
oconv ./plastic_mat.rad ./geom1.rad > ./scene1.oct
vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda
-opdv ./scene1.oct > ./zzz_vta_pts_P_N_v_1.txt
vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda
-opdv ./scene1.oct | rcalc -e '$1=if($7,1,0); $2=1' | total >
./zzz_vta_pts_total_1.txt
oconv ./plastic_mat.rad ./geom2.rad > ./scene2.oct
vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda
-opdv ./scene2.oct > ./zzz_vta_pts_P_N_v_2.txt
vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda
-opdv ./scene2.oct | rcalc -e '$1=if($7,1,0); $2=1' | total >
./zzz_vta_pts_total_2.txt
rlam ./zzz_vta_pts_total_1.txt ./zzz_vta_pts_total_2.txt >
./zzz_vta_pts_total_temp.txt
rcalc -e '$1=($3-$1)/$3' ./zzz_vta_pts_total_temp.txt >
./zzz_vta_pts_total_final.txt

···

#################################

1. scene1.oct describes a cylinder like geometry (diameter=2, height=1)
with its top and bottom open. This is suppose to be the obstruction for the
view point, and from which the sky exposure factor is to be calculated

2. scene2.oct describes a cone in the same position as the cylinder, in the
same height and with the same bottom circle diameter. It is to obstruct the
view entirely so that we can "ironically" calculate the total number of
rays that may reach the sky if there's no obstruction to the view.

3. view_vta.vf defines an upward angular fisheye view of 180 degrees
located at the centre of the bottom circle of the cylinder

4. in the 2nd line of the script, the "-opdv" option in the rtrace outputs
the xyz coordinates, xyz normal vectors, and radiance value for each point
as a result of the intersection of a ray and the cylinder geometry to a
text file. If a ray didn't hit any geometry, it will return seven zeros: "0
0 0 0 0 0 0".

5. in the 3rd line of script, an evaluation is conducted: if the 7th value
as output for each ray is a positive value (which means the ray hits the
geometry and return a value as a results of the -av 1 1 1 option), that ray
will be marked as "1", otherwise, it'll be marked as "0". The "total" in
this line sums all the values and outputs the two values to
"zzz_vta_pts_total_1.txt": the first value is the total number of rays hit
the inner side of the cylinder (or the total number of pixels in the
400x400 virtual fisheye rendering that is in grey color), and the second
value is the total number of pixels in the "virtual fisheye rendering"
which in this case is 400*400=640000

6. similarly, in the 6th line of script, the two values output to
"zzz_vta_pts_total_2.txt" is the total number of rays that may reach the
sky (which is also the total number of the rays hit the inner side of the
cone which block the view completely in this case), and the total number of
pixels.

7. in the last line of script, the "$3-$1" part is to calculate in scene1
the actual number of rays that may reach the sky (or in the virtual fisheye
image the number of pixels representing the visible sky patch)

8. finally, the ratio of the visible sky path to the unobstructed sky dome
is calculated...

9. Validation:
We have a similar in-house approach to calculate the Sky Exposure Factor
(SkyEF) built on a 3D modeling software, in which we literally shoot out a
bunch of points evenly spaced in a 2*PI upward solid angle from the
viewpoint towards a sky hemisphere surface. We than calculate the ratio
between the number of points reaching the sky dome surface and the total
number of points shot to get the SkyEF. For the cylinder scenario tested
here, the SkyEF should be 0.2929 or 29.29%, which is actually the ratio
between the solid angle subtended by the view to sky: 2*PI*(1-cos45) to the
solid angle of an unobstructed sky hemisphere: 2*PI. However, the
vrways+rtrace approach as described here can't get the this value. I've
visualized the all the intersection points based on the
zzz_vta_pts_P_N_v_1.txt file, and I found that the total number of points
hitting obstructing geometry is different for different view type
specifications. I assume it's related to how the nature of the fisheye
image distortion...

I apologize if I didn't explain clearly. I'd appreciate if both of you and
the list can further advise on an appropriate view-type-independent
Radiance approach to calculate Sky Exposure Factor !

- Cheers, Ji

On Sun, Oct 21, 2012 at 10:34 PM, Lars O. Grobe <[email protected]> wrote:

Hi!

However, if I understand correctly, the output of rtrace is a file,

within which each row indicating the xyz coordinates and rgb irradiance of
a given sensor.

I'd suggest to any Radiance user to thoroughly read the rtrace manpage.
Especially the part about output (-o...). rtrace is NOT only returning
radiance, irradiance or contribution coefficients. It can output
information about the first ray intersection, as well as intersection of
daughter rays, with geometry in your scene. This may be coordinates,
directions, lengths, surface identifiers, materials and modifiers, ... And
the output is not a file but a stream of data, which, piped into other
tools such as rcalc, grep, sed, ... can be processed further. Maybe even
into input for the next rtrace process.

Giulio was proposing something similar, but relying on an image format.
You could, again, use my rcalc line with his approach to get both the
number of rays intersecting with geometry and the total number of rays:

$1=if($1,1,0) sets all pixels (rays) to one if they are above 0 (meaning
they hit some geometry, as you have no light source but only self-glowing
geometry).

$2=1 sets the second value to 1 for any pixels (rays) regardless they hit
geometry or not.

So rcalc -e ´$1=if($1,1,0); $2=1´ | total would result in two values,
first the number of pixels (rays) hitting geometry, second the total number
of pixels sent. The fraction is what you need. The input for this rcalc
command can be from vwrays | racalc, rpict or anything else shooting rays
into a hemisphere...

The more interesting question may be whether it is enough to trace from
only one point on your window. Maybe you want several random sampling
positions on the window pane.

Cheers, Lars.

______________________________**_________________
Radiance-general mailing list
Radiance-general@radiance-**online.org<[email protected]>
http://www.radiance-online.**org/mailman/listinfo/radiance-**general<http://www.radiance-online.org/mailman/listinfo/radiance-general>

[Lars_Grobe]

Hi Ji Zhang!

vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda -opdv ./scene1.oct > ./zzz_vta_pts_P_N_v_1.txt
vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda -opdv ./scene1.oct | rcalc -e '$1=if($7,1,0); $2=1' | total > ./zzz_vta_pts_total_1.txt

The problem here probably is, that your fisheye view -vta produces pixel values outside the circular image you would expect. These get counted in the total number of pixels. So if you are using -vta, you need way to filter pixels lying outside the circle. Several approaches to do so come to my mind. A generic one is:

1) vwrays -vta into a scene consisting only of a source, corresponding to the hemisphere you want to sample
2) pipe the output to rtrace, check for intersections with the source and get origin and direction vectors
3) pipe that into rtrace again, this time checking for your pixel values as above...

Still, there is a problem with the -vta (equiangular) fisheye not being a equisolid fisheye, so pixels do not represent equal solid angles.... for sky view factors, that is what you would want, but for your definition, you want the ration (solid angle visible sky) / (solid angle sky without obstructions). So either calculate the solid angle of the pixel depending on the distance from view centre, or go with rpict, create a fisheye image (-vta), and use the S and T functions to filter pixels outside the view and to weigh pixels by their solid angle. So in above commands, you would not set the pixel value to 0 or 1, but to 0 or S(n).

Again, I could not try out all this and send a complete example, just trying to point you to some direction.

Cheers, Lars.

[Ji_ZHANG]

Hi, Lars, thanks a lot for your advices!

May I ask the references on the S and T function as you suggested to look
up? (I didn't find any relevant infor via Radiance forum search...)

May I also ask what the "n" in the "S(n)" denotes?

Thanks again!

- Cheers, Ji

···

On Tue, Oct 23, 2012 at 4:40 PM, Lars O. Grobe <[email protected]> wrote:

Hi Ji Zhang!

> vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda
-opdv ./scene1.oct > ./zzz_vta_pts_P_N_v_1.txt
> vwrays -fd -vf ./view_vta.vf -x 800 -y 800 | rtrace -av 1 1 1 -w -h -fda
-opdv ./scene1.oct | rcalc -e '$1=if($7,1,0); $2=1' | total >
./zzz_vta_pts_total_1.txt

The problem here probably is, that your fisheye view -vta produces pixel
values outside the circular image you would expect. These get counted in
the total number of pixels. So if you are using -vta, you need way to
filter pixels lying outside the circle. Several approaches to do so come to
my mind. A generic one is:

1) vwrays -vta into a scene consisting only of a source, corresponding to
the hemisphere you want to sample
2) pipe the output to rtrace, check for intersections with the source and
get origin and direction vectors
3) pipe that into rtrace again, this time checking for your pixel values
as above...

Still, there is a problem with the -vta (equiangular) fisheye not being a
equisolid fisheye, so pixels do not represent equal solid angles.... for
sky view factors, that is what you would want, but for your definition, you
want the ration (solid angle visible sky) / (solid angle sky without
obstructions). So either calculate the solid angle of the pixel depending
on the distance from view centre, or go with rpict, create a fisheye image
(-vta), and use the S and T functions to filter pixels outside the view and
to weigh pixels by their solid angle. So in above commands, you would not
set the pixel value to 0 or 1, but to 0 or S(n).

Again, I could not try out all this and send a complete example, just
trying to point you to some direction.

Cheers, Lars.

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

[Lars_Grobe]

Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image "solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o - > solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle. To take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage - good way to think about projections...

Cheers, Lars.

···

Hi, Lars, thanks a lot for your advices!

May I ask the references on the S and T function as you suggested to look up? (I didn't find any relevant infor via Radiance forum search...)

May I also ask what the "n" in the "S(n)" denotes?

Thanks again!

- Cheers, Ji

[Ji_ZHANG]

Hi, Lars, Thanks for your detailed explanation!

The following bash script is put up according to the suggestions from all
previous replies to this post. This method is view type independent.
Anyway, I'd appreciate further advices from the list to make it more
succinct and efficient, or point out the loopholes if there are any.

# start__________________________
# calculate Sky Exposure Factor
# which is defined as the ratio between
# the solid angle subtended by visible sky patch/patches
# and that of the unobstructed sky hemisphere (which is 2*PI)
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct
rpict -av 1 1 1 -vf ./view_vts.vf -x 1000 -y 1000 ./SkyEF_scene.oct | pcomb
-e 'solidAngle=S(1);ro=if(ri(1),0,solidAngle); go=if(gi(1),0,solidAngle);
bo=if(bi(1),0,solidAngle)' -o - | pvalue -h -H | rcalc -e '$1=$3' | total |
rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

The contents of "view_vts.vf" (note that the location of the view point is
slightly away from the surface of the scene geometry):
rvu -vts -vp 0 0 0.001 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0 -vs
0 -vl 0

The following step-by-step break down of the commands might be useful for
debugging purpose.

# start__________________________
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct

rpict -av 1 1 1 -vf ./view_vts.vf -x 800 -y 800 ./SkyEF_scene.oct >
./SkyEF_vts.hdr

cat ./SkyEF_vts.hdr | pcomb -e 'omega=S(1);ro=if(ri(1),0,omega);
go=if(gi(1),0,omega); bo=if(bi(1),0,omega)' -o - > ./SkyEF_solidAngle.hdr

cat ./SkyEF_solidAngle.hdr | pvalue -h -H >
./SkyEF_xpos_ypos_solidAngleVal.txt

cat ./SkyEF_xpos_ypos_solidAngleVal.txt | rcalc -e '$1=$3' | total >
./SkyEF_total_solidAngle_of_visible_sky.txt

cat ./SkyEF_total_solidAngle_of_visible_sky.txt | rcalc -e '$1=$1/2/PI' >
./SkyEF_results.txt
# end__________________________

Thanks again for the help from all of you!
- Ji

···

On Thu, Oct 25, 2012 at 4:20 PM, Lars O. Grobe <[email protected]> wrote:

Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image
"solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle
of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o -
> solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle. To
take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage -
good way to think about projections...

Cheers, Lars.

> Hi, Lars, thanks a lot for your advices!
>
> May I ask the references on the S and T function as you suggested to
look up? (I didn't find any relevant infor via Radiance forum search...)
>
> May I also ask what the "n" in the "S(n)" denotes?
>
> Thanks again!
>
> - Cheers, Ji

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

[Ji_ZHANG]

Dear list,

I'd like to ask if the Radiance way to calculate sky exposure as explained
below can be further optimized.

This method is quite accurate, but it is just not fast enough for us (0.2
second per sensor).

It seems the Radiance programs used in this approach, such as rpict, pcomb,
pvalue, etc. are not applicable to harvest the power of parallel
processing, such as what the "-n" option does for rtrace.

Maybe I'm just too greedy, but is there a way to further enhance the
efficiency of the individual Radiance command in this method?

Thanks in advance!

- Ji

···

On Fri, Oct 26, 2012 at 2:11 AM, Ji Zhang <[email protected]> wrote:

Hi, Lars, Thanks for your detailed explanation!

The following bash script is put up according to the suggestions from all
previous replies to this post. This method is view type independent.
Anyway, I'd appreciate further advices from the list to make it more
succinct and efficient, or point out the loopholes if there are any.

# start__________________________
# calculate Sky Exposure Factor
# which is defined as the ratio between
# the solid angle subtended by visible sky patch/patches
# and that of the unobstructed sky hemisphere (which is 2*PI)
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct
rpict -av 1 1 1 -vf ./view_vts.vf -x 1000 -y 1000 ./SkyEF_scene.oct |
pcomb -e 'solidAngle=S(1);ro=if(ri(1),0,solidAngle);
go=if(gi(1),0,solidAngle); bo=if(bi(1),0,solidAngle)' -o - | pvalue -h -H |
rcalc -e '$1=$3' | total | rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

The contents of "view_vts.vf" (note that the location of the view point is
slightly away from the surface of the scene geometry):
rvu -vts -vp 0 0 0.001 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0 -vs
0 -vl 0

The following step-by-step break down of the commands might be useful for
debugging purpose.

# start__________________________
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct

rpict -av 1 1 1 -vf ./view_vts.vf -x 800 -y 800 ./SkyEF_scene.oct >
./SkyEF_vts.hdr

cat ./SkyEF_vts.hdr | pcomb -e 'omega=S(1);ro=if(ri(1),0,omega);
go=if(gi(1),0,omega); bo=if(bi(1),0,omega)' -o - > ./SkyEF_solidAngle.hdr

cat ./SkyEF_solidAngle.hdr | pvalue -h -H >
./SkyEF_xpos_ypos_solidAngleVal.txt

cat ./SkyEF_xpos_ypos_solidAngleVal.txt | rcalc -e '$1=$3' | total >
./SkyEF_total_solidAngle_of_visible_sky.txt

cat ./SkyEF_total_solidAngle_of_visible_sky.txt | rcalc -e '$1=$1/2/PI' >
./SkyEF_results.txt
# end__________________________

Thanks again for the help from all of you!
- Ji

On Thu, Oct 25, 2012 at 4:20 PM, Lars O. Grobe <[email protected]> wrote:

Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image
"solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle
of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o -
> solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle.
To take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage
- good way to think about projections...

Cheers, Lars.

> Hi, Lars, thanks a lot for your advices!
>
> May I ask the references on the S and T function as you suggested to
look up? (I didn't find any relevant infor via Radiance forum search...)
>
> May I also ask what the "n" in the "S(n)" denotes?
>
> Thanks again!
>
> - Cheers, Ji

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

[Iebele]

Hi Ji,

Concerning the rpict part of your problem, you might consider an approach that divides the solution into series of scanlines equal to the number of nodes/processors you have available in your parallel system. Use piece instead of rpict, in such case.

- iebele

···

Op 30 nov. 2012, om 12:50 heeft Ji Zhang het volgende geschreven:

Dear list,

I'd like to ask if the Radiance way to calculate sky exposure as explained below can be further optimized.

This method is quite accurate, but it is just not fast enough for us (0.2 second per sensor).

It seems the Radiance programs used in this approach, such as rpict, pcomb, pvalue, etc. are not applicable to harvest the power of parallel processing, such as what the "-n" option does for rtrace.

Maybe I'm just too greedy, but is there a way to further enhance the efficiency of the individual Radiance command in this method?

Thanks in advance!

- Ji

On Fri, Oct 26, 2012 at 2:11 AM, Ji Zhang <[email protected]> wrote:
Hi, Lars, Thanks for your detailed explanation!

The following bash script is put up according to the suggestions from all previous replies to this post. This method is view type independent. Anyway, I'd appreciate further advices from the list to make it more succinct and efficient, or point out the loopholes if there are any.

# start__________________________
# calculate Sky Exposure Factor
# which is defined as the ratio between
# the solid angle subtended by visible sky patch/patches
# and that of the unobstructed sky hemisphere (which is 2*PI)
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct
rpict -av 1 1 1 -vf ./view_vts.vf -x 1000 -y 1000 ./SkyEF_scene.oct | pcomb -e 'solidAngle=S(1);ro=if(ri(1),0,solidAngle); go=if(gi(1),0,solidAngle); bo=if(bi(1),0,solidAngle)' -o - | pvalue -h -H | rcalc -e '$1=$3' | total | rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

The contents of "view_vts.vf" (note that the location of the view point is slightly away from the surface of the scene geometry):
rvu -vts -vp 0 0 0.001 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0 -vs 0 -vl 0

The following step-by-step break down of the commands might be useful for debugging purpose.

# start__________________________
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct

rpict -av 1 1 1 -vf ./view_vts.vf -x 800 -y 800 ./SkyEF_scene.oct > ./SkyEF_vts.hdr

cat ./SkyEF_vts.hdr | pcomb -e 'omega=S(1);ro=if(ri(1),0,omega); go=if(gi(1),0,omega); bo=if(bi(1),0,omega)' -o - > ./SkyEF_solidAngle.hdr

cat ./SkyEF_solidAngle.hdr | pvalue -h -H > ./SkyEF_xpos_ypos_solidAngleVal.txt

cat ./SkyEF_xpos_ypos_solidAngleVal.txt | rcalc -e '$1=$3' | total > ./SkyEF_total_solidAngle_of_visible_sky.txt

cat ./SkyEF_total_solidAngle_of_visible_sky.txt | rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

Thanks again for the help from all of you!
- Ji

On Thu, Oct 25, 2012 at 4:20 PM, Lars O. Grobe <[email protected]> wrote:
Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image "solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o - > solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle. To take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage - good way to think about projections...

Cheers, Lars.

> Hi, Lars, thanks a lot for your advices!
>
> May I ask the references on the S and T function as you suggested to look up? (I didn't find any relevant infor via Radiance forum search...)
>
> May I also ask what the "n" in the "S(n)" denotes?
>
> Thanks again!
>
> - Cheers, Ji

_______________________________________________
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

[Andrew_McNeil2]

You could use vwrays with rtrace instead of rpict.
Andy

···

On Fri, Nov 30, 2012 at 8:51 AM, Iebele <[email protected]> wrote:

Hi Ji,

Concerning the rpict part of your problem, you might consider an approach
that divides the solution into series of scanlines equal to the number of
nodes/processors you have available in your parallel system. Use piece
instead of rpict, in such case.

- iebele

Op 30 nov. 2012, om 12:50 heeft Ji Zhang het volgende geschreven:

Dear list,

I'd like to ask if the Radiance way to calculate sky exposure as explained
below can be further optimized.

This method is quite accurate, but it is just not fast enough for us (0.2
second per sensor).

It seems the Radiance programs used in this approach, such as rpict,
pcomb, pvalue, etc. are not applicable to harvest the power of parallel
processing, such as what the "-n" option does for rtrace.

Maybe I'm just too greedy, but is there a way to further enhance the
efficiency of the individual Radiance command in this method?

Thanks in advance!

- Ji

On Fri, Oct 26, 2012 at 2:11 AM, Ji Zhang <[email protected]> wrote:

Hi, Lars, Thanks for your detailed explanation!

The following bash script is put up according to the suggestions from all
previous replies to this post. This method is view type independent.
Anyway, I'd appreciate further advices from the list to make it more
succinct and efficient, or point out the loopholes if there are any.

# start__________________________
# calculate Sky Exposure Factor
# which is defined as the ratio between
# the solid angle subtended by visible sky patch/patches
# and that of the unobstructed sky hemisphere (which is 2*PI)
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct
rpict -av 1 1 1 -vf ./view_vts.vf -x 1000 -y 1000 ./SkyEF_scene.oct |
pcomb -e 'solidAngle=S(1);ro=if(ri(1),0,solidAngle);
go=if(gi(1),0,solidAngle); bo=if(bi(1),0,solidAngle)' -o - | pvalue -h -H |
rcalc -e '$1=$3' | total | rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

The contents of "view_vts.vf" (note that the location of the view point
is slightly away from the surface of the scene geometry):
rvu -vts -vp 0 0 0.001 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0
-vs 0 -vl 0

The following step-by-step break down of the commands might be useful for
debugging purpose.

# start__________________________
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct

rpict -av 1 1 1 -vf ./view_vts.vf -x 800 -y 800 ./SkyEF_scene.oct >
./SkyEF_vts.hdr

cat ./SkyEF_vts.hdr | pcomb -e 'omega=S(1);ro=if(ri(1),0,omega);
go=if(gi(1),0,omega); bo=if(bi(1),0,omega)' -o - > ./SkyEF_solidAngle.hdr

cat ./SkyEF_solidAngle.hdr | pvalue -h -H >
./SkyEF_xpos_ypos_solidAngleVal.txt

cat ./SkyEF_xpos_ypos_solidAngleVal.txt | rcalc -e '$1=$3' | total >
./SkyEF_total_solidAngle_of_visible_sky.txt

cat ./SkyEF_total_solidAngle_of_visible_sky.txt | rcalc -e '$1=$1/2/PI' >
./SkyEF_results.txt
# end__________________________

Thanks again for the help from all of you!
- Ji

On Thu, Oct 25, 2012 at 4:20 PM, Lars O. Grobe <[email protected]> wrote:

Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image
"solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle
of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o
- > solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle.
To take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage
- good way to think about projections...

Cheers, Lars.

> Hi, Lars, thanks a lot for your advices!
>
> May I ask the references on the S and T function as you suggested to
look up? (I didn't find any relevant infor via Radiance forum search...)
>
> May I also ask what the "n" in the "S(n)" denotes?
>
> Thanks again!
>
> - Cheers, Ji

_______________________________________________
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

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

[Ji_ZHANG]

Dear Andy, thanks!

I did a simple test and it seems that using vwrays+"rtrace with the -n
option" to replace rpict didn't improve the speed. Instead, the simulation
time increased quite a lot (a difference btw 2second and 11second), and the
size of the same hdr file generated is larger than the one generated by
rpict (a difference btw 1M and 28KB).

1) the script for the "rpict" way is:
*oconv ./mat.rad ./geom.rad ./sky.rad > ./scene.oct
rpict -ab 1 -vf ./view.vf -x 500 -y 500 ./scene.oct > ./SkyEF-vta_ab1.hdr*

2) the script for the vwrays+"rtrace with the -n option" way is:
*oconv ./mat.rad ./geom.rad ./sky.rad > ./scene.oct
vwrays -ff -vf ./view.vf -x 500 -y 500 | rtrace -ab 1 `vwrays -d -vf
./view.vf -x 500 -y 500` -ffc -n 2 -af ./amb_f.amb ./scene.oct >
./SkyEF-vta_ab1.hdr*

(tested on an iMac with DuoCore CPU)

Would appreciate if you can further advice on these issues!

- Ji

···

On Sat, Dec 1, 2012 at 1:37 AM, Andrew McNeil <[email protected]> wrote:

You could use vwrays with rtrace instead of rpict.
Andy

On Fri, Nov 30, 2012 at 8:51 AM, Iebele <[email protected]> wrote:

Hi Ji,

Concerning the rpict part of your problem, you might consider an approach
that divides the solution into series of scanlines equal to the number of
nodes/processors you have available in your parallel system. Use piece
instead of rpict, in such case.

- iebele

Op 30 nov. 2012, om 12:50 heeft Ji Zhang het volgende geschreven:

Dear list,

I'd like to ask if the Radiance way to calculate sky exposure as
explained below can be further optimized.

This method is quite accurate, but it is just not fast enough for us (0.2
second per sensor).

It seems the Radiance programs used in this approach, such as rpict,
pcomb, pvalue, etc. are not applicable to harvest the power of parallel
processing, such as what the "-n" option does for rtrace.

Maybe I'm just too greedy, but is there a way to further enhance the
efficiency of the individual Radiance command in this method?

Thanks in advance!

- Ji

On Fri, Oct 26, 2012 at 2:11 AM, Ji Zhang <[email protected]> wrote:

Hi, Lars, Thanks for your detailed explanation!

The following bash script is put up according to the suggestions from
all previous replies to this post. This method is view type independent.
Anyway, I'd appreciate further advices from the list to make it more
succinct and efficient, or point out the loopholes if there are any.

# start__________________________
# calculate Sky Exposure Factor
# which is defined as the ratio between
# the solid angle subtended by visible sky patch/patches
# and that of the unobstructed sky hemisphere (which is 2*PI)
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct
rpict -av 1 1 1 -vf ./view_vts.vf -x 1000 -y 1000 ./SkyEF_scene.oct |
pcomb -e 'solidAngle=S(1);ro=if(ri(1),0,solidAngle);
go=if(gi(1),0,solidAngle); bo=if(bi(1),0,solidAngle)' -o - | pvalue -h -H |
rcalc -e '$1=$3' | total | rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

The contents of "view_vts.vf" (note that the location of the view point
is slightly away from the surface of the scene geometry):
rvu -vts -vp 0 0 0.001 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0
-vs 0 -vl 0

The following step-by-step break down of the commands might be useful
for debugging purpose.

# start__________________________
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct

rpict -av 1 1 1 -vf ./view_vts.vf -x 800 -y 800 ./SkyEF_scene.oct >
./SkyEF_vts.hdr

cat ./SkyEF_vts.hdr | pcomb -e 'omega=S(1);ro=if(ri(1),0,omega);
go=if(gi(1),0,omega); bo=if(bi(1),0,omega)' -o - > ./SkyEF_solidAngle.hdr

cat ./SkyEF_solidAngle.hdr | pvalue -h -H >
./SkyEF_xpos_ypos_solidAngleVal.txt

cat ./SkyEF_xpos_ypos_solidAngleVal.txt | rcalc -e '$1=$3' | total >
./SkyEF_total_solidAngle_of_visible_sky.txt

cat ./SkyEF_total_solidAngle_of_visible_sky.txt | rcalc -e '$1=$1/2/PI'
> ./SkyEF_results.txt
# end__________________________

Thanks again for the help from all of you!
- Ji

On Thu, Oct 25, 2012 at 4:20 PM, Lars O. Grobe <[email protected]> wrote:

Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image
"solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle
of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o
- > solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle.
To take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage
- good way to think about projections...

Cheers, Lars.

> Hi, Lars, thanks a lot for your advices!
>
> May I ask the references on the S and T function as you suggested to
look up? (I didn't find any relevant infor via Radiance forum search...)
>
> May I also ask what the "n" in the "S(n)" denotes?
>
> Thanks again!
>
> - Cheers, Ji

_______________________________________________
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

_______________________________________________
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

[Ji_ZHANG]

Thanks, iebele, I may need to read on rpiece's function later and do some
test accordingly ...

- Ji

···

On Sat, Dec 1, 2012 at 12:51 AM, Iebele <[email protected]> wrote:

Hi Ji,

Concerning the rpict part of your problem, you might consider an approach
that divides the solution into series of scanlines equal to the number of
nodes/processors you have available in your parallel system. Use piece
instead of rpict, in such case.

- iebele

Op 30 nov. 2012, om 12:50 heeft Ji Zhang het volgende geschreven:

Dear list,

I'd like to ask if the Radiance way to calculate sky exposure as explained
below can be further optimized.

This method is quite accurate, but it is just not fast enough for us (0.2
second per sensor).

It seems the Radiance programs used in this approach, such as rpict,
pcomb, pvalue, etc. are not applicable to harvest the power of parallel
processing, such as what the "-n" option does for rtrace.

Maybe I'm just too greedy, but is there a way to further enhance the
efficiency of the individual Radiance command in this method?

Thanks in advance!

- Ji

On Fri, Oct 26, 2012 at 2:11 AM, Ji Zhang <[email protected]> wrote:

Hi, Lars, Thanks for your detailed explanation!

The following bash script is put up according to the suggestions from all
previous replies to this post. This method is view type independent.
Anyway, I'd appreciate further advices from the list to make it more
succinct and efficient, or point out the loopholes if there are any.

# start__________________________
# calculate Sky Exposure Factor
# which is defined as the ratio between
# the solid angle subtended by visible sky patch/patches
# and that of the unobstructed sky hemisphere (which is 2*PI)
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct
rpict -av 1 1 1 -vf ./view_vts.vf -x 1000 -y 1000 ./SkyEF_scene.oct |
pcomb -e 'solidAngle=S(1);ro=if(ri(1),0,solidAngle);
go=if(gi(1),0,solidAngle); bo=if(bi(1),0,solidAngle)' -o - | pvalue -h -H |
rcalc -e '$1=$3' | total | rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt
# end__________________________

The contents of "view_vts.vf" (note that the location of the view point
is slightly away from the surface of the scene geometry):
rvu -vts -vp 0 0 0.001 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0
-vs 0 -vl 0

The following step-by-step break down of the commands might be useful for
debugging purpose.

# start__________________________
oconv ./plastic_mat.rad ./geom.rad > ./SkyEF_scene.oct

rpict -av 1 1 1 -vf ./view_vts.vf -x 800 -y 800 ./SkyEF_scene.oct >
./SkyEF_vts.hdr

cat ./SkyEF_vts.hdr | pcomb -e 'omega=S(1);ro=if(ri(1),0,omega);
go=if(gi(1),0,omega); bo=if(bi(1),0,omega)' -o - > ./SkyEF_solidAngle.hdr

cat ./SkyEF_solidAngle.hdr | pvalue -h -H >
./SkyEF_xpos_ypos_solidAngleVal.txt

cat ./SkyEF_xpos_ypos_solidAngleVal.txt | rcalc -e '$1=$3' | total >
./SkyEF_total_solidAngle_of_visible_sky.txt

cat ./SkyEF_total_solidAngle_of_visible_sky.txt | rcalc -e '$1=$1/2/PI' >
./SkyEF_results.txt
# end__________________________

Thanks again for the help from all of you!
- Ji

On Thu, Oct 25, 2012 at 4:20 PM, Lars O. Grobe <[email protected]> wrote:

Hi Ji!

The functions S(n) and T(n) are available in pcomb. To make an image
"solid_angles.hdr" with pixel values (r=g=b) being equal to the solid angle
of the pixel in sr, you would do the following:

cat image.hdr | pcomb -e 'omega=S(1); ro=omega; go=omega; bo=omega' -o
- > solid_angles.hdr

So S(n) gives, for each pixel of the n'th input image, its solid angle.
To take a look, use falsecolor -m 1 -s .000008 -ip solidangle.hdr | ximage
- good way to think about projections...

Cheers, Lars.

> Hi, Lars, thanks a lot for your advices!
>
> May I ask the references on the S and T function as you suggested to
look up? (I didn't find any relevant infor via Radiance forum search...)
>
> May I also ask what the "n" in the "S(n)" denotes?
>
> Thanks again!
>
> - Cheers, Ji

_______________________________________________
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

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