[Radiance-general] sky visibility

Sat Dec 1 00:46:19 PST 2012

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 <hope.zh at gmail.com> 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 <amcneil at lbl.gov> wrote:
>
>> You could use vwrays with rtrace instead of rpict.
>> Andy
>>
>>
>> On Fri, Nov 30, 2012 at 8:51 AM, Iebele <iabel at iebele.nl> 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 <hope.zh at gmail.com> 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 <grobe at gmx.net> 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
>>>>> Radiance-general at radiance-online.org
>>>>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Radiance-general mailing list
>>> Radiance-general at radiance-online.org
>>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>>
>>>
>>>
>>> _______________________________________________
>>> Radiance-general mailing list
>>> Radiance-general at radiance-online.org
>>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>>
>>>
>>
>> _______________________________________________
>> Radiance-general mailing list
>> Radiance-general at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20121201/c2478ac9/attachment.html>