ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/radiance/ray/doc/ray.1
Revision: 1.9
Committed: Wed May 10 19:50:30 2006 UTC (17 years, 10 months ago) by greg
Branch: MAIN
Changes since 1.8: +7 -7 lines
Log Message:
Fixed language uses ("virtual" vs. "secondary" light sources)

File Contents

# User Rev Content
1 greg 1.9 .\" RCSid "$Id"
2 greg 1.1 .\" Print using the -ms macro package
3     .DA 1/20/99
4     .LP
5 greg 1.9 .tl """Copyright \(co 2003 Regents, University of California
6 greg 1.1 .sp 2
7     .TL
8     The
9     .so ../src/rt/VERSION
10     .br
11     Synthetic Imaging System
12     .AU
13 greg 1.9 Building Technologies Department
14 greg 1.1 .br
15     Lawrence Berkeley Laboratory
16     .br
17 greg 1.4 1 Cyclotron Rd., MS 90-3111
18 greg 1.1 .br
19     Berkeley, CA 94720
20     .NH 1
21     Introduction
22     .PP
23     RADIANCE was developed as a research tool
24     for predicting the distribution of visible radiation in
25     illuminated spaces.
26     It takes as input a three-dimensional geometric model of
27     the physical environment, and produces a map of
28     spectral radiance values in a color image.
29     The technique of ray-tracing follows light backwards
30     from the image plane to the source(s).
31     Because it can produce realistic images from a simple description,
32     RADIANCE has a wide range of applications in graphic arts,
33     lighting design, computer-aided engineering and architecture.
34     .KF
35     .sp 25
36     .ce
37     .B "Figure 1."
38     .sp
39     .KE
40     .PP
41     The diagram in Figure 1 shows the flow between programs (boxes) and
42     data (ovals).
43     The central program is
44     .I rpict,
45     which produces a picture from a scene description.
46     .I Rview
47     is a variation of
48     .I rpict
49     that computes and displays images interactively.
50 greg 1.4 Other programs (not shown) connect many of these elements together,
51     such as the executive programs
52     .I rad
53     and
54     .I ranimate,
55     the interactive rendering program
56     .I rholo,
57     and the animation program
58     .I ranimove.
59     The program
60     .I obj2mesh
61     acts as both a converter and scene compiler, converting a Wavefront .OBJ
62     file into a compiled mesh octree for efficient rendering.
63 greg 1.1 .PP
64     A scene description file lists the surfaces and materials
65 greg 1.4 that make up a specific environment.
66     The current surface types are spheres, polygons, cones, and cylinders.
67     There is also a composite surface type, called mesh, and a pseudosurface
68     type, called instance, which facilitates very complex geometries.
69     Surfaces can be made from materials such as plastic, metal, and glass.
70     Light sources can be distant disks as well as local spheres, disks
71     and polygons.
72 greg 1.1 .PP
73     From a three-dimensional scene description and a specified view,
74     .I rpict
75     produces a two-dimensional image.
76     A picture file is a compressed binary representation of the
77     pixels in the image.
78     This picture can be scaled in size and
79     brightness, anti-aliased, and sent to a graphics output device.
80     .PP
81     A header in each picture file lists the program(s) and
82     parameters that produced it.
83     This is useful for identifying a picture
84     without having to display it.
85     The information can be read by the program
86     .I getinfo.
87     .NH 1
88     Scene Description
89     .PP
90     A scene description file represents a
91     three-dimensional physical environment
92     in Cartesian (rectilinear) world coordinates.
93     It is stored as ASCII text, with the following basic format:
94     .DS
95     # comment
96    
97     modifier type identifier
98 greg 1.4 n S1 S2 "S 3" .. Sn
99 greg 1.1 0
100     m R1 R2 R3 .. Rm
101    
102     modifier alias identifier reference
103    
104     ! command
105    
106     ...
107     .DE
108     .PP
109     A comment line begins with a pound sign, `#'.
110     .PP
111     The scene description
112     .I primitives
113     all have the same general format, and can
114     be either surfaces or modifiers.
115     A primitive has a modifier, a type, and an identifier.
116     A modifier is either the identifier of a
117     .I "previously defined"
118     primitive, or "void"\(dg.
119     .FS
120     \(dgThe most recent definition of a modifier is the one used,
121     and later definitions do not cause relinking of loaded
122     primitives.
123     Thus, the same identifier may be used repeatedly, and each new
124     definition will apply to the primitives following it.
125     .FE
126 greg 1.4 An identifier can be any string (i.e., any sequence of non-white characters).
127 greg 1.1 The
128     .I arguments
129     associated with a primitive can be strings or real numbers.
130     The first integer following the identifier is the number
131     of string arguments, and it is followed by the arguments themselves
132 greg 1.4 (separated by white space or enclosed in quotes).
133 greg 1.1 The next integer is the number of integer arguments, and is followed
134     by the integer arguments.
135     (There are currently no primitives that use them, however.)
136     The next integer is the real argument count, and it is followed
137     by the real arguments.
138     .PP
139     An alias gets its type and arguments from a previously defined primitive.
140     This is useful when the same material is used with a different
141     modifier, or as a convenient naming mechanism.
142 greg 1.2 The reserved modifier name "inherit" may be used to specificy that
143     an alias will inherit its modifier from the original.
144 greg 1.1 Surfaces cannot be aliased.
145     .PP
146     A line beginning with an exclamation point, `!',
147     is interpreted as a command.
148     It is executed by the shell, and its output is read as input to
149     the program.
150     The command must not try to read from its standard input, or
151     confusion will result.
152     A command may be continued over multiple lines using a backslash, `\\',
153     to escape the newline.
154     .PP
155 greg 1.4 White space is generally ignored, except as a separator.
156 greg 1.1 The exception is the newline character after a command or comment.
157     Commands, comments and primitives may appear in any combination, so long
158     as they are not intermingled.
159     .NH 2
160     Primitive Types
161     .PP
162     Primitives can be surfaces, materials, textures or patterns.
163 greg 1.4 Modifiers can be materials, mixtures, textures or patterns.
164 greg 1.1 Simple surfaces must have one material in their modifier list.
165     .NH 3
166     Surfaces
167     .PP
168     A scene description will consist mostly of surfaces.
169     The basic types are given below.
170     .LP
171     .UL Source
172     .PP
173     A source is not really a surface, but a solid angle.
174     It is used for specifying light sources that are very distant.
175     The direction to the center of the source and the number of degrees
176     subtended by its disk are given as follows:
177     .DS
178     mod source id
179     0
180     0
181     4 xdir ydir zdir angle
182     .DE
183     .LP
184     .UL Sphere
185     .PP
186     A sphere is given by its center and radius:
187     .DS
188     mod sphere id
189     0
190     0
191     4 xcent ycent zcent radius
192     .DE
193     .LP
194     .UL Bubble
195     .PP
196     A bubble is simply a sphere whose surface normal points inward.
197     .LP
198     .UL Polygon
199     .PP
200     A polygon is given by a list of three-dimensional vertices,
201     which are ordered counter-clockwise as viewed from
202     the front side (into the surface normal).
203     The last vertex is automatically connected to the first.
204     Holes are represented in polygons as interior vertices connected to
205     the outer perimeter by coincident edges (seams).
206     .DS
207     mod polygon id
208     0
209     0
210     3n
211     x1 y1 z1
212     x2 y2 z2
213     ...
214     xn yn zn
215     .DE
216     .LP
217     .UL Cone
218     .PP
219     A cone is a megaphone-shaped object.
220     It is truncated by two planes perpendicular to its axis,
221     and one of its ends may come to a point.
222     It is given as two axis endpoints, and the starting
223     and ending radii:
224     .DS
225     mod cone id
226     0
227     0
228     8
229     x0 y0 z0
230     x1 y1 z1
231     r0 r1
232     .DE
233     .LP
234     .UL Cup
235     .PP
236 greg 1.4 A cup is an inverted cone (i.e., has an inward surface normal).
237 greg 1.1 .LP
238     .UL Cylinder
239     .PP
240     A cylinder is like a cone, but its starting and ending radii are
241     equal.
242     .DS
243     mod cylinder id
244     0
245     0
246     7
247     x0 y0 z0
248     x1 y1 z1
249     rad
250     .DE
251     .LP
252     .UL Tube
253     .PP
254     A tube is an inverted cylinder.
255     .LP
256     .UL Ring
257     .PP
258     A ring is a circular disk given by its center, surface
259     normal, and inner and outer radii:
260     .DS
261     mod ring id
262     0
263     0
264     8
265     xcent ycent zcent
266     xdir ydir zdir
267     r0 r1
268     .DE
269     .LP
270     .UL Mesh
271     .PP
272     A mesh is a compound surface, made up of many triangles and
273     an octree data structure to accelerate ray intersection.
274     It is typically converted from a Wavefront .OBJ file using the
275 greg 1.4 .I obj2mesh
276     program.
277 greg 1.1 .DS
278     mod mesh id
279     1+ meshfile transform
280     0
281     0
282     .DE
283 greg 1.3 If the modifier is "void", then surfaces will use the modifiers given
284     in the original mesh description.
285     Otherwise, the modifier specified is used in their place.
286 greg 1.1 The transform moves the mesh to the desired location in the scene.
287     Multiple instances using the same meshfile take little extra memory,
288     and the compiled mesh itself takes much less space than individual
289     polygons would.
290     In the case of an unsmoothed mesh, using the mesh primitive reduces
291     memory requirements by a factor of 30 relative to individual triangles.
292     If a mesh has smoothed surfaces, we save a factor of 50 or more,
293     permitting very detailed geometries that would otherwise exhaust the
294     available memory.
295     In addition, the mesh primitive can have associated (u,v) coordinates
296     for pattern and texture mapping.
297 greg 1.4 These are made available to function files via the Lu and Lv variables.
298 greg 1.1 .LP
299     .UL Instance
300     .PP
301     An instance is a compound surface, given by the contents of an
302     octree file (created by oconv).
303     .DS
304     mod instance id
305     1+ octree transform
306     0
307     0
308     .DE
309     If the modifier is "void", then surfaces will use the modifiers given
310     in the original description.
311     Otherwise, the modifier specified is used in their place.
312     The transform moves the octree to the desired location in the scene.
313     Multiple instances using the same octree take little extra memory,
314     hence very complex descriptions can be rendered using this primitive.
315     .PP
316     There are a number of important limitations to be aware of when using
317     instances.
318     First, the scene description used to generate the octree must stand on
319     its own, without referring to modifiers in the parent description.
320     This is necessary for oconv to create the octree.
321     Second, light sources in the octree will not be incorporated correctly
322     in the calculation, and they are not recommended.
323     Finally, there is no advantage (other than convenience) to
324     using a single instance of an octree, or an octree containing only a
325     few surfaces.
326     An xform command on the subordinate description is prefered in such cases.
327     .NH 3
328     Materials
329     .PP
330     A material defines the way light interacts with a surface.
331     The basic types are given below.
332     .LP
333     .UL Light
334     .PP
335 greg 1.4 Light is the basic material for self-luminous surfaces (i.e., light
336 greg 1.1 sources).
337     In addition to the source surface type, spheres, discs (rings with zero
338     inner radius), cylinders (provided they are long enough), and
339     polygons can act as light sources.
340     Polygons work best when they are rectangular.
341     Cones cannot be used at this time.
342     A pattern may be used to specify a light output distribution.
343     Light is defined simply as a RGB radiance value (watts/steradian/m2):
344     .DS
345     mod light id
346     0
347     0
348     3 red green blue
349     .DE
350     .LP
351     .UL Illum
352     .PP
353     Illum is used for secondary light sources with broad distributions.
354     A secondary light source is treated like any other
355     light source, except when viewed directly.
356     It then acts like it is made of a different material (indicated by
357     the string argument), or becomes invisible (if no string argument is given,
358     or the argument is "void").
359     Secondary sources are useful when modeling windows or
360     brightly illuminated surfaces.
361     .DS
362     mod illum id
363     1 material
364     0
365     3 red green blue
366     .DE
367     .LP
368     .UL Glow
369     .PP
370     Glow is used for surfaces that are self-luminous, but limited
371     in their effect.
372     In addition to the radiance value, a maximum radius for
373     shadow testing is given:
374     .DS
375     mod glow id
376     0
377     0
378     4 red green blue maxrad
379     .DE
380     If maxrad is zero, then the surface will never be tested
381     for shadow, although it may participate in an interreflection calculation.
382     If maxrad is negative, then the surface will never contribute to scene
383     illumination.
384     Glow sources will never illuminate objects on the other side of an
385     illum surface.
386     This provides a convenient way to illuminate local light fixture
387     geometry without overlighting nearby objects.
388     .LP
389     .UL Spotlight
390     .PP
391     Spotlight is used for self-luminous surfaces having directed output.
392     As well as radiance, the full cone angle (in degrees)
393     and orientation (output direction) vector are given.
394     The length of the orientation vector is the distance
395 greg 1.4 of the effective focus behind the source center (i.e., the focal length).
396 greg 1.1 .DS
397     mod spotlight id
398     0
399     0
400     7 red green blue angle xdir ydir zdir
401     .DE
402     .LP
403     .UL Mirror
404     .PP
405 greg 1.9 Mirror is used for planar surfaces that produce virtual
406 greg 1.1 source reflections.
407     This material should be used sparingly, as it may cause the light
408     source calculation to blow up if it is applied to many small surfaces.
409     This material is only supported for flat surfaces such as polygons
410     and rings.
411     The arguments are simply the RGB reflectance values, which should be
412     between 0 and 1.
413     An optional string argument may be used like the illum type to specify a
414     different material to be used for shading non-source rays.
415     If this alternate material is given as "void", then the mirror surface
416     will be invisible.
417     This is only appropriate if the surface hides other (more detailed)
418     geometry with the same overall reflectance.
419     .DS
420     mod mirror id
421     1 material
422     0
423     3 red green blue
424     .DE
425     .LP
426     .UL Prism1
427     .PP
428     The prism1 material is for general light redirection from prismatic
429 greg 1.9 glazings, generating virtual light sources.
430 greg 1.4 It can only be used to modify a planar surface (i.e., a polygon or disk)
431 greg 1.1 and should not result in either light concentration or scattering.
432     The new direction of the ray can be on either side of the material,
433     and the definitions must have the correct bidirectional properties
434 greg 1.9 to work properly with virtual light sources.
435 greg 1.1 The arguments give the coefficient for the redirected light
436     and its direction.
437     .DS
438     mod prism1 id
439     5+ coef dx dy dz funcfile transform
440     0
441     n A1 A2 .. An
442     .DE
443     The new direction variables
444     .I "dx, dy"
445     and
446     .I dz
447     need not produce a normalized vector.
448     For convenience, the variables
449     .I "DxA, DyA"
450     and
451     .I DzA
452     are defined as the normalized direction to the target light source.
453     See section 2.2.1 on function files for further information.
454     .LP
455     .UL Prism2
456     .PP
457     The material prism2 is identical to prism1 except that
458     it provides for two ray redirections rather than one.
459     .DS
460     mod prism2 id
461     9+ coef1 dx1 dy1 dz1 coef2 dx2 dy2 dz2 funcfile transform
462     0
463     n A1 A2 .. An
464     .DE
465     .LP
466     .UL Mist
467     .PP
468     Mist is a virtual material used to delineate a volume
469     of participating atmosphere.
470     A list of important light sources may be given, along with an
471     extinction coefficient, scattering albedo and scattering eccentricity
472     parameter.
473     The light sources named by the string argument list
474     will be tested for scattering within the volume.
475     Sources are identified by name, and virtual light sources may be indicated
476     by giving the relaying object followed by '>' followed by the source, i.e:
477     .DS
478     3 source1 mirror1>source10 mirror2>mirror1>source3
479     .DE
480     Normally, only one source is given per mist material, and there is an
481     upper limit of 32 to the total number of active scattering sources.
482     The extinction coefficient, if given, is added to the global
483     coefficient set on the command line.
484     Extinction is in units of 1/distance (distance based on the world coordinates),
485     and indicates the proportional loss of radiance over one unit distance.
486     The scattering albedo, if present, will override the global setting within
487     the volume.
488     An albedo of 0\00\00 means a perfectly absorbing medium, and an albedo of
489     1\01\01\0 means
490     a perfectly scattering medium (no absorption).
491     The scattering eccentricity parameter will likewise override the global
492     setting if it is present.
493     Scattering eccentricity indicates how much scattered light favors the
494     forward direction, as fit by the Heyney-Greenstein function:
495     .DS
496     P(theta) = (1 - g*g) / (1 + g*g - 2*g*cos(theta))^1.5
497     .DE
498     A perfectly isotropic scattering medium has a g parameter of 0, and
499     a highly directional material has a g parameter close to 1.
500     Fits to the g parameter may be found along with typical extinction
501     coefficients and scattering albedos for various atmospheres and
502     cloud types in USGS meteorological tables.
503     (A pattern will be applied to the extinction values.)\0
504     .DS
505     mod mist id
506     N src1 src2 .. srcN
507     0
508     0|3|6|7 [ rext gext bext [ ralb galb balb [ g ] ] ]
509     .DE
510     There are two usual uses of the mist type.
511     One is to surround a beam from a spotlight or laser so that it is
512     visible during rendering.
513     For this application, it is important to use a cone (or cylinder) that
514     is long enough and wide enough to contain the important visible portion.
515     Light source photometry and intervening objects will have the desired
516     effect, and crossing beams will result in additive scattering.
517     For this application, it is best to leave off the real arguments, and
518     use the global rendering parameters to control the atmosphere.
519     The second application is to model clouds or other localized media.
520     Complex boundary geometry may be used to give shape to a uniform medium,
521     so long as the boundary encloses a proper volume.
522     Alternatively, a pattern may be used to set the line integral value
523     through the cloud for a ray entering or exiting a point in a given
524     direction.
525     For this application, it is best if cloud volumes do not overlap each other,
526     and opaque objects contained within them may not be illuminated correctly
527     unless the line integrals consider enclosed geometry.
528     .LP
529     .UL Plastic
530     .PP
531     Plastic is a material with uncolored highlights.
532     It is given by its RGB reflectance, its fraction of specularity,
533     and its roughness value.
534     Roughness is specified as the rms slope of surface facets.
535     A value of 0 corresponds to a perfectly smooth surface, and
536     a value of 1 would be a very rough surface.
537     Specularity fractions greater than 0.1 and
538     roughness values greater than 0.2 are not very
539     realistic.
540     (A pattern modifying plastic will affect the material color.)
541     .DS
542     mod plastic id
543     0
544     0
545     5 red green blue spec rough
546     .DE
547     .LP
548     .UL Metal
549     .PP
550     Metal is similar to plastic, but specular highlights
551     are modified by the material color.
552     Specularity of metals is usually .9 or greater.
553     As for plastic, roughness values above .2 are uncommon.
554     .LP
555     .UL Trans
556     .PP
557     Trans is a translucent material, similar to plastic.
558     The transmissivity is the fraction of penetrating light that
559     travels all the way through the material.
560     The transmitted specular component is the fraction of transmitted
561     light that is not diffusely scattered.
562     Transmitted and diffusely reflected light is modified by the material color.
563     Translucent objects are infinitely thin.
564     .DS
565     mod trans id
566     0
567     0
568     7 red green blue spec rough trans tspec
569     .DE
570     .LP
571     .UL Plastic2
572     .PP
573     Plastic2 is similar to plastic, but with anisotropic
574     roughness.
575     This means that highlights in the surface will appear elliptical rather
576     than round.
577     The orientation of the anisotropy is determined by the unnormalized
578     direction vector
579     .I "ux uy uz".
580     These three expressions (separated by white space) are evaluated in
581     the context of the function file
582     .I funcfile.
583 greg 1.4 If no function file is required (i.e., no special variables or
584 greg 1.1 functions are required), a period (`.') may be given in its
585     place.
586     (See the discussion of Function Files in the Auxiliary Files section).
587     The
588     .I urough
589     value defines the roughness along the
590     .B u
591     vector given projected onto the surface.
592     The
593     .I vrough
594     value defines the roughness perpendicular to this vector.
595     Note that the highlight will be narrower in the direction of the
596     smaller roughness value.
597     Roughness values of zero are not allowed for efficiency reasons
598     since the behavior would be the same as regular plastic in that
599     case.
600     .DS
601     mod plastic2 id
602     4+ ux uy uz funcfile transform
603     0
604     6 red green blue spec urough vrough
605     .DE
606     .LP
607     .UL Metal2
608     .PP
609     Metal2 is the same as plastic2, except that the highlights are
610     modified by the material color.
611     .LP
612     .UL Trans2
613     .PP
614     Trans2 is the anisotropic version of trans.
615     The string arguments are the same as for plastic2, and the real
616     arguments are the same as for trans but with an additional roughness
617     value.
618     .DS
619     mod trans2 id
620     4+ ux uy uz funcfile transform
621     0
622     8 red green blue spec urough vrough trans tspec
623     .DE
624     .LP
625     .UL Dielectric
626     .PP
627     A dielectric material is transparent, and it refracts light
628     as well as reflecting it.
629     Its behavior is determined by the index of refraction and
630     transmission coefficient in each wavelength band per unit length.
631     Common glass has a index of refraction (n) around 1.5,
632     and a transmission coefficient of roughly 0.92 over an inch.
633     An additional number, the Hartmann constant, describes how
634     the index of refraction changes as a function of wavelength.
635     It is usually zero.
636     (A pattern modifies only the refracted value.)
637     .DS
638     mod dielectric id
639     0
640     0
641     5 rtn gtn btn n hc
642     .DE
643     .LP
644     .UL Interface
645     .PP
646     An interface is a boundary between two dielectrics.
647     The first transmission coefficient and refractive index are for the inside;
648     the second ones are for the outside.
649     Ordinary dielectrics are surrounded by a vacuum (1 1 1 1).
650     .DS
651     mod interface id
652     0
653     0
654     8 rtn1 gtn1 btn1 n1 rtn2 gtn2 btn2 n2
655     .DE
656     .LP
657     .UL Glass
658     .PP
659     Glass is similar to dielectric, but it is optimized for thin glass
660     surfaces (n = 1.52).
661     One transmitted ray and one reflected ray is produced.
662     By using a single surface is in place of two, internal reflections
663     are avoided.
664     The surface orientation is irrelevant, as it is for plastic,
665     metal, and trans.
666     The only specification required is the transmissivity at normal
667     incidence.
668     (Transmissivity is the amount of light not absorbed in one traversal
669     of the material.
670     Transmittance -- the value usually measured -- is the total light
671     transmitted through the pane including multiple reflections.)\0
672     To compute transmissivity (tn) from transmittance (Tn) use:
673     .DS
674     tn = (sqrt(.8402528435+.0072522239*Tn*Tn)-.9166530661)/.0036261119/Tn
675     .DE
676     Standard 88% transmittance glass has a transmissivity of 0.96.
677     (A pattern modifying glass will affect the transmissivity.)
678     If a fourth real argument is given, it is interpreted as the index of
679     refraction to use instead of 1.52.
680     .DS
681     mod glass id
682     0
683     0
684     3 rtn gtn btn
685     .DE
686     .LP
687     .UL Plasfunc
688     .PP
689     Plasfunc in used for the procedural definition of plastic-like
690     materials with arbitrary bidirectional reflectance distribution
691     functions (BRDF's).
692     The arguments to this material include the color and specularity,
693     as well as the function defining the specular distribution and the
694     auxiliary file where it may be found.
695     .DS
696     mod plasfunc id
697     2+ refl funcfile transform
698     0
699     4+ red green blue spec A5 ..
700     .DE
701     The function
702     .I refl
703     takes four arguments, the x, y and z
704     direction towards the incident light, and the solid angle
705     subtended by the source.
706     The solid angle is provided to facilitate averaging, and is usually
707     ignored.
708     The
709     .I refl
710     function should integrate to 1 over
711     the projected hemisphere to maintain energy balance.
712     At least four real arguments must be given, and these are made
713     available along with any additional values to the reflectance
714     function.
715     Currently, only the contribution from direct light sources is
716     considered in the specular calculation.
717     As in most material types, the surface normal is always
718     altered to face the incoming ray.
719     .LP
720     .UL Metfunc
721     .PP
722     Metfunc is identical to plasfunc and takes the same arguments, but
723     the specular component is multiplied also by the material color.
724     .LP
725     .UL Transfunc
726     .PP
727     Transfunc is similar to plasfunc but with an arbitrary bidirectional
728     transmittance distribution as well as a reflectance distribution.
729     Both reflectance and transmittance are specified with the same function.
730     .DS
731     mod transfunc id
732     2+ brtd funcfile transform
733     0
734     6+ red green blue rspec trans tspec A7 ..
735     .DE
736     Where
737     .I trans
738     is the total light transmitted and
739     .I tspec
740     is the non-Lambertian fraction of transmitted light.
741     The function
742     .I brtd
743     should integrate to 1 over each projected hemisphere.
744     .LP
745     .UL BRTDfunc
746     .PP
747     The material BRTDfunc gives the maximum flexibility over surface
748     reflectance and transmittance, providing for spectrally-dependent
749     specular rays and reflectance and transmittance distribution functions.
750     .DS
751     mod BRTDfunc id
752     10+ rrefl grefl brefl
753     rtrns gtrns btrns
754     rbrtd gbrtd bbrtd
755     funcfile transform
756     0
757     9+ rfdif gfdif bfdif
758     rbdif gbdif bbdif
759     rtdif gtdif btdif
760     A10 ..
761     .DE
762     The variables
763     .I "rrefl, grefl"
764     and
765     .I brefl
766     specify the color coefficients for
767     the ideal specular (mirror) reflection of the surface.
768     The variables
769     .I "rtrns, gtrns"
770     and
771     .I btrns
772     specify the color coefficients for the ideal specular transmission.
773     The functions
774     .I "rbrtd, gbrtd"
775     and
776     .I bbrtd
777     take the direction to the incident light (and its solid angle)
778     and compute the color coefficients for the directional diffuse part of
779     reflection and transmission.
780     As a special case, three identical values of '0' may be given in place of
781     these function names to indicate no directional diffuse component.
782     .PP
783     Unlike most other material types, the surface normal is not altered to
784     face the incoming ray.
785     Thus, functions and variables must pay attention to the orientation of
786     the surface and make adjustments appropriately.
787     However, the special variables for the perturbed dot product and surface
788     normal,
789     .I "RdotP, NxP, NyP"
790     and
791     .I NzP
792     are reoriented as if the ray hit the front surface for convenience.
793     .PP
794     A diffuse reflection component may be given for the front side with
795     .I "rfdif, gfdif"
796     and
797     .I bfdif
798     for the front side of the surface or
799     .I "rbdif, gbdif"
800     and
801     .I bbdif
802     for the back side.
803     The diffuse transmittance (must be the same for both sides by physical law)
804     is given by
805     .I "rtdif, gtdif"
806     and
807     .I btdif.
808     A pattern will modify these diffuse scattering values,
809     and will be available through the special variables
810     .I "CrP, CgP"
811     and
812     .I CbP.
813     .PP
814     Care must be taken when using this material type to produce a physically
815     valid reflection model.
816     The reflectance functions should be bidirectional, and under no circumstances
817     should the sum of reflected diffuse, transmitted diffuse, reflected specular,
818     transmitted specular and the integrated directional diffuse component be
819     greater than one.
820     .LP
821     .UL Plasdata
822     .PP
823     Plasdata is used for arbitrary BRDF's that are most conveniently
824     given as interpolated data.
825     The arguments to this material are the data file and coordinate index
826     functions, as well as a function to optionally modify the data
827     values.
828     .DS
829     mod plasdata id
830     3+n+
831     func datafile
832     funcfile x1 x2 .. xn transform
833     0
834     4+ red green blue spec A5 ..
835     .DE
836     The coordinate indices
837     .I "(x1, x2,"
838     etc.) are themselves functions of
839     the x, y and z direction to the incident light, plus the solid angle
840     subtended by the light source (usually ignored).
841     The data function
842     .I (func)
843     takes five variables, the
844     interpolated value from the n-dimensional data file, followed by the
845     x, y and z direction to the incident light and the solid angle of the source.
846     The light source direction and size may of course be ignored by the function.
847     .LP
848     .UL Metdata
849     .PP
850     As metfunc is to plasfunc, metdata is to plasdata.
851     Metdata takes the same arguments as plasdata, but the specular
852     component is modified by the given material color.
853     .LP
854     .UL Transdata
855     .PP
856     Transdata is like plasdata but the specification includes transmittance
857     as well as reflectance.
858     The parameters are as follows.
859     .DS
860     mod transdata id
861     3+n+
862     func datafile
863     funcfile x1 x2 .. xn transform
864     0
865     6+ red green blue rspec trans tspec A7 ..
866     .DE
867     .LP
868     .UL Antimatter
869     .PP
870     Antimatter is a material that can "subtract" volumes from other volumes.
871     A ray passing into an antimatter object becomes blind to all the specified
872     modifiers:
873     .DS
874     mod antimatter id
875     N mod1 mod2 .. modN
876     0
877     0
878     .DE
879     The first modifier will also be used to shade the area leaving the
880     antimatter volume and entering the regular volume.
881     If mod1 is void, the antimatter volume is completely invisible.
882     Antimatter does not work properly with the material type "trans",
883     and multiple antimatter surfaces should be disjoint.
884     The viewpoint must be outside all volumes concerned for a correct
885     rendering.
886     .NH 3
887     Textures
888     .PP
889     A texture is a perturbation of the surface normal, and
890     is given by either a function or data.
891     .LP
892     .UL Texfunc
893     .PP
894     A texfunc uses an auxiliary function file
895     to specify a procedural texture:
896     .DS
897     mod texfunc id
898     4+ xpert ypert zpert funcfile transform
899     0
900     n A1 A2 .. An
901     .DE
902     .LP
903     .UL Texdata
904     .PP
905     A texdata texture uses three data files to get the surface
906     normal perturbations.
907     The variables
908     .I xfunc,
909     .I yfunc
910     and
911     .I zfunc
912     take three arguments
913     each from the interpolated values in
914     .I xdfname,
915     .I ydfname
916     and
917     .I zdfname.
918     .DS
919     mod texdata id
920     8+ xfunc yfunc zfunc xdfname ydfname zdfname vfname x0 x1 .. xf
921     0
922     n A1 A2 .. An
923     .DE
924     .NH 3
925     Patterns
926     .PP
927     Patterns are used to modify the reflectance of materials.
928     The basic types are given below.
929     .LP
930     .UL Colorfunc
931     .PP
932     A colorfunc is a procedurally defined color pattern.
933     It is specified as follows:
934     .DS
935     mod colorfunc id
936     4+ red green blue funcfile transform
937     0
938     n A1 A2 .. An
939     .DE
940     .LP
941     .UL Brightfunc
942     .PP
943     A brightfunc is the same as a colorfunc, except it is monochromatic.
944     .DS
945     mod brightfunc id
946     2+ refl funcfile transform
947     0
948     n A1 A2 .. An
949     .DE
950     .LP
951     .UL Colordata
952     .PP
953     Colordata uses an interpolated data map to modify a material's color.
954     The map is n-dimensional, and is stored in three
955     auxiliary files, one for each color.
956     The coordinates used to look up and interpolate the data are
957     defined in another auxiliary file.
958     The interpolated data values are modified by functions of
959     one or three variables.
960     If the functions are of one variable, then they are passed the
961     corresponding color component (red or green or blue).
962     If the functions are of three variables, then they are passed the
963     original red, green, and blue values as parameters.
964     .DS
965     mod colordata id
966     7+n+
967     rfunc gfunc bfunc rdatafile gdatafile bdatafile
968     funcfile x1 x2 .. xn transform
969     0
970     m A1 A2 .. Am
971     .DE
972     .LP
973     .UL Brightdata
974     .PP
975     Brightdata is like colordata, except monochromatic.
976     .DS
977     mod brightdata id
978     3+n+
979     func datafile
980     funcfile x1 x2 .. xn transform
981     0
982     m A1 A2 .. Am
983     .DE
984     .LP
985     .UL Colorpict
986     .PP
987     Colorpict is a special case of colordata, where the pattern is
988     a two-dimensional image stored in the RADIANCE picture format.
989     The dimensions of the image data are determined by the picture
990     such that the smaller dimension is always 1, and the other
991     is the ratio between the larger and the smaller.
992     For example, a 500x338 picture would have coordinates (u,v)
993     in the rectangle between (0,0) and (1.48,1).
994     .DS
995     mod colorpict id
996     7+
997     rfunc gfunc bfunc pictfile
998     funcfile u v transform
999     0
1000     m A1 A2 .. Am
1001     .DE
1002     .LP
1003     .UL Colortext
1004     .PP
1005     Colortext is dichromatic writing in a polygonal font.
1006     The font is defined in an auxiliary file, such as
1007     .I helvet.fnt.
1008     The text itself is also specified in a separate file, or
1009     can be part of the material arguments.
1010     The character size, orientation, aspect ratio and slant is
1011     determined by right and down motion vectors.
1012     The upper left origin for the text block as well as
1013     the foreground and background colors
1014     must also be given.
1015     .DS
1016     mod colortext id
1017     2 fontfile textfile
1018     0
1019     15+
1020     Ox Oy Oz
1021     Rx Ry Rz
1022     Dx Dy Dz
1023     rfore gfore bfore
1024     rback gback bback
1025     [spacing]
1026     .DE
1027     or:
1028     .DS
1029     mod colortext id
1030     2+N fontfile . This is a line with N words ...
1031     0
1032     15+
1033     Ox Oy Oz
1034     Rx Ry Rz
1035     Dx Dy Dz
1036     rfore gfore bfore
1037     rback gback bback
1038     [spacing]
1039     .DE
1040     .LP
1041     .UL Brighttext
1042     .PP
1043     Brighttext is like colortext, but the writing is monochromatic.
1044     .DS
1045     mod brighttext id
1046     2 fontfile textfile
1047     0
1048     11+
1049     Ox Oy Oz
1050     Rx Ry Rz
1051     Dx Dy Dz
1052     foreground background
1053     [spacing]
1054     .DE
1055     or:
1056     .DS
1057     mod brighttext id
1058     2+N fontfile . This is a line with N words ...
1059     0
1060     11+
1061     Ox Oy Oz
1062     Rx Ry Rz
1063     Dx Dy Dz
1064     foreground background
1065     [spacing]
1066     .DE
1067     .LP
1068     By default, a uniform spacing algorithm is used that guarantees
1069     every character will appear in a precisely determined position.
1070     Unfortunately, such a scheme results in rather unattractive and difficult to
1071     read text with most fonts.
1072     The optional
1073     .I spacing
1074     value defines the distance between characters for proportional spacing.
1075     A positive value selects a spacing algorithm that preserves right margins and
1076     indentation, but does not provide the ultimate in proportionally spaced text.
1077     A negative value insures that characters are properly spaced, but the
1078     placement of words then varies unpredictably.
1079     The choice depends on the relative importance of spacing versus formatting.
1080     When presenting a section of formatted text, a positive spacing value is
1081     usually preferred.
1082     A single line of text will often be accompanied by a negative spacing value.
1083     A section of text meant to depict a picture, perhaps using a special purpose
1084     font such as hexbit4x1.fnt, calls for uniform spacing.
1085     Reasonable magnitudes for proportional spacing are
1086     between 0.1 (for tightly spaced characters) and 0.3 (for wide spacing).
1087     .NH 3
1088     Mixtures
1089     .PP
1090     A mixture is a blend of one or more materials or textures and patterns.
1091     The basic types are given below.
1092     .LP
1093     .UL Mixfunc
1094     .PP
1095     A mixfunc mixes two modifiers procedurally.
1096     It is specified as follows:
1097     .DS
1098     mod mixfunc id
1099     4+ foreground background vname funcfile transform
1100     0
1101     n A1 A2 .. An
1102     .DE
1103     Foreground and background are modifier names that must be
1104     defined earlier in the scene description.
1105     If one of these is a material, then
1106     the modifier of the mixfunc must be "void".
1107     (Either the foreground or background modifier may be "void",
1108     which serves as a form of opacity control when used with a material.)\0
1109     Vname is the coefficient defined in funcfile that determines the influence
1110     of foreground.
1111     The background coefficient is always (1-vname).
1112     Since the references are not resolved until runtime, the last
1113     definitions of the modifier id's will be used.
1114     This can result in modifier loops, which are detected by the
1115     renderer.
1116     .LP
1117     .UL Mixdata
1118     .PP
1119     Mixdata combines two modifiers using an auxiliary data file:
1120     .DS
1121     mod mixdata id
1122     5+n+
1123     foreground background func datafile
1124     funcfile x1 x2 .. xn transform
1125     0
1126     m A1 A2 .. Am
1127     .DE
1128     .LP
1129     .UL Mixpict
1130     .PP
1131     Mixpict combines two modifiers based on a picture:
1132     .DS
1133     mod mixpict id
1134     7+
1135     foreground background func pictfile
1136     funcfile u v transform
1137     0
1138     m A1 A2 .. Am
1139     .DE
1140     The mixing coefficient function "func" takes three
1141     arguments, the red, green and blue values
1142     corresponding to the pixel at (u,v).
1143     .LP
1144     .UL Mixtext
1145     .PP
1146     Mixtext uses one modifier for the text foreground, and one for the
1147     background:
1148     .DS
1149     mod mixtext id
1150     4 foreground background fontfile textfile
1151     0
1152     9+
1153     Ox Oy Oz
1154     Rx Ry Rz
1155     Dx Dy Dz
1156     [spacing]
1157     .DE
1158     or:
1159     .DS
1160     mod mixtext id
1161     4+N
1162     foreground background fontfile .
1163     This is a line with N words ...
1164     0
1165     9+
1166     Ox Oy Oz
1167     Rx Ry Rz
1168     Dx Dy Dz
1169     [spacing]
1170     .DE
1171     .NH 2
1172     Auxiliary Files
1173     .PP
1174     Auxiliary files used in textures and patterns
1175     are accessed by the programs during image generation.
1176     These files may be located in the working directory, or in
1177     a library directory.
1178     The environment variable
1179     .I RAYPATH
1180     can be assigned an alternate set of search directories.
1181     Following is a brief description of some common file types.
1182     .NH 3
1183     Function Files
1184     .PP
1185     A function file contains the definitions of variables, functions
1186     and constants used by a primitive.
1187     The transformation that accompanies the file name contains the necessary
1188     rotations, translations and scalings to bring the coordinates of
1189     the function file into agreement with the world coordinates.
1190     The transformation specification is the same as for the
1191     .I xform
1192     command.
1193     An example function file is given below:
1194     .DS
1195     {
1196     This is a comment, enclosed in curly braces.
1197     {Comments can be nested.}
1198     }
1199     { standard expressions use +,-,*,/,^,(,) }
1200     vname = Ny * func(A1) ;
1201     { constants are defined with a colon }
1202     const : sqrt(PI/2) ;
1203     { user-defined functions add to library }
1204     func(x) = 5 + A1*sin(x/3) ;
1205     { functions may be passed and recursive }
1206     rfunc(f,x) = if(x,f(x),f(-x)*rfunc(f,x+1)) ;
1207     { constant functions may also be defined }
1208     cfunc(x) : 10*x / sqrt(x) ;
1209     .DE
1210     Many variables and functions are already defined by the program,
1211     and they are listed in the file
1212     .I rayinit.cal.
1213     The following variables are particularly important:
1214     .DS
1215     Dx, Dy, Dz - incident ray direction
1216 greg 1.4 Nx, Ny, Nz - surface normal at intersection point
1217 greg 1.1 Px, Py, Pz - intersection point
1218 greg 1.4 T - distance from start
1219     Ts - single ray (shadow) distance
1220 greg 1.1 Rdot - cosine between ray and normal
1221     arg(0) - number of real arguments
1222     arg(i) - i'th real argument
1223     .DE
1224 greg 1.4 For mesh objects, the local surface coordinates are available:
1225     .DS
1226     Lu, Lv - local (u,v) coordinates
1227     .DE
1228 greg 1.1 For BRDF types, the following variables are defined as well:
1229     .DS
1230     NxP, NyP, NzP - perturbed surface normal
1231     RdotP - perturbed dot product
1232     CrP, CgP, CbP - perturbed material color
1233     .DE
1234     A unique context is set up for each file so that the same variable
1235     may appear in different function files without conflict.
1236     The variables listed above and any others defined in
1237     rayinit.cal are available globally.
1238     If no file is needed by a given primitive because all the required
1239     variables are global, a period (`.') can be given in
1240     place of the file name.
1241     It is also possible to give an expression instead of a straight
1242     variable name in a scene file, although such expressions should
1243 greg 1.4 be kept simple if possible.
1244 greg 1.1 Also, functions (requiring parameters)
1245     must be given as names and not as expressions.
1246     .PP
1247     Constant expressions are used as an optimization in function
1248     files.
1249     They are replaced wherever they occur in an expression by their
1250     value.
1251     Constant expressions are evaluated only once, so they must not
1252     contain any variables or values that can change, such as the ray
1253     variables Px and Ny or the primitive argument function arg().
1254     All the math library functions such as sqrt() and cos() have the
1255     constant attribute, so they will be replaced by immediate values
1256     whenever they are given constant arguments.
1257     Thus, the subexpression cos(PI*sqrt(2)) is immediately replaced
1258     by its value, -.266255342, and does not cause any additional overhead
1259     in the calculation.
1260     .PP
1261     It is generally a good idea to define constants and variables before
1262     they are referred to in a function file.
1263     Although evaluation does not take place until later, the interpreter
1264     does variable scoping and constant subexpression evaluation based on
1265     what it has compiled already.
1266     For example, a variable that is defined globally in rayinit.cal then
1267     referenced in the local context of a function file cannot
1268     subsequently be redefined in the same file because the compiler
1269     has already determined the scope of the referenced variable as global.
1270     To avoid such conflicts, one can state the scope of a variable explicitly
1271     by preceding the variable name with a context mark (a back-quote) for
1272     a local variable, or following the name with a context mark for a global
1273     variable.
1274     .NH 3
1275     Data Files
1276     .PP
1277     Data files contain n-dimensional arrays of real numbers used
1278     for interpolation.
1279     Typically, definitions in a function file determine how
1280     to index and use interpolated data values.
1281     The basic data file format is as follows:
1282     .DS
1283     N
1284     beg1 end1 m1
1285     0 0 m2 x2.1 x2.2 x2.3 x2.4 .. x2.m2
1286     ...
1287     begN endN mN
1288     DATA, later dimensions changing faster.
1289     .DE
1290     N is the number of dimensions.
1291     For each dimension, the beginning and ending coordinate
1292     values and the dimension size is given.
1293     Alternatively, individual coordinate values can be given when
1294     the points are not evenly spaced.
1295     These values must either be increasing or decreasing monotonically.
1296     The data is m1*m2*...*mN real numbers in ASCII form.
1297     Comments may appear anywhere in the file, beginning with a pound
1298     sign ('#') and continuing to the end of line.
1299     .NH 3
1300     Font Files
1301     .PP
1302     A font file lists the polygons which make up a character set.
1303     Comments may appear anywhere in the file, beginning with a pound
1304     sign ('#') and continuing to the end of line.
1305     All numbers are decimal integers:
1306     .DS
1307     code n
1308     x0 y0
1309     x1 y1
1310     ...
1311     xn yn
1312     ...
1313     .DE
1314     The ASCII codes can appear in any order.
1315     N is the number of vertices, and the last is automatically
1316     connected to the first.
1317     Separate polygonal sections are joined by coincident sides.
1318     The character coordinate system is a square with lower left corner at
1319     (0,0), lower right at (255,0) and upper right at (255,255).
1320     .NH 2
1321     Generators
1322     .PP
1323     A generator is any program that produces a scene description
1324     as its output.
1325     They usually appear as commands in a scene description file.
1326     An example of a simple generator is
1327     .I genbox.
1328     .I Genbox
1329     takes the arguments of width, height and depth to produce
1330     a parallelepiped description.
1331     .I Genprism
1332     takes a list of 2-dimensional coordinates and extrudes them along a vector to
1333     produce a 3-dimensional prism.
1334     .I Genrev
1335     is a more sophisticated generator
1336     that produces an object of rotation from parametric functions
1337     for radius and axis position.
1338     .I Gensurf
1339     tessellates a surface defined by the
1340     parametric functions x(s,t), y(s,t), and z(s,t).
1341     .I Genworm
1342     links cylinders and spheres along a curve.
1343     .I Gensky
1344     produces a sun and sky distribution corresponding
1345     to a given time and date.
1346     .PP
1347     .I Xform
1348     is a program that transforms a scene description from one
1349     coordinate space to another.
1350     .I Xform
1351     does rotation, translation, scaling, and mirroring.
1352     .NH 1
1353     Image Generation
1354     .PP
1355     Once the scene has been described in three-dimensions, it
1356     is possible to generate a two-dimensional image from a
1357     given perspective.
1358     .PP
1359     The image generating programs use an
1360     .I octree
1361     to efficiently trace rays through the scene.
1362     An octree subdivides space into nested octants which
1363     contain sets of surfaces.
1364     In RADIANCE, an octree is created from a scene description by
1365     .I oconv.
1366     The details of this process are not important,
1367     but the octree will serve as input to the ray-tracing
1368     programs and directs the use of a scene description.
1369     .PP
1370     .I Rview
1371     is ray-tracing program for viewing a scene interactively.
1372     When the user specifies a new perspective,
1373 greg 1.9 .I rview
1374 greg 1.1 quickly displays a rough
1375     image on the terminal, then progressively
1376     increases the resolution as the user looks on.
1377     He can select a particular section of the image to improve,
1378     or move to a different view and start over.
1379     This mode of interaction is useful for debugging scenes
1380     as well as determining the best view for a final image.
1381     .PP
1382     .I Rpict
1383     produces a high-resolution picture of a scene from
1384     a particular perspective.
1385     This program features adaptive sampling, crash
1386     recovery and progress reporting, all of which are important
1387     for time-consuming images.
1388     .PP
1389     A number of filters are available for manipulating picture files.
1390     .I Pfilt
1391     sets the exposure and performs anti-aliasing.
1392     .I Pcompos
1393     composites (cuts and pastes) pictures.
1394     .I Pcond
1395     conditions a picture for a specific display device.
1396     .I Pcomb
1397     performs arbitrary math on one or more pictures.
1398     .I Protate
1399     rotates a picture 90 degrees clockwise.
1400     .I Pflip
1401     flips a picture horizontally, vertically, or both (180 degree rotation).
1402     .I Pvalue
1403     converts a picture to and from simpler formats.
1404     .PP
1405     Pictures may be displayed directly under X11 using the program
1406     .I ximage,
1407     or converted a standard image format.
1408     .I Ra_avs
1409     converts to and from AVS image format.
1410     .I Ra_pict
1411     converts to Macintosh 32-bit PICT2 format.
1412     .I Ra_ppm
1413     converts to and from Poskanzer Portable Pixmap formats.
1414     .I Ra_pr
1415     converts to and from Sun 8-bit rasterfile format.
1416     .I Ra_pr24
1417     converts to and from Sun 24-bit rasterfile format.
1418     .I Ra_ps
1419     converts to PostScript color and greyscale formats.
1420     .I Ra_rgbe
1421     converts to and from Radiance uncompressed picture format.
1422     .I Ra_t16
1423     converts to and from Targa 16 and 24-bit image formats.
1424     .I Ra_t8
1425     converts to and from Targa 8-bit image format.
1426     .I Ra_tiff
1427     converts to and from TIFF.
1428     .I Ra_xyze
1429     converts to and from Radiance CIE picture format.
1430     .NH 1
1431     License
1432     .PP
1433 greg 1.4 .DS
1434     The Radiance Software License, Version 1.0
1435    
1436     Copyright (c) 1990 - 2002 The Regents of the University of California,
1437     through Lawrence Berkeley National Laboratory. All rights reserved.
1438    
1439     Redistribution and use in source and binary forms, with or without
1440     modification, are permitted provided that the following conditions
1441     are met:
1442    
1443     1. Redistributions of source code must retain the above copyright
1444     notice, this list of conditions and the following disclaimer.
1445    
1446     2. Redistributions in binary form must reproduce the above copyright
1447     notice, this list of conditions and the following disclaimer in
1448     the documentation and/or other materials provided with the
1449     distribution.
1450    
1451     3. The end-user documentation included with the redistribution,
1452     if any, must include the following acknowledgment:
1453     "This product includes Radiance software
1454     (http://radsite.lbl.gov/)
1455     developed by the Lawrence Berkeley National Laboratory
1456     (http://www.lbl.gov/)."
1457     Alternately, this acknowledgment may appear in the software itself,
1458     if and wherever such third-party acknowledgments normally appear.
1459    
1460     4. The names "Radiance," "Lawrence Berkeley National Laboratory"
1461     and "The Regents of the University of California" must
1462     not be used to endorse or promote products derived from this
1463     software without prior written permission. For written
1464     permission, please contact [email protected].
1465    
1466     5. Products derived from this software may not be called "Radiance",
1467     nor may "Radiance" appear in their name, without prior written
1468     permission of Lawrence Berkeley National Laboratory.
1469    
1470     THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
1471     WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
1472     OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
1473     DISCLAIMED. IN NO EVENT SHALL Lawrence Berkeley National Laboratory OR
1474     ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
1475     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
1476     LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
1477     USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
1478     ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
1479     OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
1480     OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
1481     SUCH DAMAGE.
1482     .DE
1483 greg 1.1 .NH 1
1484     Acknowledgements
1485     .PP
1486     This work was supported by the Assistant Secretary of Conservation
1487     and Renewable Energy, Office of Building Energy Research and
1488     Development, Buildings Equipment Division of the U.S. Department of
1489     Energy under Contract No. DE-AC03-76SF00098.
1490     .PP
1491     Additional work was sponsored by the Swiss federal government
1492     under the Swiss LUMEN Project and was
1493     carried out in the Laboratoire d'Energie Solaire (LESO Group) at
1494     the Ecole Polytechnique Federale de Lausanne (EPFL University)
1495     in Lausanne, Switzerland.
1496     .NH 1
1497     References
1498 greg 1.4 .LP
1499     Ward, G., Elena Eydelberg-Vileshin,
1500     ``Picture Perfect RGB Rendering Using Spectral Prefiltering and
1501     Sharp Color Primaries,''
1502     13th Eurographics Workshop on Rendering, P. Debevec and
1503     S. Gibson (Editors), June 2002.
1504     .LP
1505     Ward, G. and M. Simmons,
1506     ``The Holodeck Ray Cache: An Interactive Rendering System for Global
1507     Illumination in Nondiffuse Environments,''
1508     .I "ACM Transactions on Graphics,"
1509     18(4):361-98, October 1999.
1510     .LP
1511     Larson, G.W., H. Rushmeier, C. Piatko,
1512     ``A Visibility Matching Tone Reproduction Operator for High Dynamic
1513     Range Scenes,''
1514     .I "IEEE Transactions on Visualization and Computer Graphics",
1515     3(4), 291-306, December 1997.
1516     .LP
1517     Ward, G.,
1518     ``Making Global Illumination User Friendly,''
1519     .I "Sixth Eurographics Workshop on Rendering",
1520     proceedings to be published by Springer-Verlag,
1521     Dublin, Ireland, June 1995.
1522     .LP
1523     Rushmeier, H., G. Ward, C. Piatko, P. Sanders, B. Rust,
1524     ``Comparing Real and Synthetic Images: Some Ideas about Metrics,''
1525     .I "Sixth Eurographics Workshop on Rendering",
1526     proceedings to be published by Springer-Verlag,
1527     Dublin, Ireland, June 1995.
1528 greg 1.1 .LP
1529     Ward, G.,
1530     ``The Radiance Lighting Simulation and Rendering System,''
1531     .I "Computer Graphics",
1532     Orlando, July 1994.
1533     .LP
1534     Rushmeier, H., G. Ward,
1535     ``Energy-Preserving Non-Linear Filters,''
1536     .I "Computer Graphics",
1537     Orlando, July 1994.
1538     .LP
1539     Ward, G.,
1540     ``A Contrast-Based Scalefactor for Luminance Display,''
1541     .I "Graphics Gems IV",
1542     Edited by Paul Heckbert,
1543     Academic Press 1994.
1544     .LP
1545     Ward, G.,
1546     ``Measuring and Modeling Anisotropic Reflection,''
1547     .I "Computer Graphics",
1548     Chicago, July 1992.
1549     .LP
1550     Ward, G., P. Heckbert,
1551     ``Irradiance Gradients,''
1552     .I "Third Annual Eurographics Workshop on Rendering",
1553     to be published by Springer-Verlag, held in Bristol, UK, May 1992.
1554     .LP
1555     Ward, G.,
1556     ``Adaptive Shadow Testing for Ray Tracing,''
1557     .I "Second Annual Eurographics Workshop on Rendering",
1558     to be published by Springer-Verlag, held in Barcelona, SPAIN, May 1991.
1559     .LP
1560     Ward, G.,
1561     ``Visualization,''
1562     .I "Lighting Design and Application",
1563     Vol. 20, No. 6, June 1990.
1564     .LP
1565     Ward, G., F. Rubinstein, R. Clear,
1566     ``A Ray Tracing Solution for Diffuse Interreflection,''
1567     .I "Computer Graphics",
1568     Vol. 22, No. 4, August 1988.
1569     .LP
1570     Ward, G., F. Rubinstein,
1571     ``A New Technique for Computer Simulation of Illuminated Spaces,''
1572     .I "Journal of the Illuminating Engineering Society",
1573     Vol. 17, No. 1, Winter 1988.