Encyclopedia of Graphics File Formats Companion/GFF_CD.ISO/formats/radiance/spec/tutorial.ms

Text File | 1994-04-15 | 28.1 KB | 1,121 lines

.\" SCCSid "@(#)tutorial.1 2.2 1/24/93 LBL"
.\"Print using the -ms macro package
.ps 11
.nr PS 11
.vs 14
.nr VS 14
.TL
RADIANCE Tutorial
.AU
Greg Ward
.br
Lawrence Berkeley Laboratory
.NH
Introduction
.sp .5
.LP
RADIANCE is a lighting simulation program that synthesizes images
from 3-dimensional geometric models of physical spaces.
The input model describes each surface's shape, size, location and
composition.
A model may contain many thousands of surfaces, and is often produced
by a separate CAD program.
In addition to arbitrary (planar) polygons, RADIANCE directly models
spheres and cones.
Generator programs are provided for the creation of more complex
shapes from these basic
surface primitives.
Examples include boxes, prisms and surfaces of revolution.
A transformation utility permits the simple duplication of objects and
hierarchical construction of a scene.
.sp .5
.LP
This tutorial assumes a certain familiarity with the UNIX
operating system and its text editing facilities.
Ask your system administrator for a basic introduction.
.sp .5
.LP
The RADIANCE reference manual will be required to understand the following
examples of scene creation and program interaction.
Text in
.I italics
is user input.
.NH
Input of a Simple Room
.sp .5
.LP
In this example, we will use a text editor to create the input for
a simple room containing a box, a ball, and a light source.
In most applications, a CAD system would be used to describe a scene's
geometry, which would then be combined with surface materials,
light fixtures, and (optionally) furniture.
To get a more intimate understanding of the input to RADIANCE, we will
start without the advantages of a CAD program or an object library.
.sp .5
.LP
The scene we will be working towards is shown in Figure 1.
It is usually helpful to start with a simple drawing showing the
coordinate axis and the relative locations of major surfaces.
.sp .5
.LP
The minimum input required to get an image is a source of
illumination and an object to reflect light to the "camera".*\0
.FS
*In fact, a RADIANCE renderer can be thought of an invisible camera
in a simulated world.
.FE
We will begin with two spheres, one emissive and one reflective.
First we define the materials, then the spheres themselves.
Actually, the order is only important insofar as each modifier definition
(i.e. material) must appear before its first reference.
(Consult the RADIANCE manual for an explanation of the
primitive types and their parameters.)\0
Start your favorite text editor ("vi" in this example) to create the
following file called "room.rad":
.sp .5
.QP
%
.I "vi room.rad"
.sp .5
.QP
.I
.nf
#
#  My first scene.
#

# this is the material for my light source:

void light bright
0
0
3  100  100  100

# this is the material for my test ball:

void plastic red_plastic
0
0
5  .7  .05  .05  .05  .05

# here is the light source:

bright sphere fixture
0
0
4  2  1  1.5  .125

# here is the ball:

red_plastic sphere ball
0
0
4  .7  1.125  .625  .125
.fi
.R
.sp .5
.LP
Now that we have a simple scene description, we can look at it with
the interactive viewing program,
.B rview.
First, however, we must create the "octree"
file that will be used to accelerate the rendering process.
To accomplish this, type the following command:
.sp .5
.QP
%
.I
oconv room.rad > test.oct
.R
.sp .5
.LP
Note that the suffixes ".rad" and ".oct" are not enforced by the program,
but are merely a convenience to aid the user in identifying files later.
The command
.B getinfo
can be used to get information on the origin of binary (unviewable)
files created by RADIANCE utilities.
Try entering the command:
.sp .5
.QP
%
.I "getinfo test.oct"
.sp .5
.LP
The usefulness of such a function will be apparent when you find
yourself with a dozen files named "test.pic".
.sp .5
.LP
To make an image of our scene,
we must select a suitable set of view parameters telling RADIANCE
where to point its camera.
To simplify our example, we will use the same starting position for
all our renderings, and change views only once
.B rview
is started:
.sp .5
.QP
%
.I
rview -vp 2.25 .375 1 -vd -.25 .125 -.125 -av .5 .5 .5 test.oct
.R
.sp .5
.LP
The "-vp" option gives the view point, and the "-vd" option gives
the view direction vector.
The "-av" option specifies the amount of light globally present
in the scene, permitting portions of the scene that are not
illuminated directly to be visible.
.B Rview
has many more options, and their default values may be discovered using:
.sp .5
.QP
%
.I "rview -defaults"
.sp .5
.LP
You should start to see an image of a red ball forming on your screen.
Take this opportunity to try each of
.B rview's
commands, as described in the manual.
If you make a mistake in a view specification, use the
.B last
command to get back to where you were.
It is probably a good idea to save your favorite view using the rview
command:
.sp .5
.QP
:
.I "view default.vp"
.sp .5
.LP
You can create any number of "viewfiles"
with this command, and retrieve them with:
.sp .5
.QP
:
.I last
viewfile
.sp .5
.LP
If you look around enough, you may even be able to see the light source
itself.
Unlike many rendering programs, the light sources in RADIANCE are
visible objects.
This illustrates the philosophy behind the program, which is the simulation
of physical spaces.
Since it is not possible to create an invisible light source in reality,
there is no reason to do it in simulation.
.sp .5
.LP
Still, there is no guarantee that the user will create physically meaningful
descriptions.
For example, we have just floated a red ball next to a light source somewhere
in intergalactic space.
In the interest of making this scene more realistic, let's enclose the
light and ball in a room by adding the following text to "room.rad":
.sp .5
.QP
%
.I "vi room.rad"
.sp .5
.QP
.I
.nf
# the wall material:

void plastic gray_paint
0
0
5  .5  .5  .5  0  0

# a box shaped room:

!genbox gray_paint room  3  2  1.75  -i
.fi
.R
.sp .5
.LP
The generator program
.B genbox
is just a command that produces a RADIANCE description, and it is
executed when the file is read.
It is more convenient than specifying the coordinates of four vertices
for each of six polygons, and can be changed later quite easily.
(See the manual genbox page for further details.)\0
.sp .5
.LP
You can now look at the modified scene, but remember first to
regenerate the octree:
.sp .5
.QP
%
.I "oconv room.rad > test.oct"
.br
%
.I "rview -vf default.vp -av  .5  .5  .5  test.oct"
.sp .5
.LP
This is better, but our ball and light source are still floating, which
is an unrealistic condition for most rooms.
Let's put a box under the table, and a rod to suspend the light from
the ceiling:
.sp .5
.QP
.I
.nf
# a shiny blue box:

void plastic blue_plastic
0
0
5 .1 .1 .6 .05 .1

!genbox blue_plastic box  .5  .5  .5  | xform -rz  15  -t  .5  .75  0

# a chrome rod to suspend the light from the ceiling:

void metal chrome
0
0
5  .8  .8  .8  .9  0

chrome cylinder fixture_support
0
0
7
211.5
211.75
.05
.fi
.R
.sp .5
.LP
Note that this time the output of genbox was "piped" into another program,
.B xform.
.B Xform
is used to move, scale and rotate RADIANCE descriptions.
.B Genbox
always creates a box in the positive octant of 3-space with
one corner at the origin.
This was what we wanted for the room, but we wanted the box moved away
from the wall and rotated slightly.
First we rotated the box 15 degrees about the z-axis (pivoting on the
origin), then translated the corner from the origin to (.5,.75,0).
By no small coincidence, this position is directly under our original
ball.
.sp .5
.LP
After viewing this new arrangement, you can try changing some of the
materials -- here are a few examples:
.sp .5
.QP
.I
.nf
# solid crystal:

void dielectric crystal
0
0
5  .5  .5  .5  1.5  0

# dark brown:

void plastic brown
0
0
5  .2  .1  .1  0  0

# light gray:

void plastic white
0
0
5  .7  .7  .7  0  0
.fi
.R
.sp .5
.LP
To change the ball from red_plastic to the crystal defined above, simply
replace
.I "red_plastic sphere ball"
with
.I "crystal sphere ball".
Note once again that the definition of the new materials must
precede any references to them.
Changing the materials for the floor and ceiling of the room is a little
more difficult.
Since
.B genbox
creates six rectangles, all using the same material,
it is necessary to replace the command with its output before we can
make the required changes.
To do this, enter the command directly:
.sp .5
.QP
%
.I
genbox gray_paint room  3  2  1.75  -i >> room.rad
.R
.sp .5
.LP
The double arrow ">>" causes the output to be "appended" to the end
of the file, rather than overwriting its contents.
Now edit the file and change the ceiling
material to "white", and the floor material
to "brown".
(Hint:  the ceiling is the polygon whose z coordinates are all high.
And don't forget to remove the original
.B genbox
command from the file!)
.sp .5
.LP
Once you have chosen a nice view, you can generate a high-resolution
image in batch mode using the
.B rpict
command:
.sp .5
.QP
%
.I "rpict -vf"
myview
.I "-av  .5  .5  .5  test.oct > test.pic &"
.br
[PID]
.sp .5
.LP
The ampersand "&" causes the program to run in the background, so you can
log out and go home while the computer continues to work on your picture.
The bracketed number [PID]
printed by the C-shell command interpreter is the process
id that can be used later to check the progress or kill the program.
This number can also be determined by the
.B ps
command:
.sp .5
.QP
%
.I ps
.sp .5
.LP
The number preceding the
.B rpict
command is the process id.
If you want to kill the process later, use the command:
.sp .5
.QP
%
.I kill
PID
.sp .5
.LP
If you only want a progress report, use the form:
.sp .5
.QP
%
.I "kill -CONT"
PID
.sp .5
.LP
This sends a "continue" signal to
.B rpict,
which then prints out the percentage completion.
Note that this is a special feature of rpict, and will not work with most
programs.
Also note that this works only for the current login session.
If you log on later on a different terminal (or window),
.B rpict
will not send the report to the correct place.
It is usually a good idea, therefore, to give
.B rpict
an error file argument if it is running a long job:
.sp .5
.QP
%
.I rpict
.I -e
errfile ...
.sp .5
.LP
Now sending an alarm signal will result in
.B rpict
reporting to the end of the specified error file.
Alternatively,
you can use the
.I -t
option to generate reports automatically at regular intervals.
You can check the reports at any time by printing the file:
.sp .5
.QP
%
.I cat
errfile
.sp .5
.LP
This file will also contain a header, and any errors that occurred.
.NH
Addition of a Window
.sp .5
.LP
Adding a window to the room requires two basic steps.
The first step is to cut a hole in the wall an put in a piece of glass.
The second step is to put something outside to make the view worth having.
Since there are no explicit holes allowed in RADIANCE polygons, we use the
trick of coincident edges (making a seam) to give the appearance of a hole.
The new polygon for the window wall is shown in Figure 2.
.KF
.sp 18
.QP
.B "Figure 2."
The window wall with a hole cut in it.
.sp
.KE
.sp .5
.LP
To create the window wall, change the appropriate polygon in the scene
file (modified part in italics).
If you haven't done so already, follow the instructions in
the previous section to change the
.B genbox
command in the file to its corresponding polygons.
.sp .5
.KS
.QP
%
.I "vi room.rad"
.sp .5
.QP
.nf
gray_paint polygon room.5137
0
0
.I
30
321.75
320
300
301.75
3.6251.75
3.625.625
31.375.625
31.3751.375
3.6251.375
3.6251.75
.fi
.R
.sp .5
.KE
.LP
Next, create a separate file for the window.
(The use of separate files is desirable for parts of the scene that
will be manipulated independently, as we will see in a moment.)
.sp .5
.QP
%
.I "vi window.rad"
.sp .5
.QP
.nf
.I
# an 88% transmittance glass window has a transmission of 96%:

void glass window_glass
0
0
3 .96 .96 .96

window_glass polygon window
0
0
12
3.6251.375
31.3751.375
31.375.625
3.625.625
.fi
.R
.sp .5
.LP
The vertex order is very important, especially for polygons with holes.
Normally, vertices are listed in counterclockwise order as seen from the
front.
However, the hole of a polygon has its vertices listed in the opposite
order.
This insures that the seam does not cross itself.
.sp .5
.LP
The next step is the description of the scene outside the window.
A special purpose generator,
.B gensky,
will create a description of the sun and sky which will be
stored in a separate file.
The arguments to
.B gensky
are the month, day and hour (local standard time).
The following command produces a description for 10:00 solar time
on March 20th at latitude of 40 degrees:
.sp .5
.QP
%
.I "gensky 3 20 10 -o 0 -m 0 -a 40 > sky.rad"
.sp .5
.LP
The file "sky.rad"
contains only a description of the sun and the sky
.UL distribution.
The actual sky and ground are still undefined, so we will create another
short file containing a generic background:
.sp .5
.QP
%
.I "vi outside.rad"
.sp .5
.QP
.nf
.I
#
# A standard sky and ground to follow a gensky sun and sky distribution.
#

skyfunc glow sky_glow
0
0
4 .9 .9 1.15 0

sky_glow source sky
0
0
4 0 0 1 180

skyfunc glow ground_glow
0
0
4 1.4 .9 .6 0

ground_glow source ground
0
0
4 0 0 -1 180
.fi
.R
.sp .5
.LP
We can now put these elements together in one octree file using
.B oconv:
.sp .5
.QP
%
.I "oconv outside.rad sky.rad window.rad room.rad > test.oct"
.sp .5
.LP
Note that the above command results in the following error message:
.DS
oconv: fatal - (outside.rad): undefined modifier "skyfunc"
.DE
The modifier is undefined because we put "outside.rad",
which uses
.I skyfunc
before "sky.rad" where
.I skyfunc
is defined.
It is therefore necessary to change the order of the files so that
.I skyfunc
is defined
.UL before
it is used:
.sp .5
.QP
%
.I "oconv sky.rad outside.rad window.rad room.rad > test.oct"
.sp .5
.LP
Now let's look at our modified scene, using the same rview command as before:
.sp .5
.QP
%
.I "rview -vf default.vp -av .5 .5 .5 test.oct"
.sp .5
.LP
As you look around the scene, you will need to adjust the exposure repeatedly
to be able to see detail over the wide dynamic range now present.
To do this, wait a few seconds after choosing each new view and enter the
command:
.sp .5
.QP
:
.I "exposure 1"
.sp .5
.LP
or simply:
.sp .5
.QP
:
.I "e 1"
.sp .5
.LP
All commands in
.B rview
can be abbreviated by one or two letters.
Additional control over the exposure is possible by changing the multiplier
factor to a value greater than one to lighten or less than one to darken.
It is also possible to use absolute settings and spot normalization.
See the
.B rview
manual entry for details.
.sp .5
.LP
You may notice that other than a patch of sun on the floor, the window does
not seem to illuminate the room.
In RADIANCE, certain surfaces act as light sources and others do not.
Whether or not a surface is a light source is determined by its material
type.
Surfaces made from the material types
.I "light, illum, spotlight"
and (sometimes)
.I glow
will act as light sources, whereas surfaces made from
.I "plastic, metal, glass"
and other material types will not.
In order for the window to directly illuminate the room, it is therefore
necessary to change its material type.
We will use the type
.I illum
because it is specially designed for "secondary" light sources such as
windows and other bright objects that are not merely emitters but have
other important visual properties.
An
.I illum
will act as a light source for parts of the calculation, but when viewed
directly will appear as if made from a different material (or disappear
altogether).
.sp .5
.LP
Rather than modify the contents of "window.rad" which is a perfectly
valid description of a non-source window, let's create a new file, which
we can substitute during octree creation, called "srcwindow.rad":
.sp .5
.QP
%
.I "vi srcwindow.rad"
.sp .5
.QP
.nf
.I
#
# An emissive window
#

# visible glass type for illum:

void glass window_glass
0
0
3 .96 .96 .96

# window distribution function, including angular transmittance:

skyfunc brightfunc window_dist
2 winxmit winxmit.cal
0
0

# illum for window, using 88% transmittance at normal incidence:

window_dist illum window_illum
1 window_glass
0
3 .88 .88 .88

# the source polygon:

window_illum polygon window
0
0
12
        3       .625    1.375
        3       1.375   1.375
        3       1.375   .625
        3       .625    .625
.R
.fi
.sp .5
.LP
There are a couple of things you should notice in this file
The first definition is the normal glass type, window_glass,
which is used for the alternate material for the
.I illum
window_illum.
Next is the window distribution function, which is the sky distribution
modified by angular transmittance of glass defined in winxmit.cal.
Finally comes the
.I illum
itself, which is the secondary source material for the window.
.sp .5
.LP
To look at the scene, simply substitute "srcwindow.rad" for "window.rad"
in the previous
.B oconv
command, thus:
.sp .5
.QP
%
.I "oconv sky.rad outside.rad srcwindow.rad room.rad > test.oct"
.sp .5
.LP
You can look at the room at different times by changing the
.B gensky
command used to create "sky.rad" and regenerating the octree.
(Although the octree does not strictly need to be recreated for
.UL every
change to the input files, it is good to get in the habit until
the exceptions are well understood.)\0
.NH
Outside Geometry
.sp .5
.LP
If the exterior of a space is not approximated well by an infinitely
distant sky and ground, we can add a better description
to calculate a more accurate window output distribution as well as
a better view outside the window.
Let's add a ground plane and a nearby building to the "outside.rad"
file we created earlier:
.sp .5
.QP
.nf
.I
# Terra Firma:

void plastic ground_mat
0
0
5 .28 .18 .12 0 0

ground_mat ring groundplane
0
0
8
00-.01
001
030

# A big, ugly, mirrored glass building:

void mirror reflect20
0
0
3 .15 .2 .2

!genbox reflect20 building 10 10 2 | xform -t 10 5 0
.R
.fi
.sp .5
.LP
Note that the groundplane was given a slightly negative z value.
This is very important so that the ground does not peek through
the floor we have defined.
The material type
.I mirror,
used to define the neighboring structure, is special in RADIANCE.
Surfaces of this type as well as the types
.I prism1
and
.I prism2
participate in something called the "virtual light source" calculation.
In short, this means that the surfaces of the building we have created
will reflect sunlight and any other light source present in our scene.
The virtual light source material types should be used with care since
they can result in substantial growth in the calculation.
It would be a good idea in the example above to remove the bottom
surface of the building (which cannot be seen from the outside anyway)
and change the roof type to metal or some non-reflecting material.
This can be done using the same manual process described earlier for
changing the room surface materials.
.sp .5
.LP
Now that we have a better description of the outside, what do we do
with it?
If we simply substitute it in our scene without changing the description
of the window
.I illum,
the distribution of light from the window will be slightly wrong because
the "skybright" function only describes light from the sky and the ground,
not from other structures.
Using this approximation might be acceptable in some cases, but let's
assume that accuracy is one of our main goals in life.
There are two ways to an accurate calculation of light from a window.
The first is to treat the window as an ordinary window and rely on the
default interreflection calculation of RADIANCE, and the second is to
use the program
.B mkillum
to calculate the window distribution separately so we can still treat
it as an
.I illum
light source.
Let's try them both.
.sp .5
.LP
Using the default interreflection calculation is probably easier, but
as we shall see it takes a little longer to get a good result in this
case.
To use the interreflection calculation, we first create an octree
using the original glass window and our new description of the outside:
.sp .5
.QP
%
.I "oconv sky.rad outside.rad window.rad room.rad > test.oct"
.sp .5
.LP
Now we just add a few new options to our rview command like so:
.sp .5
.QP
%
.I "rview -vf default.vp -dr 1 -av .5 .5 .5 -ab 1 -ad 200 -as 80 -ar 80 test.oct"
.sp .5
.LP
The
.I \-dr
parameter tells
.B rview
how many reflections to allow in the virtual light source calculation.
Because of the geometry of our scene, there will never be more than
one reflection from our exterior building.
The
.I \-ab
parameter tells
.B rview
how many diffuse interreflections to follow.
When this value is 0, there is no interreflection calculation.
By setting this parameter to 1, we compute the first diffuse interreflection
(eg. from the sun patch to the wall) as well as the contribution from
the sky and exterior objects through the window.
The
.I \-ad
option tells
.B rview
how many rays to use in its initial sampling of the hemisphere for the
diffuse interreflection calculation.
We have set this value high enough so the program can find the
relatively small window and its sun patch.
The
.I \-as
option tells the program how many rays to send to particularly bright
areas of the hemisphere.
Since we know that we will have such bright areas, we set this value to
something which is around half the initial sample.
The
.I \-ar
option tells
.B rview
at what resolution it can relax the accuracy of the interreflection
calculation.
This number is relative to the overall size of our scene, which can be
determined using
.I getinfo
on the octree like so:
.sp .5
.QP
%
.I "getinfo -d test.oct"
.sp .5
.LP
This command reveals that our scene has an overall dimension of 60 (due
to the large ring we have used for our ground plane).
In order to have good resolution in our interior space, we set the value
so that 60 divided by this parameter is somewhat less than one quarter
the dimension of our interior space.
Unfortunately, many of the calculation parameters used in Radiance are
difficult to set correctly the first time, and require some experience
as well as knowledge about the calculation.
.sp .5
.LP
Probably the first thing you notice after starting
.B rview
is that nothing happens.
It takes the calculation a while to get going, as it must trace
may rays at the outset to determine the contribution at each
point from the window area.
Once
.B rview
has stored up some values, the progress rate improves, but it
never really reaches blistering speed.
.sp .5
.LP
A more efficient alternative in this case is to use the program
.B mkillum
to create a modified window file that uses calculated data values to
define its light output distribution.
Applying mkillum is relatively straightforward in this case.
You simply give it an octree defined with the normal window and the file
describing this window and it creates a new window description using
calculated data values:
.sp .5
.QP
%
.I "oconv sky.rad outside.rad window.rad room.rad > test.oct"
.br
%
.I "mkillum -av 18 18 18 -ab 0 test.oct < window.rad > mkiwindow.rad"
.sp .5
.LP
The
.I \-av
value is appropriate for the outside, which is much brighter, as
suggested by the output of the gensky command stored in "sky.rad".
The
.I \-ab
option is set to 0, because outside the building we do not expect
interreflections to play as important a role as in the interior (plus we
are trying to save some time).
The
.B mkillum
command may take a few minutes, so be patient.
If we look at the output file from
.I mkillum,
we see that it uses a pattern type called
.I brightdata,
which refers to a data file called "illum.dat".
This file contains the results of an
.B rtrace
calculation, which traced many rays in each direction from the window in
order to determine its brightness distribution.
Now we can create an octree using this new file and render it with
.B rview,
this time without the interreflection calculation:
.sp .5
.QP
%
.I "oconv sky.rad outside.rad mkiwindow.rad room.rad > test.oct"
.br
%
.I "rview -vf default.vp -av .5 .5 .5 test.oct"
.sp .5
.LP
You will notice that the calculation proceeds much more quickly, and
even produces a smoother looking result.
Aside from waiting for mkillum to finish, there is an additional price
for this speed advantage, however.
The contribution from the sun patch on the floor is no longer being
considered, since we are not performing an interreflection calculation
inside our space.
The light from the window is being taken care of by the mkillum output,
but the solar patch is not.
In most cases, we endeavor to prevent direct sun from entering the
space, and in the morning hours this is true for our model, but
otherwise it is necessary to use the diffuse interreflection calculation
to correctly account for all contributions.
.NH
Discomfort Glare
.sp .5
.LP
Especially in scenes containing daylight, situations arise where the
occupant is uncomfortable due to large differences in the brightness of
the visual field.
For example, trying to look at someone's face when they are backlit by a
bright window is difficult and painful.
We would therefore like some way to predict the effects of such bright
sources of illumination when designing a space.
RADIANCE provides just such a calculation.
.sp .5
.LP
Let's start by generating a fisheye picture of our design space:
.sp .5
.QP
%
.I "rpict -vta -vp 1.5 .8 1 -vd 0 1 0 -vh 240 -vv 180 -av .5 .5 .5 test.oct > fish.pic"
.sp .5
.LP
This picture will be used to identify sources of glare from a particular
view point (1.5, 1, 1) about a particular direction (0, 1, 0).
Since RADIANCE pictures contain true floating point radiance values,
they can be used to analyze a visual environment for problems such as
discomfort glare.
Once
.I rpict
has finished (and this may take the better part of an hour), you may
display the image using
.B ximage
or whatever display program you have available on your system.
A fisheye perspective is a type of distortion that allows a wider field
of view than a standard perspective image.
This larger field is used by the program
.I findglare
to locate any and all bright spots that might affect visual comfort.
.B Findglare
can also use direct calculation with
.B rtrace,
but this takes a long time without providing the nice visual feedback one
gets from an image.
.sp .5
.LP
To facilitate the use of
.B findglare
and the associated programs
.B glarendx
and
.B xglaresrc,
a script has been written called
.B glare.
This script asks you some questions and to make it a little easier to
get a nice result.
To start the script, simply type
.I glare
on the command line.
When it asks you a name for the glare file you want to work with, enter
something innocuous like "test.glr".
It will tell you that the file does not exist, so we will have to create
it.
It then prompts you for the name of the picture and the name of the
octree, which are "fish.pic" and "test.oct", respectively.
When it asks for the view, just hit return because we want to use the
default view from the picture file.
.B Glare
then asks what parameters it should use for the
.B rtrace
calculation.
.B (Findglare
will still use
.B rtrace
to calculate any points that it needs which are off the picture we have
given it.)\0
For this, you should give the
.I \-av
setting from before (.5 .5 .5).
Then
.B glare
will ask you if the sources of glare are small, which they are
not, and if you would like to set the glare threshold manually, which
you would not.
Finally, you will be asked
what maximum angle you want to calculate away from the view
center.
Let's use 60 degrees (to the right and left).
.B Glare
then proceeds to call the program
.B findglare
to locate the actual glare sources.
Once
.B findglare
has finished,
.B glare
will call the program
.B xglaresrc
(if you are running X) to circle the glare sources found on the image.
.sp .5
.LP
You then have a choice of a few different glare indices you may
calculated from the computed sources.
The Guth visual comfort probability (VCP) is perhaps the easiest to
understand for those who are not familiar with glare metrics, because
it gives a result in terms of a percentage of people who would be
satisfied.
Calculating the Guth VCP in this case, we see that looking straight
ahead (ie. 0 degrees), we see that less than 15% of the people would
find this visual environment comfortable.
Although the visual comfort probability increases as we look to the left
(positive angles), it never gets over 20% for the range of angles we've
given.
That is primarily because the window is unshielded and very near the
horizontal line of sight.
Skylights and ceiling fixtures are a little nicer from a glare
standpoint for that reason.