sky visibility

[Ji_ZHANG]

Another problem now is that the larger .hdr image generated via the
vwrays+"rtrace with the -n option" approach can't be processed by pcomb. I
got the following error message "S: domain error" and "if: domain error"
when I tried the following script:

···

#_____________________________
oconv ./mat.rad ./geom.rad ./sky.rad > ./scene.oct

vwrays -ff -vf ./view.vf -x 500 -y 500 | rtrace -ab 0 `vwrays -d -vf
./view.vf -x 500 -y 500` -ffc -n 2 -af ./amb_f.amb ./scene.oct >
./SkyEF-vta_ab0.hdr

cat ./SkyEF-vta_ab0.hdr | pcomb -e
'solidAngle=S(1);ro=if(ri(1),solidAngle,0); go=if(gi(1),solidAngle,0);
bo=if(bi(1),solidAngle,0)' -o - > ./SkyEF_viz_solidAngles.hdr
#____________________________

The following script using rpict, however, is OK:
#_____________________________
oconv ./mat.rad ./geom.rad ./sky.rad > ./scene.oct

rpict -ab 0 -vf ./view.vf -x 500 -y 500 ./scene.oct > ./SkyEF-vta_ab0.hdr

cat ./SkyEF-vta_ab0.hdr | pcomb -e
'solidAngle=S(1);ro=if(ri(1),solidAngle,0); go=if(gi(1),solidAngle,0);
bo=if(bi(1),solidAngle,0)' -o - > ./SkyEF_viz_solidAngles.hdr
#____________________________

I assume the two "SkyEF-vta_ab0.hdr" generated through the two approaches
are different, not only in file size but also in image file content, which
may have caused pcomb unable to process the first one (created via
vwrays+rtrace) ...

... advices area greatly appreciated!

- JI

On Sat, Dec 1, 2012 at 3:52 PM, Ji Zhang <[email protected]> wrote:

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

[Greg_Ward]

Ji,

My suggestion is to simplify your command. Most of your time is probably being spent in pcomb, unless your scene is extremely complex. Try:

  oconv -f ./plastic_mat.rad ./geom.rad \
  > rpict -av 1 1 1 -vf view_vts.vf -x 1000 -y 1000 \
  > pcomb -e 'lo=if(gi(1),0,S(1))' - \
  > pvalue -h -H -pG -d \
  > total \
  > rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt

Best,
-Greg

···

From: Ji Zhang <[email protected]>
Date: November 30, 2012 12:50:56 AM HST

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

[Ji_ZHANG]

Thank you very much, Greg!

The method is faster (around 50% faster) now according to your suggestion!

I understand from your advise that there's no need to model the uniform
sky, and using the "-av 1 1 1" option for rpict can literally "color" the
geometries visible from the view specified in light grey so that they can
be differentiated from the visible sky patch(es) which is rendered as black
in this case.

And also, the pcomb part of calculation can be performed for just one of
the RGB channels.

Thanks again!

- Ji

···

On Sun, Dec 2, 2012 at 2:26 AM, Greg Ward <[email protected]> wrote:

Ji,

My suggestion is to simplify your command. Most of your time is probably
being spent in pcomb, unless your scene is extremely complex. Try:

oconv -f ./plastic_mat.rad ./geom.rad \
> rpict -av 1 1 1 -vf view_vts.vf -x 1000 -y 1000 \
> pcomb -e 'lo=if(gi(1),0,S(1))' - \
> pvalue -h -H -pG -d \
> total \
> rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt

Best,
-Greg

*From: *Ji Zhang <[email protected]>

*Date: *November 30, 2012 12:50:56 AM HST

*
*

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]

Hi, Greg, a follow-up based on some quick tests:

Maybe we still need to include the following definition of a "bright"
ground into the octree:

···

#___________________________
# content of SkyEF_ground.rad file
!gensky 6 21 +15.0 -a 1.0 -o 103.0 -m -105 -u -B 1.0

skyfunc glow ground_glow
0
0
4 1 1 1 0

ground_glow source ground
0
0
4 0 0 -1 180
#___________________________

It is to prevent some of the visible part of the ground below horizon
(rendered as black by rpict in your way) from being mistakenly recognized
as part of the sky (also rendered as black) in the pcomb related processing
...

- Cheers, Ji

On Sun, Dec 2, 2012 at 8:26 PM, Ji Zhang <[email protected]> wrote:

Thank you very much, Greg!

The method is faster (around 50% faster) now according to your suggestion!

I understand from your advise that there's no need to model the uniform
sky, and using the "-av 1 1 1" option for rpict can literally "color" the
geometries visible from the view specified in light grey so that they can
be differentiated from the visible sky patch(es) which is rendered as black
in this case.

And also, the pcomb part of calculation can be performed for just one of
the RGB channels.

Thanks again!

- Ji

On Sun, Dec 2, 2012 at 2:26 AM, Greg Ward <[email protected]> wrote:

Ji,

My suggestion is to simplify your command. Most of your time is probably
being spent in pcomb, unless your scene is extremely complex. Try:

oconv -f ./plastic_mat.rad ./geom.rad \
> rpict -av 1 1 1 -vf view_vts.vf -x 1000 -y 1000 \
> pcomb -e 'lo=if(gi(1),0,S(1))' - \
> pvalue -h -H -pG -d \
> total \
> rcalc -e '$1=$1/2/PI' > ./SkyEF_results.txt

Best,
-Greg

*From: *Ji Zhang <[email protected]>

*Date: *November 30, 2012 12:50:56 AM HST

*
*

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

[Giulio_Antonutto]

IF you use an ambient file and the ray tracing of direct stuff is trivial, the easiest and fastest trick is to run multiple rpict instances of the same view using the same ambient file, trash all but one.
this makes the ambient file faster to populate and therefore the the image.
I have used this in the past and the speed increase was noticeable, but the overall time was large.
I am not sure you would see a gain in an image that takes very little to compute…. but you could try...
G

···

On 1 Dec 2012, at 08:46, Ji Zhang <[email protected]> wrote:

Another problem now is that the larger .hdr image generated via the vwrays+"rtrace with the -n option" approach can't be processed by pcomb. I got the following error message "S: domain error" and "if: domain error" when I tried the following script:

#_____________________________
oconv ./mat.rad ./geom.rad ./sky.rad > ./scene.oct

vwrays -ff -vf ./view.vf -x 500 -y 500 | rtrace -ab 0 `vwrays -d -vf ./view.vf -x 500 -y 500` -ffc -n 2 -af ./amb_f.amb ./scene.oct > ./SkyEF-vta_ab0.hdr

cat ./SkyEF-vta_ab0.hdr | pcomb -e 'solidAngle=S(1);ro=if(ri(1),solidAngle,0); go=if(gi(1),solidAngle,0); bo=if(bi(1),solidAngle,0)' -o - > ./SkyEF_viz_solidAngles.hdr
#____________________________

The following script using rpict, however, is OK:
#_____________________________
oconv ./mat.rad ./geom.rad ./sky.rad > ./scene.oct

rpict -ab 0 -vf ./view.vf -x 500 -y 500 ./scene.oct > ./SkyEF-vta_ab0.hdr

cat ./SkyEF-vta_ab0.hdr | pcomb -e 'solidAngle=S(1);ro=if(ri(1),solidAngle,0); go=if(gi(1),solidAngle,0); bo=if(bi(1),solidAngle,0)' -o - > ./SkyEF_viz_solidAngles.hdr
#____________________________

I assume the two "SkyEF-vta_ab0.hdr" generated through the two approaches are different, not only in file size but also in image file content, which may have caused pcomb unable to process the first one (created via vwrays+rtrace) ...

... advices area greatly appreciated!

- JI

On Sat, Dec 1, 2012 at 3:52 PM, Ji Zhang <[email protected]> wrote:
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

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