[Radiance-general] sky visibility

[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 <grobe at gmx.net> 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 at radiance-**online.org<Radiance-general at radiance-online.org>
> http://www.radiance-online.**org/mailman/listinfo/radiance-**general<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/20121022/1a58fddd/attachment-0001.html>