1 |
<html> |
2 |
<!-- RCSid $Id: ray.html,v 1.37 2023/12/12 20:25:22 greg Exp $ --> |
3 |
<head> |
4 |
<title> |
5 |
The RADIANCE 6.0 Synthetic Imaging System |
6 |
</title> |
7 |
</head> |
8 |
<body> |
9 |
|
10 |
<p> |
11 |
|
12 |
<h1> |
13 |
The RADIANCE 6.0 Synthetic Imaging System |
14 |
</h1> |
15 |
|
16 |
<p> |
17 |
|
18 |
Building Technologies Program<br> |
19 |
Lawrence Berkeley National Laboratory<br> |
20 |
1 Cyclotron Rd., 90-3111<br> |
21 |
Berkeley, CA 94720<br> |
22 |
<a HREF="http://radsite.lbl.gov/radiance"</a> |
23 |
http://radsite.lbl.gov/radiance<br> |
24 |
|
25 |
<p> |
26 |
<hr> |
27 |
|
28 |
<h2> |
29 |
<a NAME="Overview">Overview</a> |
30 |
</h2> |
31 |
<ol> |
32 |
<li><a HREF="#Intro">Introduction</a><!P> |
33 |
<li><a HREF="#Scene">Scene Description</a><!P> |
34 |
<ol> |
35 |
<li><a HREF="#Primitive"> Primitive Types</a> |
36 |
<ol> |
37 |
<li><a HREF="#Surfaces">Surfaces</a> |
38 |
<li><a HREF="#Materials">Materials</a> |
39 |
<li><a HREF="#Textures">Textures</a> |
40 |
<li><a HREF="#Patterns">Patterns</a> |
41 |
<li><a HREF="#Mixtures">Mixtures</a> |
42 |
</ol><!P> |
43 |
<li><a HREF="#Auxiliary">Auxiliary Files</a> |
44 |
<ol> |
45 |
<li><a HREF="#Function">Function Files</a> |
46 |
<li><a HREF="#Data">Data Files</a> |
47 |
<li><a HREF="#Font">Font Files</a> |
48 |
</ol><!P> |
49 |
<li><a HREF="#Generators">Generators</a> |
50 |
</ol><!P> |
51 |
<li><a HREF="#Image">Image Generation</a><!P> |
52 |
<li><a HREF="#License">License</a><!P> |
53 |
<li><a HREF="#Ack">Acknowledgements</a><!P> |
54 |
<li><a HREF="#Ref">References</a><!P> |
55 |
<li><a HREF="#Index">Types Index</a><!P> |
56 |
</ol> |
57 |
|
58 |
<p> |
59 |
<hr> |
60 |
|
61 |
<h2> |
62 |
<a NAME="Intro">1. Introduction</a> |
63 |
</h2> |
64 |
|
65 |
RADIANCE was developed as a research tool for predicting |
66 |
the distribution of visible radiation in illuminated spaces. |
67 |
It takes as input a three-dimensional geometric model |
68 |
of the physical environment, and produces a map of |
69 |
spectral radiance values in a color image. |
70 |
The technique of ray-tracing follows light backwards |
71 |
from the image plane to the source(s). |
72 |
Because it can produce realistic images from a |
73 |
simple description, RADIANCE has a wide range of applications |
74 |
in graphic arts, lighting design, |
75 |
computer-aided engineering and architecture. |
76 |
|
77 |
<p> |
78 |
<img SRC="diagram1.gif"> |
79 |
<p> |
80 |
Figure 1 |
81 |
<p> |
82 |
The diagram in Figure 1 shows the flow between programs (boxes) and data |
83 |
(ovals). |
84 |
The central program is <i>rpict</i>, which produces a picture from a scene |
85 |
description. |
86 |
<i>Rvu</i> is a variation of rpict that computes and displays images |
87 |
interactively, and rtrace computes single ray values. |
88 |
Other programs (not shown) connect many of these elements together, |
89 |
such as the executive programs |
90 |
<i>rad</i> |
91 |
and |
92 |
<i>ranimate</i>, |
93 |
the interactive rendering program |
94 |
<i>rholo</i>, |
95 |
and the animation program |
96 |
<i>ranimove</i>. |
97 |
The program |
98 |
<i>obj2mesh</i> |
99 |
acts as both a converter and scene compiler, converting a Wavefront .OBJ |
100 |
file into a compiled mesh octree for efficient rendering. |
101 |
|
102 |
<p> |
103 |
A scene description file lists the surfaces and materials |
104 |
that make up a specific environment. |
105 |
The current surface types are spheres, polygons, cones, and cylinders. |
106 |
There is also a composite surface type, called mesh, and a pseudosurface |
107 |
type, called instance, which facilitates very complex geometries. |
108 |
Surfaces can be made from materials such as plastic, metal, and glass. |
109 |
Light sources can be distant disks as well as local spheres, disks |
110 |
and polygons. |
111 |
|
112 |
<p> |
113 |
From a three-dimensional scene description and a specified view, |
114 |
<i>rpict</i> produces a two-dimensional image. |
115 |
A picture file is a compressed binary representation of the |
116 |
pixels in the image. |
117 |
This picture can be scaled in size and brightness, |
118 |
anti-aliased, and sent to a graphics output device. |
119 |
|
120 |
<p> |
121 |
A header in each picture file lists the program(s) |
122 |
and parameters that produced it. |
123 |
This is useful for identifying a picture without having to display it. |
124 |
The information can be read by the program <i>getinfo</i>. |
125 |
|
126 |
<p> |
127 |
<hr> |
128 |
|
129 |
<h2> |
130 |
<a name="Scene">2. Scene Description</a> |
131 |
</h2> |
132 |
|
133 |
A scene description file represents a three-dimensional physical environment in Cartesian (rectilinear) world coordinates. |
134 |
It is stored as ASCII text, with the following basic format: |
135 |
|
136 |
<pre> |
137 |
# comment |
138 |
|
139 |
modifier type identifier |
140 |
n S1 S2 "S 3" .. Sn |
141 |
0 |
142 |
m R1 R2 R3 .. Rm |
143 |
|
144 |
modifier alias identifier reference |
145 |
|
146 |
! command |
147 |
|
148 |
... |
149 |
</pre> |
150 |
|
151 |
A comment line begins with a pound sign, `#'. |
152 |
|
153 |
<p> |
154 |
The <a NAME="scene_desc">scene description primitives</a> |
155 |
all have the same general format, and can be either surfaces or modifiers. |
156 |
A primitive has a modifier, a type, and an identifier. |
157 |
<p> |
158 |
A <a NAME="modifier"><b>modifier</b></a> is either the |
159 |
identifier of a previously defined primitive, or "void". |
160 |
<br> |
161 |
[ The most recent definition of a modifier is the |
162 |
one used, and later definitions do not cause relinking |
163 |
of loaded primitives. |
164 |
Thus, the same identifier may be used repeatedly, |
165 |
and each new definition will apply to the primitives following it. ] |
166 |
<p> |
167 |
An <a NAME="identifier"><b>identifier</b></a> can be any string |
168 |
(i.e., any sequence of non-white characters). |
169 |
<p> |
170 |
The arguments associated with a primitive can be strings or real numbers. |
171 |
<ul> |
172 |
<li> The first integer following the identifier is the number of <b>string arguments</b>, |
173 |
and it is followed by the arguments themselves (separated by white space or enclosed in quotes). |
174 |
<li> The next integer is the number of integer arguments, and is followed by the <b>integer arguments</b>. |
175 |
(There are currently no primitives that use them, however.) |
176 |
<li> The next integer is the real argument count, and it is followed by the <b>real arguments</b>. |
177 |
</ul> |
178 |
|
179 |
<p> |
180 |
An <a NAME="alias"><b>alias</b></a> gets its type and arguments from |
181 |
a previously defined primitive. |
182 |
This is useful when the same material is |
183 |
used with a different modifier, or as a convenient naming mechanism. |
184 |
The reserved modifier name "inherit" may be used to specificy that |
185 |
an alias will inherit its modifier from the original. |
186 |
Surfaces cannot be aliased. |
187 |
|
188 |
<p> |
189 |
A line beginning with an exclamation point, `!', |
190 |
is interpreted as a command. |
191 |
It is executed by the shell, and its output is read as input to the program. |
192 |
The command must not try to read from its standard input, or confusion |
193 |
will result. |
194 |
A command may be continued over multiple lines using a |
195 |
backslash, `\', to escape the newline. |
196 |
|
197 |
<p> |
198 |
White space is generally ignored, except as a separator. |
199 |
The exception is the newline character after a command or comment. |
200 |
Commands, comments and primitives may appear in any |
201 |
combination, so long as they are not intermingled. |
202 |
|
203 |
<p> |
204 |
<hr> |
205 |
|
206 |
<h3> |
207 |
<a NAME="Primitive">2.1. Primitive Types</a> |
208 |
</h3> |
209 |
|
210 |
Primitives can be <a HREF="#Surfaces">surfaces</a>, |
211 |
<a HREF="#Materials">materials</a>, |
212 |
<a HREF="#Textures">textures</a> or |
213 |
<a HREF="#Patterns">patterns</a>. |
214 |
Modifiers can be <a HREF="#Materials">materials</a>, |
215 |
<a HREF="#Mixtures">mixtures</a>, |
216 |
<a HREF="#Textures">textures</a> or <a HREF="#Patterns">patterns</a>. |
217 |
Simple surfaces must have one material in their modifier list. |
218 |
|
219 |
<p> |
220 |
<hr> |
221 |
|
222 |
<h4> |
223 |
<a NAME="Surfaces">2.1.1. Surfaces</a> |
224 |
</h4> |
225 |
<dl> |
226 |
|
227 |
A scene description will consist mostly of surfaces. |
228 |
The basic types are given below. |
229 |
|
230 |
<p> |
231 |
|
232 |
<dt> |
233 |
<a NAME="Source"> |
234 |
<b>Source </b> |
235 |
</a> |
236 |
<dd> |
237 |
A source is not really a surface, but a solid angle. |
238 |
It is used for specifying light sources that are very distant. |
239 |
The direction to the center of the source and the number of degrees subtended by its disk are given as follows: |
240 |
|
241 |
<pre> |
242 |
mod source id |
243 |
0 |
244 |
0 |
245 |
4 xdir ydir zdir angle |
246 |
</pre> |
247 |
|
248 |
<p> |
249 |
|
250 |
<dt> |
251 |
<a NAME="Sphere"> |
252 |
<b>Sphere</b> |
253 |
</a> |
254 |
<dd> |
255 |
A sphere is given by its center and radius: |
256 |
|
257 |
<pre> |
258 |
mod sphere id |
259 |
0 |
260 |
0 |
261 |
4 xcent ycent zcent radius |
262 |
</pre> |
263 |
|
264 |
<p> |
265 |
|
266 |
<dt> |
267 |
<a NAME="Bubble"> |
268 |
<b>Bubble</b> |
269 |
</a> |
270 |
|
271 |
<dd> |
272 |
A bubble is simply a sphere whose surface normal points inward. |
273 |
|
274 |
<p> |
275 |
|
276 |
<dt> |
277 |
<a NAME="Polygon"> |
278 |
<b>Polygon</b> |
279 |
</a> |
280 |
<dd> |
281 |
A polygon is given by a list of three-dimensional vertices, |
282 |
which are ordered counter-clockwise as viewed from the |
283 |
front side (into the surface normal). |
284 |
The last vertex is automatically connected to the first. |
285 |
Holes are represented in polygons as interior vertices |
286 |
connected to the outer perimeter by coincident edges (seams). |
287 |
|
288 |
<pre> |
289 |
mod polygon id |
290 |
0 |
291 |
0 |
292 |
3n |
293 |
x1 y1 z1 |
294 |
x2 y2 z2 |
295 |
... |
296 |
xn yn zn |
297 |
</pre> |
298 |
|
299 |
<p> |
300 |
|
301 |
<dt> |
302 |
<a NAME="Cone"> |
303 |
<b>Cone</b> |
304 |
</a> |
305 |
<dd> |
306 |
A cone is a megaphone-shaped object. |
307 |
It is truncated by two planes perpendicular to its axis, |
308 |
and one of its ends may come to a point. |
309 |
It is given as two axis endpoints, and the starting and ending radii: |
310 |
|
311 |
<pre> |
312 |
mod cone id |
313 |
0 |
314 |
0 |
315 |
8 |
316 |
x0 y0 z0 |
317 |
x1 y1 z1 |
318 |
r0 r1 |
319 |
</pre> |
320 |
|
321 |
<p> |
322 |
|
323 |
<dt> |
324 |
<a NAME="Cup"> |
325 |
<b>Cup</b> |
326 |
</a> |
327 |
<dd> |
328 |
A cup is an inverted <a HREF="#Cone">cone</a> (i.e., has an |
329 |
inward surface normal). |
330 |
|
331 |
<p> |
332 |
|
333 |
<dt> |
334 |
<a NAME="Cylinder"> |
335 |
<b>Cylinder</b> |
336 |
</a> |
337 |
<dd> |
338 |
A cylinder is like a <a HREF="#Cone">cone</a>, but its |
339 |
starting and ending radii are equal. |
340 |
|
341 |
<pre> |
342 |
mod cylinder id |
343 |
0 |
344 |
0 |
345 |
7 |
346 |
x0 y0 z0 |
347 |
x1 y1 z1 |
348 |
rad |
349 |
</pre> |
350 |
|
351 |
<p> |
352 |
|
353 |
<dt> |
354 |
<a NAME="Tube"> |
355 |
<b>Tube</b> |
356 |
</a> |
357 |
<dd> |
358 |
A tube is an inverted <a HREF="#Cylinder">cylinder</a>. |
359 |
|
360 |
<p> |
361 |
|
362 |
<dt> |
363 |
<a NAME="Ring"> |
364 |
<b>Ring</b> |
365 |
</a> |
366 |
<dd> |
367 |
A ring is a circular disk given by its center, |
368 |
surface normal, and inner and outer radii: |
369 |
|
370 |
<pre> |
371 |
mod ring id |
372 |
0 |
373 |
0 |
374 |
8 |
375 |
xcent ycent zcent |
376 |
xdir ydir zdir |
377 |
r0 r1 |
378 |
</pre> |
379 |
|
380 |
<p> |
381 |
|
382 |
<dt> |
383 |
<a NAME="Instance"> |
384 |
<b>Instance</b> |
385 |
</a> |
386 |
<dd> |
387 |
An instance is a compound surface, given |
388 |
by the contents of an octree file (created by oconv). |
389 |
|
390 |
<pre> |
391 |
mod instance id |
392 |
1+ octree transform |
393 |
0 |
394 |
0 |
395 |
</pre> |
396 |
|
397 |
If the modifier is "void", then surfaces will |
398 |
use the modifiers given in the original description. |
399 |
Otherwise, the modifier specified is used in their place. |
400 |
The transform moves the octree to the desired location in the scene. |
401 |
Multiple instances using the same octree take |
402 |
little extra memory, hence very complex |
403 |
descriptions can be rendered using this primitive. |
404 |
|
405 |
<p> |
406 |
There are a number of important limitations to be aware of |
407 |
when using instances. |
408 |
First, the scene description used to generate the octree must |
409 |
stand on its own, without referring to modifiers in the |
410 |
parent description. |
411 |
This is necessary for oconv to create the octree. |
412 |
Second, light sources in the octree will not be |
413 |
incorporated correctly in the calculation, |
414 |
and they are not recommended. |
415 |
Finally, there is no advantage (other than |
416 |
convenience) to using a single instance of an octree, |
417 |
or an octree containing only a few surfaces. |
418 |
An <a HREF="../man_html/xform.1.html">xform</a> command |
419 |
on the subordinate description is prefered in such cases. |
420 |
</dl> |
421 |
|
422 |
<p> |
423 |
|
424 |
<dt> |
425 |
<a NAME="Mesh"> |
426 |
<b>Mesh</b> |
427 |
</a> |
428 |
<dd> |
429 |
A mesh is a compound surface, made up of many triangles and |
430 |
an octree data structure to accelerate ray intersection. |
431 |
It is typically converted from a Wavefront .OBJ file using the |
432 |
<i>obj2mesh</i> program. |
433 |
|
434 |
<pre> |
435 |
mod mesh id |
436 |
1+ meshfile transform |
437 |
0 |
438 |
0 |
439 |
</pre> |
440 |
|
441 |
If the modifier is "void", then surfaces will |
442 |
use the modifiers given in the original mesh description. |
443 |
Otherwise, the modifier specified is used in their place. |
444 |
The transform moves the mesh to the desired location in the scene. |
445 |
Multiple instances using the same meshfile take little extra memory, |
446 |
and the compiled mesh itself takes much less space than individual |
447 |
polygons would. |
448 |
In the case of an unsmoothed mesh, using the mesh primitive reduces |
449 |
memory requirements by a factor of 30 relative to individual triangles. |
450 |
If a mesh has smoothed surfaces, we save a factor of 50 or more, |
451 |
permitting very detailed geometries that would otherwise exhaust the |
452 |
available memory. |
453 |
In addition, the mesh primitive can have associated (u,v) coordinates |
454 |
for pattern and texture mapping. |
455 |
These are made available to function files via the Lu and Lv variables. |
456 |
|
457 |
</dl> |
458 |
|
459 |
<p> |
460 |
<hr> |
461 |
|
462 |
<h4> |
463 |
<a NAME="Materials">2.1.2. Materials</a> |
464 |
</h4> |
465 |
|
466 |
A material defines the way light interacts with a surface. The basic types are given below. |
467 |
|
468 |
<p> |
469 |
|
470 |
<dl> |
471 |
|
472 |
<dt> |
473 |
<a NAME="Light"> |
474 |
<b>Light</b> |
475 |
</a> |
476 |
<dd> |
477 |
Light is the basic material for self-luminous surfaces (i.e., |
478 |
light sources). |
479 |
In addition to the <a HREF="#Source">source</a> surface type, |
480 |
<a HREF="#Sphere">spheres</a>, |
481 |
discs (<a HREF="#Ring">rings</a> with zero inner radius), |
482 |
<a HREF="#Cylinder">cylinders</a> (provided they are long enough), and <a HREF="#Polygon">polygons</a> can act as light sources. |
483 |
Polygons work best when they are rectangular. |
484 |
Cones cannot be used at this time. |
485 |
A pattern may be used to specify a light output distribution. |
486 |
Light is defined simply as a RGB radiance value (watts/steradian/m2): |
487 |
|
488 |
<pre> |
489 |
mod light id |
490 |
0 |
491 |
0 |
492 |
3 red green blue |
493 |
</pre> |
494 |
|
495 |
<p> |
496 |
|
497 |
<dt> |
498 |
<a NAME="Illum"> |
499 |
<b>Illum</b> |
500 |
</a> |
501 |
|
502 |
<dd> |
503 |
Illum is used for secondary light sources with broad distributions. |
504 |
A secondary light source is treated like any other light source, except when viewed directly. |
505 |
It then acts like it is made of a different material (indicated by |
506 |
the string argument), or becomes invisible (if no string argument is given, |
507 |
or the argument is "void"). |
508 |
Secondary sources are useful when modeling windows or brightly illuminated surfaces. |
509 |
|
510 |
<pre> |
511 |
mod illum id |
512 |
1 material |
513 |
0 |
514 |
3 red green blue |
515 |
</pre> |
516 |
|
517 |
<p> |
518 |
|
519 |
<dt> |
520 |
<a NAME="Glow"> |
521 |
<b>Glow</b> |
522 |
</a> |
523 |
|
524 |
<dd> |
525 |
Glow is used for surfaces that are self-luminous, but limited in their effect. |
526 |
In addition to the radiance value, a maximum radius for shadow testing is given: |
527 |
|
528 |
<pre> |
529 |
mod glow id |
530 |
0 |
531 |
0 |
532 |
4 red green blue maxrad |
533 |
</pre> |
534 |
|
535 |
If maxrad is zero, then the surface will never be tested for shadow, although it may participate in an interreflection calculation. |
536 |
If maxrad is negative, then the surface will never contribute to scene illumination. |
537 |
Glow sources will never illuminate objects on the other side of an illum surface. |
538 |
This provides a convenient way to illuminate local light fixture geometry without overlighting nearby objects. |
539 |
|
540 |
<p> |
541 |
|
542 |
<dt> |
543 |
<a NAME="Spotlight"> |
544 |
<b>Spotlight</b> |
545 |
</a> |
546 |
|
547 |
<dd> |
548 |
Spotlight is used for self-luminous surfaces having directed output. |
549 |
As well as radiance, the full cone angle (in degrees) and orientation (output direction) vector are given. |
550 |
The length of the orientation vector is the distance of the effective |
551 |
focus behind the source center (i.e., the focal length). |
552 |
|
553 |
<pre> |
554 |
mod spotlight id |
555 |
0 |
556 |
0 |
557 |
7 red green blue angle xdir ydir zdir |
558 |
</pre> |
559 |
|
560 |
<p> |
561 |
|
562 |
<dt> |
563 |
<a NAME="Mirror"> |
564 |
<b>Mirror</b> |
565 |
</a> |
566 |
|
567 |
<dd> |
568 |
Mirror is used for planar surfaces that produce virtual source reflections. |
569 |
This material should be used sparingly, as it may cause the light source calculation to blow up if it is applied to many small surfaces. |
570 |
This material is only supported for flat surfaces such as <a HREF="#Polygon">polygons</a> and <a HREF="#Ring">rings</a>. |
571 |
The arguments are simply the RGB reflectance values, which should be between 0 and 1. |
572 |
An optional string argument may be used like the illum type to specify a different material to be used for shading non-source rays. |
573 |
If this alternate material is given as "void", then the mirror surface will be invisible. |
574 |
This is only appropriate if the surface hides other (more detailed) geometry with the same overall reflectance. |
575 |
|
576 |
<pre> |
577 |
mod mirror id |
578 |
1 material |
579 |
0 |
580 |
3 red green blue |
581 |
</pre> |
582 |
|
583 |
<p> |
584 |
|
585 |
<dt> |
586 |
<a NAME="Prism1"> |
587 |
<b>Prism1</b> |
588 |
</a> |
589 |
|
590 |
<dd> |
591 |
The prism1 material is for general light redirection from prismatic glazings, generating virtual light sources. |
592 |
It can only be used to modify a planar surface |
593 |
(i.e., a <a HREF="#Polygon">polygon</a> or <a HREF="#Ring">disk</a>) |
594 |
and should not result in either light concentration or scattering. |
595 |
The new direction of the ray can be on either side of the material, |
596 |
and the definitions must have the correct bidirectional properties to work properly with virtual light sources. |
597 |
The arguments give the coefficient for the redirected light and its direction. |
598 |
|
599 |
<pre> |
600 |
mod prism1 id |
601 |
5+ coef dx dy dz funcfile transform |
602 |
0 |
603 |
n A1 A2 .. An |
604 |
</pre> |
605 |
|
606 |
The new direction variables dx, dy and dz need not produce a normalized vector. |
607 |
For convenience, the variables DxA, DyA and DzA are defined as the normalized direction to the target light source. |
608 |
See <a HREF="#Function">section 2.2.1</a> on function files for further information. |
609 |
|
610 |
<p> |
611 |
|
612 |
<dt> |
613 |
<a NAME="Prism2"> |
614 |
<b>Prism2</b> |
615 |
</a> |
616 |
|
617 |
<dd> |
618 |
The material prism2 is identical to <a HREF="#Prism1">prism1</a> except that it provides for two ray redirections rather than one. |
619 |
|
620 |
<pre> |
621 |
mod prism2 id |
622 |
9+ coef1 dx1 dy1 dz1 coef2 dx2 dy2 dz2 funcfile transform |
623 |
0 |
624 |
n A1 A2 .. An |
625 |
</pre> |
626 |
|
627 |
<p> |
628 |
|
629 |
<dt> |
630 |
<a NAME="Mist"> |
631 |
<b>Mist</b> |
632 |
</a> |
633 |
|
634 |
<dd> |
635 |
Mist is a virtual material used to delineate a volume |
636 |
of participating atmosphere. |
637 |
A list of important light sources may be given, along with an |
638 |
extinction coefficient, scattering albedo and scattering eccentricity |
639 |
parameter. |
640 |
The light sources named by the string argument list |
641 |
will be tested for scattering within the volume. |
642 |
Sources are identified by name, and virtual light sources may be indicated |
643 |
by giving the relaying object followed by '>' followed by the source, i.e: |
644 |
|
645 |
<pre> |
646 |
3 source1 mirror1>source10 mirror2>mirror1>source3 |
647 |
</pre> |
648 |
|
649 |
Normally, only one source is given per mist material, and there is an |
650 |
upper limit of 32 to the total number of active scattering sources. |
651 |
The extinction coefficient, if given, is added the the global |
652 |
coefficient set on the command line. |
653 |
Extinction is in units of 1/distance (distance based on the world coordinates), |
654 |
and indicates the proportional loss of radiance over one unit distance. |
655 |
The scattering albedo, if present, will override the global setting within |
656 |
the volume. |
657 |
An albedo of 0 0 0 means a perfectly absorbing medium, and an albedo of |
658 |
1 1 1 means |
659 |
a perfectly scattering medium (no absorption). |
660 |
The scattering eccentricity parameter will likewise override the global |
661 |
setting if it is present. |
662 |
Scattering eccentricity indicates how much scattered light favors the |
663 |
forward direction, as fit by the Henyey-Greenstein function: |
664 |
|
665 |
<pre> |
666 |
P(theta) = (1 - g*g) / (1 + g*g - 2*g*cos(theta))^1.5 |
667 |
</pre> |
668 |
|
669 |
A perfectly isotropic scattering medium has a g parameter of 0, and |
670 |
a highly directional material has a g parameter close to 1. |
671 |
Fits to the g parameter may be found along with typical extinction |
672 |
coefficients and scattering albedos for various atmospheres and |
673 |
cloud types in USGS meteorological tables. |
674 |
(A pattern will be applied to the extinction values.) |
675 |
|
676 |
<pre> |
677 |
mod mist id |
678 |
N src1 src2 .. srcN |
679 |
0 |
680 |
0|3|6|7 [ rext gext bext [ ralb galb balb [ g ] ] ] |
681 |
</pre> |
682 |
|
683 |
There are two usual uses of the mist type. |
684 |
One is to surround a beam from a spotlight or laser so that it is |
685 |
visible during rendering. |
686 |
For this application, it is important to use a <a HREF="#Cone">cone</a> |
687 |
(or <a HREF="#Cylinder">cylinder</a>) that |
688 |
is long enough and wide enough to contain the important visible portion. |
689 |
Light source photometry and intervening objects will have the desired |
690 |
effect, and crossing beams will result in additive scattering. |
691 |
For this application, it is best to leave off the real arguments, and |
692 |
use the global rendering parameters to control the atmosphere. |
693 |
The second application is to model clouds or other localized media. |
694 |
Complex boundary geometry may be used to give shape to a uniform medium, |
695 |
so long as the boundary encloses a proper volume. |
696 |
Alternatively, a pattern may be used to set the line integral value |
697 |
through the cloud for a ray entering or exiting a point in a given |
698 |
direction. |
699 |
For this application, it is best if cloud volumes do not overlap each other, |
700 |
and opaque objects contained within them may not be illuminated correctly |
701 |
unless the line integrals consider enclosed geometry. |
702 |
|
703 |
<dt> |
704 |
<a NAME="Plastic"> |
705 |
<b>Plastic</b> |
706 |
</a> |
707 |
|
708 |
<dd> |
709 |
Plastic is a material with uncolored highlights. |
710 |
It is given by its RGB reflectance, its fraction of specularity, and its roughness value. |
711 |
Roughness is specified as the rms slope of surface facets. |
712 |
A value of 0 corresponds to a perfectly smooth surface, and a value of 1 would be a very rough surface. |
713 |
Specularity fractions greater than 0.1 and roughness values greater than 0.2 are not very realistic. |
714 |
(A pattern modifying plastic will affect the material color.) |
715 |
|
716 |
<pre> |
717 |
mod plastic id |
718 |
0 |
719 |
0 |
720 |
5 red green blue spec rough |
721 |
</pre> |
722 |
|
723 |
<p> |
724 |
|
725 |
<dt> |
726 |
<a NAME="Metal"> |
727 |
<b>Metal</b> |
728 |
</a> |
729 |
|
730 |
<dd> |
731 |
Metal is similar to <a HREF="#Plastic">plastic</a>, but specular highlights are modified by the material color. |
732 |
Specularity of metals is usually .9 or greater. |
733 |
As for plastic, roughness values above .2 are uncommon. |
734 |
|
735 |
<p> |
736 |
|
737 |
<dt> |
738 |
<a NAME="Trans"> |
739 |
<b>Trans</b> |
740 |
</a> |
741 |
|
742 |
<dd> |
743 |
Trans is a translucent material, similar to <a HREF="#Plastic">plastic</a>. |
744 |
The transmissivity is the fraction of penetrating light that travels all the way through the material. |
745 |
The transmitted specular component is the fraction of transmitted light that is not diffusely scattered. |
746 |
Transmitted and diffusely reflected light is modified by the material color. |
747 |
Translucent objects are infinitely thin. |
748 |
|
749 |
<pre> |
750 |
mod trans id |
751 |
0 |
752 |
0 |
753 |
7 red green blue spec rough trans tspec |
754 |
</pre> |
755 |
|
756 |
<p> |
757 |
|
758 |
<dt> |
759 |
<a NAME="Plastic2"> |
760 |
<b>Plastic2</b> |
761 |
</a> |
762 |
|
763 |
<dd> |
764 |
Plastic2 is similar to <a HREF="#Plastic">plastic</a>, but with anisotropic roughness. |
765 |
This means that highlights in the surface will appear elliptical rather than round. |
766 |
The orientation of the anisotropy is determined by the unnormalized direction vector ux uy uz. |
767 |
These three expressions (separated by white space) are evaluated in the context of the function file funcfile. |
768 |
If no function file is required (i.e., no special variables or functions are required), a period (`.') may be given in its place. |
769 |
(See the discussion of <a HREF="#Function">Function Files</a> in the Auxiliary Files section). |
770 |
The urough value defines the roughness along the u vector given projected onto the surface. |
771 |
The vrough value defines the roughness perpendicular to this vector. |
772 |
Note that the highlight will be narrower in the direction of the smaller roughness value. |
773 |
Roughness values of zero are not allowed for efficiency reasons since the behavior would be the same as regular plastic in that case. |
774 |
|
775 |
<pre> |
776 |
mod plastic2 id |
777 |
4+ ux uy uz funcfile transform |
778 |
0 |
779 |
6 red green blue spec urough vrough |
780 |
</pre> |
781 |
|
782 |
<p> |
783 |
|
784 |
<dt> |
785 |
<a NAME="Metal2"> |
786 |
<b>Metal2</b> |
787 |
</a> |
788 |
|
789 |
<dd> |
790 |
Metal2 is the same as <a HREF="#Plastic2">plastic2</a>, except that the highlights are modified by the material color. |
791 |
|
792 |
<p> |
793 |
|
794 |
<dt> |
795 |
<a NAME="Trans2"> |
796 |
<b>Trans2</b> |
797 |
</a> |
798 |
|
799 |
<dd> |
800 |
Trans2 is the anisotropic version of <a HREF="#Trans">trans</a>. |
801 |
The string arguments are the same as for <a HREF="#Plastic2">plastic2</a>, |
802 |
and the real arguments are the same as for trans but with an additional roughness value. |
803 |
|
804 |
<pre> |
805 |
mod trans2 id |
806 |
4+ ux uy uz funcfile transform |
807 |
0 |
808 |
8 red green blue spec urough vrough trans tspec |
809 |
</pre> |
810 |
|
811 |
<p> |
812 |
|
813 |
<dt> |
814 |
<a NAME="Ashik2"> |
815 |
<b>Ashik2</b> |
816 |
</a> |
817 |
|
818 |
<dd> |
819 |
Ashik2 is the anisotropic reflectance model by Ashikhmin & Shirley. |
820 |
The string arguments are the same as for <a HREF="#Plastic2">plastic2</a>, but the real |
821 |
arguments have additional flexibility to specify the specular color. |
822 |
Also, rather than roughness, specular power is used, which has no |
823 |
physical meaning other than larger numbers are equivalent to a smoother |
824 |
surface. |
825 |
Unlike other material types, total reflectance is the sum of |
826 |
diffuse and specular colors, and should be adjusted accordingly. |
827 |
<pre> |
828 |
mod ashik2 id |
829 |
4+ ux uy uz funcfile transform |
830 |
0 |
831 |
8 dred dgrn dblu sred sgrn sblu u-power v-power |
832 |
</pre> |
833 |
|
834 |
<p> |
835 |
|
836 |
<dt> |
837 |
<a NAME="Dielectric"> |
838 |
<b>Dielectric</b> |
839 |
</a> |
840 |
|
841 |
<dd> |
842 |
A dielectric material is transparent, and it refracts light as well as reflecting it. |
843 |
Its behavior is determined by the index of refraction and transmission coefficient in each wavelength band per unit length. |
844 |
Common glass has a index of refraction (n) around 1.5, and a transmission coefficient of roughly 0.92 over an inch. |
845 |
An additional number, the Hartmann constant, describes how the index of refraction changes as a function of wavelength. |
846 |
It is usually zero. (A <a HREF="#Patterns">pattern</a> modifies only the refracted value.) |
847 |
|
848 |
<pre> |
849 |
mod dielectric id |
850 |
0 |
851 |
0 |
852 |
5 rtn gtn btn n hc |
853 |
</pre> |
854 |
|
855 |
<p> |
856 |
|
857 |
<dt> |
858 |
<a NAME="Interface"> |
859 |
<b>Interface</b> |
860 |
</a> |
861 |
|
862 |
<dd> |
863 |
An interface is a boundary between two dielectrics. |
864 |
The first transmission coefficient and refractive index are for the inside; the second ones are for the outside. |
865 |
Ordinary dielectrics are surrounded by a vacuum (1 1 1 1). |
866 |
|
867 |
<pre> |
868 |
mod interface id |
869 |
0 |
870 |
0 |
871 |
8 rtn1 gtn1 btn1 n1 rtn2 gtn2 btn2 n2 |
872 |
</pre> |
873 |
|
874 |
<p> |
875 |
|
876 |
<dt> |
877 |
<a NAME="Glass"> |
878 |
<b>Glass</b> |
879 |
</a> |
880 |
|
881 |
<dd> |
882 |
Glass is similar to <a HREF="#Dielectric">dielectric</a>, but it is optimized for thin glass surfaces (n = 1.52). |
883 |
One transmitted ray and one reflected ray is produced. |
884 |
By using a single surface is in place of two, internal reflections are avoided. |
885 |
The surface orientation is irrelevant, as it is for <a HREF="#Plastic">plastic</a>, <a HREF="#Metal">metal</a>, and <a HREF="#Trans">trans</a>. |
886 |
The only specification required is the transmissivity at normal incidence. |
887 |
(Transmissivity is the amount of light not absorbed in one traversal |
888 |
of the material. |
889 |
Transmittance -- the value usually measured -- is the total light |
890 |
transmitted through the pane including multiple reflections.) |
891 |
To compute transmissivity (tn) from transmittance (Tn) use: |
892 |
|
893 |
<pre> |
894 |
tn = (sqrt(.8402528435+.0072522239*Tn*Tn)-.9166530661)/.0036261119/Tn |
895 |
</pre> |
896 |
|
897 |
Standard 88% transmittance glass has a transmissivity of 0.96. |
898 |
(A <a HREF="#Patterns">pattern</a> modifying glass will affect the transmissivity.) |
899 |
If a fourth real argument is given, it is interpreted as the index of refraction to use instead of 1.52. |
900 |
|
901 |
<pre> |
902 |
mod glass id |
903 |
0 |
904 |
0 |
905 |
3 rtn gtn btn |
906 |
</pre> |
907 |
|
908 |
<p> |
909 |
|
910 |
<dt> |
911 |
<a NAME="Plasfunc"> |
912 |
<b>Plasfunc</b> |
913 |
</a> |
914 |
|
915 |
<dd> |
916 |
Plasfunc in used for the procedural definition of plastic-like materials |
917 |
with arbitrary bidirectional reflectance distribution functions (BRDF's). |
918 |
The arguments to this material include the color and specularity, |
919 |
as well as the function defining the specular distribution and the auxiliary file where it may be found. |
920 |
|
921 |
<pre> |
922 |
mod plasfunc id |
923 |
2+ refl funcfile transform |
924 |
0 |
925 |
4+ red green blue spec A5 .. |
926 |
</pre> |
927 |
|
928 |
The function refl takes four arguments, the x, y and z |
929 |
direction towards the incident light, and the solid angle |
930 |
subtended by the source. |
931 |
The solid angle is provided to facilitate averaging, and is usually |
932 |
ignored. |
933 |
The refl function should integrate to 1 over |
934 |
the projected hemisphere to maintain energy balance. |
935 |
At least four real arguments must be given, and these are made available along with any additional values to the reflectance function. |
936 |
Currently, only the contribution from direct light sources is considered in the specular calculation. |
937 |
As in most material types, the surface normal is always altered to face the incoming ray. |
938 |
|
939 |
<p> |
940 |
|
941 |
<dt> |
942 |
<a NAME="Metfunc"> |
943 |
<b>Metfunc</b> |
944 |
</a> |
945 |
|
946 |
<dd> |
947 |
Metfunc is identical to <a HREF="#Plasfunc">plasfunc</a> and takes the same arguments, |
948 |
but the specular component is multiplied also by the material color. |
949 |
|
950 |
<p> |
951 |
|
952 |
<dt> |
953 |
<a NAME="Transfunc"> |
954 |
<b>Transfunc</b> |
955 |
</a> |
956 |
|
957 |
<dd> |
958 |
Transfunc is similar to <a HREF="#Plasfunc">plasfunc</a> but with an arbitrary bidirectional transmittance distribution |
959 |
as well as a reflectance distribution. |
960 |
Both reflectance and transmittance are specified with the same function. |
961 |
|
962 |
<pre> |
963 |
mod transfunc id |
964 |
2+ brtd funcfile transform |
965 |
0 |
966 |
6+ red green blue rspec trans tspec A7 .. |
967 |
</pre> |
968 |
|
969 |
Where trans is the total light transmitted and tspec is the non-Lambertian fraction of transmitted light. |
970 |
The function brtd should integrate to 1 over each projected hemisphere. |
971 |
|
972 |
<p> |
973 |
|
974 |
<dt> |
975 |
<a NAME="BRTDfunc"> |
976 |
<b>BRTDfunc</b> |
977 |
</a> |
978 |
|
979 |
<dd> |
980 |
The material BRTDfunc gives the maximum flexibility over surface reflectance and transmittance, |
981 |
providing for spectrally-dependent specular rays and reflectance and transmittance distribution functions. |
982 |
|
983 |
<pre> |
984 |
mod BRTDfunc id |
985 |
10+ rrefl grefl brefl |
986 |
rtrns gtrns btrns |
987 |
rbrtd gbrtd bbrtd |
988 |
funcfile transform |
989 |
0 |
990 |
9+ rfdif gfdif bfdif |
991 |
rbdif gbdif bbdif |
992 |
rtdif gtdif btdif |
993 |
A10 .. |
994 |
</pre> |
995 |
|
996 |
The variables rrefl, grefl and brefl specify the color coefficients for the ideal specular (mirror) reflection of the surface. |
997 |
The variables rtrns, gtrns and btrns specify the color coefficients for the ideal specular transmission. |
998 |
The functions rbrtd, gbrtd and bbrtd take the direction to the incident light (and its solid angle) and |
999 |
compute the color coefficients for the directional diffuse part of reflection and transmission. |
1000 |
As a special case, three identical values of '0' may be given in place of these function names to indicate no directional diffuse component. |
1001 |
|
1002 |
<p> |
1003 |
Unlike most other material types, the surface normal is not altered to face the incoming ray. |
1004 |
Thus, functions and variables must pay attention to the orientation of the surface and make adjustments appropriately. |
1005 |
However, the special variables for the perturbed dot product and surface normal, RdotP, NxP, NyP and NzP are reoriented |
1006 |
as if the ray hit the front surface for convenience. |
1007 |
|
1008 |
<p> |
1009 |
A diffuse reflection component may be given for the front side with rfdif, gfdif and bfdif for the front side of the surface |
1010 |
or rbdif, gbdif and bbdif for the back side. |
1011 |
The diffuse transmittance (must be the same for both sides by physical law) is given by rtdif, gtdif and btdif. |
1012 |
A pattern will modify these diffuse scattering values, and will be available through the special variables CrP, CgP and CbP. |
1013 |
|
1014 |
<p> |
1015 |
Care must be taken when using this material type to produce a physically valid reflection model. |
1016 |
The reflectance functions should be bidirectional, and under no circumstances should the sum of reflected diffuse, |
1017 |
transmitted diffuse, reflected specular, transmitted specular and the integrated directional diffuse component be greater than one. |
1018 |
|
1019 |
<p> |
1020 |
|
1021 |
<dt> |
1022 |
<a NAME="Plasdata"> |
1023 |
<b>Plasdata</b> |
1024 |
</a> |
1025 |
|
1026 |
<dd> |
1027 |
Plasdata is used for arbitrary BRDF's that are most conveniently given as interpolated data. |
1028 |
The arguments to this material are the <a HREF="#Data">data file</a> and coordinate index functions, |
1029 |
as well as a function to optionally modify the data values. |
1030 |
|
1031 |
<pre> |
1032 |
mod plasdata id |
1033 |
3+n+ |
1034 |
func datafile |
1035 |
funcfile x1 x2 .. xn transform |
1036 |
0 |
1037 |
4+ red green blue spec A5 .. |
1038 |
</pre> |
1039 |
|
1040 |
The coordinate indices (x1, x2, etc.) are themselves functions of the x, y and z direction to the incident light, plus the solid angle |
1041 |
subtended by the light source (usually ignored). |
1042 |
The data function (func) takes five variables, the |
1043 |
interpolated value from the n-dimensional data file, followed by the |
1044 |
x, y and z direction to the incident light and the solid angle of the source. |
1045 |
The light source direction and size may of course be ignored by the function. |
1046 |
|
1047 |
<p> |
1048 |
|
1049 |
<dt> |
1050 |
<a NAME="Metdata"> |
1051 |
<b>Metdata</b> |
1052 |
</a> |
1053 |
|
1054 |
<dd> |
1055 |
As metfunc is to plasfunc, metdata is to <a HREF="#Plasdata">plasdata</a>. |
1056 |
Metdata takes the same arguments as plasdata, but the specular component is modified by the given material color. |
1057 |
|
1058 |
<p> |
1059 |
|
1060 |
<dt> |
1061 |
<a NAME="Transdata"> |
1062 |
<b>Transdata</b> |
1063 |
</a> |
1064 |
|
1065 |
<dd> |
1066 |
Transdata is like <a HREF="#Plasdata">plasdata</a> but the specification includes transmittance as well as reflectance. |
1067 |
The parameters are as follows. |
1068 |
|
1069 |
<pre> |
1070 |
mod transdata id |
1071 |
3+n+ |
1072 |
func datafile |
1073 |
funcfile x1 x2 .. xn transform |
1074 |
0 |
1075 |
6+ red green blue rspec trans tspec A7 .. |
1076 |
</pre> |
1077 |
|
1078 |
<p> |
1079 |
|
1080 |
<dt> |
1081 |
<a NAME="BSDF"> |
1082 |
<b>BSDF</b> |
1083 |
</a> |
1084 |
|
1085 |
<dd> |
1086 |
The BSDF material type loads an XML (eXtensible Markup Language) |
1087 |
file describing a bidirectional scattering distribution function. |
1088 |
Real arguments to this material may define additional |
1089 |
diffuse components that augment the BSDF data. |
1090 |
String arguments are used to define thickness for proxied |
1091 |
surfaces and the "up" orientation for the material. |
1092 |
|
1093 |
<pre> |
1094 |
mod BSDF id |
1095 |
6+ thick BSDFfile ux uy uz funcfile transform |
1096 |
0 |
1097 |
0|3|6|9 |
1098 |
rfdif gfdif bfdif |
1099 |
rbdif gbdif bbdif |
1100 |
rtdif gtdif btdif |
1101 |
</pre> |
1102 |
|
1103 |
<p> |
1104 |
The first string argument is a "thickness" parameter that may be used |
1105 |
to hide detail geometry being proxied by an aggregate BSDF material. |
1106 |
If a view or shadow ray hits a BSDF proxy with non-zero thickness, |
1107 |
it will pass directly through as if the surface were not there. |
1108 |
Similar to the illum type, this permits direct viewing and |
1109 |
shadow testing of complex geometry. |
1110 |
The BSDF is used when a scattered (indirect) ray hits the surface, |
1111 |
and any transmitted sample rays will be offset by the thickness amount |
1112 |
to avoid the hidden geometry and gather samples from the other side. |
1113 |
In this manner, BSDF surfaces can improve the results for indirect |
1114 |
scattering from complex systems without sacrificing appearance or |
1115 |
shadow accuracy. |
1116 |
If the BSDF has transmission and back-side reflection data, |
1117 |
a parallel BSDF surface may be |
1118 |
placed slightly less than the given thickness away from the front surface |
1119 |
to enclose the complex geometry on both sides. |
1120 |
The sign of the thickness is important, as it indicates |
1121 |
whether the proxied geometry is behind the BSDF |
1122 |
surface (when thickness is positive) or in front (when |
1123 |
thickness is negative). |
1124 |
<p> |
1125 |
The second string argument is the name of the BSDF file, |
1126 |
which is found in the usual auxiliary locations. The |
1127 |
following three string parameters name variables for an |
1128 |
"up" vector, which together with the surface |
1129 |
normal, define the local coordinate system that orients the |
1130 |
BSDF. These variables, along with the thickness, are defined |
1131 |
in a function file given as the next string argument. An |
1132 |
optional transform is used to scale the thickness and |
1133 |
reorient the up vector. |
1134 |
<p> |
1135 |
If no real arguments are given, the BSDF is used by itself |
1136 |
to determine reflection and transmission. If there are at |
1137 |
least 3 real arguments, the first triplet is an additional |
1138 |
diffuse reflectance for the front side. At least 6 real |
1139 |
arguments adds diffuse reflectance to the rear side of the |
1140 |
surface. If there are 9 real arguments, the final triplet |
1141 |
will be taken as an additional diffuse transmittance. All |
1142 |
diffuse components as well as the non-diffuse transmission |
1143 |
are modified by patterns applied to this material. The |
1144 |
non-diffuse reflection from either side are unaffected. |
1145 |
Textures perturb the effective surface normal in the usual |
1146 |
way. |
1147 |
<p> |
1148 |
The surface normal of this type is not altered to face the |
1149 |
incoming ray, so the front and back BSDF reflections may |
1150 |
differ. (Transmission is identical front-to-back by physical |
1151 |
law.) If back visibility is turned off during rendering and |
1152 |
there is no transmission or back-side reflection, only then |
1153 |
the surface will be invisible from behind. Unlike other |
1154 |
data-driven material types, the BSDF type is fully supported |
1155 |
and all parts of the distribution are properly sampled. |
1156 |
<p> |
1157 |
|
1158 |
<dt> |
1159 |
<a NAME="aBSDF"> |
1160 |
<b>aBSDF</b> |
1161 |
</a> |
1162 |
|
1163 |
<dd> |
1164 |
The aBSDF material is identical to the BSDF type with two |
1165 |
important differences. First, proxy geometry is not |
1166 |
supported, so there is no thickness parameter. Second, an |
1167 |
aBSDF is assumed to have some specular through component |
1168 |
(the ’a’ stands for "aperture"), |
1169 |
which is treated specially during the direct calculation |
1170 |
and when viewing the material. Based on the BSDF data, the |
1171 |
coefficient of specular transmission is determined and used |
1172 |
for modifying unscattered shadow and view rays. |
1173 |
|
1174 |
<pre> |
1175 |
mod aBSDF id |
1176 |
5+ BSDFfile ux uy uz funcfile transform |
1177 |
0 |
1178 |
0|3|6|9 |
1179 |
rfdif gfdif bfdif |
1180 |
rbdif gbdif bbdif |
1181 |
rtdif gtdif btdif |
1182 |
</pre> |
1183 |
|
1184 |
<p> |
1185 |
If a material has no specular transmitted component, it is |
1186 |
much better to use the BSDF type with a zero thickness |
1187 |
than to use aBSDF. |
1188 |
<p> |
1189 |
|
1190 |
<dt> |
1191 |
<a NAME="Antimatter"> |
1192 |
<b>Antimatter</b> |
1193 |
</a> |
1194 |
|
1195 |
<dd> |
1196 |
Antimatter is a material that can "subtract" volumes from other volumes. |
1197 |
A ray passing into an antimatter object becomes blind to all the specified modifiers: |
1198 |
|
1199 |
<pre> |
1200 |
mod antimatter id |
1201 |
N mod1 mod2 .. modN |
1202 |
0 |
1203 |
0 |
1204 |
</pre> |
1205 |
|
1206 |
The first modifier will also be used to shade the area leaving the antimatter volume and entering the regular volume. |
1207 |
If mod1 is void, the antimatter volume is completely invisible. |
1208 |
Antimatter does not work properly with the material type <a HREF="#Trans">"trans"</a>, |
1209 |
and multiple antimatter surfaces should be disjoint. |
1210 |
The viewpoint must be outside all volumes concerned for a correct rendering. |
1211 |
|
1212 |
</dl> |
1213 |
|
1214 |
<p> |
1215 |
<hr> |
1216 |
|
1217 |
<h4> |
1218 |
<a NAME="Textures">2.1.3. Textures</a> |
1219 |
</h4> |
1220 |
|
1221 |
A texture is a perturbation of the surface normal, and is given by either a function or data. |
1222 |
|
1223 |
<p> |
1224 |
|
1225 |
<dl> |
1226 |
|
1227 |
<dt> |
1228 |
<a NAME="Texfunc"> |
1229 |
<b>Texfunc</b> |
1230 |
</a> |
1231 |
|
1232 |
<dd> |
1233 |
A texfunc uses an auxiliary function file to specify a procedural texture: |
1234 |
|
1235 |
<pre> |
1236 |
mod texfunc id |
1237 |
4+ xpert ypert zpert funcfile transform |
1238 |
0 |
1239 |
n A1 A2 .. An |
1240 |
</pre> |
1241 |
|
1242 |
<p> |
1243 |
|
1244 |
<dt> |
1245 |
<a NAME="Texdata"> |
1246 |
<b>Texdata</b> |
1247 |
</a> |
1248 |
|
1249 |
<dd> |
1250 |
A texdata texture uses three data files to get the surface normal perturbations. |
1251 |
The variables xfunc, yfunc and zfunc take three arguments each from the interpolated values in xdfname, ydfname and zdfname. |
1252 |
|
1253 |
<pre> |
1254 |
mod texdata id |
1255 |
8+ xfunc yfunc zfunc xdfname ydfname zdfname vfname x0 x1 .. xf |
1256 |
0 |
1257 |
n A1 A2 .. An |
1258 |
</pre> |
1259 |
|
1260 |
</dl> |
1261 |
|
1262 |
<p> |
1263 |
<hr> |
1264 |
|
1265 |
<h4> |
1266 |
<a NAME="Patterns">2.1.4. Patterns</a> |
1267 |
</h4> |
1268 |
|
1269 |
Patterns are used to modify the reflectance of materials. The basic types are given below. |
1270 |
|
1271 |
<p> |
1272 |
|
1273 |
<dl> |
1274 |
|
1275 |
<dt> |
1276 |
<a NAME="Colorfunc"> |
1277 |
<b>Colorfunc</b> |
1278 |
</a> |
1279 |
|
1280 |
<dd> |
1281 |
A colorfunc is a procedurally defined color pattern. It is specified as follows: |
1282 |
|
1283 |
<pre> |
1284 |
mod colorfunc id |
1285 |
4+ red green blue funcfile transform |
1286 |
0 |
1287 |
n A1 A2 .. An |
1288 |
</pre> |
1289 |
|
1290 |
<p> |
1291 |
|
1292 |
<dt> |
1293 |
<a NAME="Brightfunc"> |
1294 |
<b>Brightfunc</b> |
1295 |
</a> |
1296 |
|
1297 |
<dd> |
1298 |
A brightfunc is the same as a colorfunc, except it is monochromatic. |
1299 |
|
1300 |
<pre> |
1301 |
mod brightfunc id |
1302 |
2+ refl funcfile transform |
1303 |
0 |
1304 |
n A1 A2 .. An |
1305 |
</pre> |
1306 |
|
1307 |
<p> |
1308 |
|
1309 |
<dt> |
1310 |
<a NAME="Colordata"> |
1311 |
<b>Colordata</b> |
1312 |
</a> |
1313 |
|
1314 |
<dd> |
1315 |
Colordata uses an interpolated data map to modify a material's color. |
1316 |
The map is n-dimensional, and is stored in three auxiliary files, one for each color. |
1317 |
The coordinates used to look up and interpolate the data are defined in another auxiliary file. |
1318 |
The interpolated data values are modified by functions of one or three variables. |
1319 |
If the functions are of one variable, then they are passed the corresponding color component (red or green or blue). |
1320 |
If the functions are of three variables, then they are passed the original red, green, and blue values as parameters. |
1321 |
|
1322 |
<pre> |
1323 |
mod colordata id |
1324 |
7+n+ |
1325 |
rfunc gfunc bfunc rdatafile gdatafile bdatafile |
1326 |
funcfile x1 x2 .. xn transform |
1327 |
0 |
1328 |
m A1 A2 .. Am |
1329 |
</pre> |
1330 |
|
1331 |
<p> |
1332 |
|
1333 |
<dt> |
1334 |
<a NAME="Brightdata"> |
1335 |
<b>Brightdata</b> |
1336 |
</a> |
1337 |
|
1338 |
<dd> |
1339 |
Brightdata is like colordata, except monochromatic. |
1340 |
|
1341 |
<pre> |
1342 |
mod brightdata id |
1343 |
3+n+ |
1344 |
func datafile |
1345 |
funcfile x1 x2 .. xn transform |
1346 |
0 |
1347 |
m A1 A2 .. Am |
1348 |
</pre> |
1349 |
|
1350 |
<p> |
1351 |
|
1352 |
<dt> |
1353 |
<a NAME="Colorpict"> |
1354 |
<b>Colorpict</b> |
1355 |
</a> |
1356 |
|
1357 |
<dd> |
1358 |
Colorpict is a special case of colordata, where the pattern is a two-dimensional image stored in the RADIANCE picture format. |
1359 |
The dimensions of the image data are determined by the picture such that the smaller dimension is always 1, |
1360 |
and the other is the ratio between the larger and the smaller. |
1361 |
For example, a 500x338 picture would have coordinates (u,v) in the rectangle between (0,0) and (1.48,1). |
1362 |
|
1363 |
<pre> |
1364 |
mod colorpict id |
1365 |
7+ |
1366 |
rfunc gfunc bfunc pictfile |
1367 |
funcfile u v transform |
1368 |
0 |
1369 |
m A1 A2 .. Am |
1370 |
</pre> |
1371 |
|
1372 |
<p> |
1373 |
|
1374 |
<dt> |
1375 |
<a NAME="Colortext"> |
1376 |
<b>Colortext</b> |
1377 |
</a> |
1378 |
|
1379 |
<dd> |
1380 |
Colortext is dichromatic writing in a polygonal font. |
1381 |
The font is defined in an auxiliary file, such as helvet.fnt. |
1382 |
The text itself is also specified in a separate file, or can be part of the material arguments. |
1383 |
The character size, orientation, aspect ratio and slant is determined by right and down motion vectors. |
1384 |
The upper left origin for the text block as well as the foreground and background colors must also be given. |
1385 |
|
1386 |
<pre> |
1387 |
mod colortext id |
1388 |
2 fontfile textfile |
1389 |
0 |
1390 |
15+ |
1391 |
Ox Oy Oz |
1392 |
Rx Ry Rz |
1393 |
Dx Dy Dz |
1394 |
rfore gfore bfore |
1395 |
rback gback bback |
1396 |
[spacing] |
1397 |
</pre> |
1398 |
|
1399 |
or: |
1400 |
|
1401 |
<pre> |
1402 |
mod colortext id |
1403 |
2+N fontfile . This is a line with N words ... |
1404 |
0 |
1405 |
15+ |
1406 |
Ox Oy Oz |
1407 |
Rx Ry Rz |
1408 |
Dx Dy Dz |
1409 |
rfore gfore bfore |
1410 |
rback gback bback |
1411 |
[spacing] |
1412 |
</pre> |
1413 |
|
1414 |
<p> |
1415 |
|
1416 |
<dt> |
1417 |
<a NAME="Brighttext"> |
1418 |
<b>Brighttext</b> |
1419 |
</a> |
1420 |
|
1421 |
<dd> |
1422 |
Brighttext is like colortext, but the writing is monochromatic. |
1423 |
|
1424 |
<pre> |
1425 |
mod brighttext id |
1426 |
2 fontfile textfile |
1427 |
0 |
1428 |
11+ |
1429 |
Ox Oy Oz |
1430 |
Rx Ry Rz |
1431 |
Dx Dy Dz |
1432 |
foreground background |
1433 |
[spacing] |
1434 |
</pre> |
1435 |
|
1436 |
or: |
1437 |
|
1438 |
<pre> |
1439 |
mod brighttext id |
1440 |
2+N fontfile . This is a line with N words ... |
1441 |
0 |
1442 |
11+ |
1443 |
Ox Oy Oz |
1444 |
Rx Ry Rz |
1445 |
Dx Dy Dz |
1446 |
foreground background |
1447 |
[spacing] |
1448 |
</pre> |
1449 |
|
1450 |
<p> |
1451 |
|
1452 |
By default, a uniform spacing algorithm is used that guarantees every character will appear in a precisely determined position. |
1453 |
Unfortunately, such a scheme results in rather unattractive and difficult to read text with most fonts. |
1454 |
The optional spacing value defines the distance between characters for proportional spacing. |
1455 |
A positive value selects a spacing algorithm that preserves right margins and indentation, |
1456 |
but does not provide the ultimate in proportionally spaced text. |
1457 |
A negative value insures that characters are properly spaced, but the placement of words then varies unpredictably. |
1458 |
The choice depends on the relative importance of spacing versus formatting. |
1459 |
When presenting a section of formatted text, a positive spacing value is usually preferred. |
1460 |
A single line of text will often be accompanied by a negative spacing value. |
1461 |
A section of text meant to depict a picture, perhaps using a special purpose font such as hexbit4x1.fnt, calls for uniform spacing. |
1462 |
Reasonable magnitudes for proportional spacing are between 0.1 (for tightly spaced characters) and 0.3 (for wide spacing). |
1463 |
|
1464 |
<p> |
1465 |
|
1466 |
<dt> |
1467 |
<a NAME="Spectrum"> |
1468 |
<b>Spectrum</b> |
1469 |
</a> |
1470 |
|
1471 |
<dd> |
1472 |
The spectrum primitive is the most basic type for introducing spectral |
1473 |
color to a material. |
1474 |
Since materials only provide RGB parameters, spectral patterns |
1475 |
are the only way to superimpose wavelength-dependent behavior. |
1476 |
|
1477 |
<pre> |
1478 |
mod spectrum id |
1479 |
0 |
1480 |
0 |
1481 |
5+ nmA nmB s1 s2 .. sN |
1482 |
</pre> |
1483 |
|
1484 |
<p> |
1485 |
The first two real arguments indicate the extrema of the |
1486 |
spectral range in nanometers. |
1487 |
Subsequent real values correspond to multipliers at each wavelength. |
1488 |
The nmA wavelength may be greater or less than nmB, |
1489 |
but they may not be equal, and their ordering matches |
1490 |
the order of the spectral values. |
1491 |
A minimum of 3 values must be given, which would act |
1492 |
more or less the same as a constant RGB multiplier. |
1493 |
As with RGB values, spectral quantities normally range between 0 |
1494 |
and 1 at each wavelength, or average to 1.0 against a standard |
1495 |
sensitivity functions such as V(lambda). |
1496 |
The best results obtain when the spectral range and number |
1497 |
of samples match rendering options, though resampling will handle |
1498 |
any differences, zero-filling wavelenths outside the nmA to nmB |
1499 |
range. |
1500 |
A warning will be issued if the given wavelength range does not |
1501 |
adequately cover the visible spectrum. |
1502 |
|
1503 |
<p> |
1504 |
|
1505 |
<dt> |
1506 |
<a NAME="Specfile"> |
1507 |
<b>Specfile</b> |
1508 |
</a> |
1509 |
|
1510 |
<dd> |
1511 |
The specfile primitive is equivalent to the spectrum type, but |
1512 |
the wavelength range and values are contained in a 1-dimensional |
1513 |
data file. |
1514 |
This may be a more convenient way to specify a spectral color, |
1515 |
especially one corresponding to a standard illuminant such as D65 |
1516 |
or a library of measured spectra. |
1517 |
|
1518 |
<pre> |
1519 |
mod specfile id |
1520 |
1 datafile |
1521 |
0 |
1522 |
0 |
1523 |
</pre> |
1524 |
|
1525 |
<p> |
1526 |
As with the spectrum type, rendering wavelengths outside the defined |
1527 |
range will be zero-filled. |
1528 |
Unlike the spectrum type, the file may contain non-uniform samples. |
1529 |
|
1530 |
<p> |
1531 |
|
1532 |
<dt> |
1533 |
<a NAME="Specfunc"> |
1534 |
<b>Specfunc</b> |
1535 |
</a> |
1536 |
|
1537 |
<dd> |
1538 |
The specfunc primitive offers dynamic control over a spectral |
1539 |
pattern, similar to the colorfunc type. |
1540 |
|
1541 |
<pre> |
1542 |
mod specfunc id |
1543 |
2+ sfunc funcfile transform |
1544 |
0 |
1545 |
2+ nmA nmB A3 .. |
1546 |
</pre> |
1547 |
|
1548 |
<p> |
1549 |
Like the spectrum primitive, the wavelength range is specified |
1550 |
in the first two real arguments, and additional real values are |
1551 |
set in the evaluation context. |
1552 |
This function is fed a wavelenth sample |
1553 |
between nmA and nmB as its only argument, |
1554 |
and it returns the corresponding spectral intensity. |
1555 |
|
1556 |
<dt> |
1557 |
<a NAME="Specdata"> |
1558 |
<b>Specdata</b> |
1559 |
</a> |
1560 |
|
1561 |
<dd> |
1562 |
Specdata is like brightdata and colordata, but with more |
1563 |
than 3 specular samples. |
1564 |
|
1565 |
<pre> |
1566 |
mod specdata id |
1567 |
3+n+ |
1568 |
func datafile |
1569 |
funcfile x1 x2 .. xn transform |
1570 |
0 |
1571 |
m A1 A2 .. Am |
1572 |
</pre> |
1573 |
|
1574 |
<p> |
1575 |
The data file must have one more dimension than the coordinate |
1576 |
variable count, as this final dimension corresponds to the covered |
1577 |
spectrum. |
1578 |
The starting and ending wavelengths are specified in "datafile" |
1579 |
as well as the number of spectral samples. |
1580 |
The function "func" will be called with two parameters, the |
1581 |
interpolated spectral value for the current coordinate and the |
1582 |
associated wavelength. |
1583 |
If the spectrum is broken into 12 components, then 12 calls |
1584 |
will be made to "func" for the relevant ray evaluation. |
1585 |
|
1586 |
<dt> |
1587 |
<a NAME="Specpict"> |
1588 |
<b>Specpict</b> |
1589 |
</a> |
1590 |
|
1591 |
<dd> |
1592 |
Specpict is a special case of specdata, where the pattern is |
1593 |
a hyperspectral image stored in the common-exponent file format. |
1594 |
The dimensions of the image data are determined by the picture |
1595 |
just as with the colorpict primitive. |
1596 |
|
1597 |
<pre> |
1598 |
mod specpict id |
1599 |
5+ |
1600 |
func specfile |
1601 |
funcfile u v transform |
1602 |
0 |
1603 |
m A1 A2 .. Am |
1604 |
</pre> |
1605 |
|
1606 |
<p> |
1607 |
The function "func" is called with the interpolated pixel value |
1608 |
and the wavelength sample in nanometers, the same as specdata, |
1609 |
with as many calls made as there are components in "specfile". |
1610 |
|
1611 |
</dl> |
1612 |
|
1613 |
<p> |
1614 |
<hr> |
1615 |
|
1616 |
<h4> |
1617 |
<a NAME="Mixtures">2.1.5. Mixtures</a> |
1618 |
</h4> |
1619 |
|
1620 |
A mixture is a blend of one or more materials or textures and patterns. |
1621 |
Blended materials should not be light source types or virtual source types. |
1622 |
The basic types are given below. |
1623 |
|
1624 |
<p> |
1625 |
|
1626 |
<dl> |
1627 |
|
1628 |
<dt> |
1629 |
<a NAME="Mixfunc"> |
1630 |
<b>Mixfunc</b> |
1631 |
</a> |
1632 |
|
1633 |
<dd> |
1634 |
A mixfunc mixes two modifiers procedurally. It is specified as follows: |
1635 |
|
1636 |
<pre> |
1637 |
mod mixfunc id |
1638 |
4+ foreground background vname funcfile transform |
1639 |
0 |
1640 |
n A1 A2 .. An |
1641 |
</pre> |
1642 |
|
1643 |
Foreground and background are modifier names that must be |
1644 |
defined earlier in the scene description. |
1645 |
If one of these is a material, then |
1646 |
the modifier of the mixfunc must be "void". |
1647 |
(Either the foreground or background modifier may be "void", |
1648 |
which serves as a form of opacity control when used with a material.) |
1649 |
Vname is the coefficient defined in funcfile that determines the influence of foreground. |
1650 |
The background coefficient is always (1-vname). |
1651 |
|
1652 |
<p> |
1653 |
|
1654 |
<dt> |
1655 |
<a NAME="Mixdata"> |
1656 |
<b>Mixdata</b> |
1657 |
</a> |
1658 |
|
1659 |
<dd> |
1660 |
Mixdata combines two modifiers using an auxiliary data file: |
1661 |
|
1662 |
<pre> |
1663 |
mod mixdata id |
1664 |
5+n+ |
1665 |
foreground background func datafile |
1666 |
funcfile x1 x2 .. xn transform |
1667 |
0 |
1668 |
m A1 A2 .. Am |
1669 |
</pre> |
1670 |
|
1671 |
<dt> |
1672 |
<a NAME="Mixpict"> |
1673 |
<b>Mixpict</b> |
1674 |
</a> |
1675 |
|
1676 |
<dd> |
1677 |
Mixpict combines two modifiers based on a picture: |
1678 |
|
1679 |
<pre> |
1680 |
mod mixpict id |
1681 |
7+ |
1682 |
foreground background func pictfile |
1683 |
funcfile u v transform |
1684 |
0 |
1685 |
m A1 A2 .. Am |
1686 |
</pre> |
1687 |
|
1688 |
<p> |
1689 |
|
1690 |
The mixing coefficient function "func" takes three |
1691 |
arguments, the red, green and blue values |
1692 |
corresponding to the pixel at (u,v). |
1693 |
|
1694 |
<p> |
1695 |
|
1696 |
<dt> |
1697 |
<a NAME="Mixtext"> |
1698 |
<b>Mixtext</b> |
1699 |
</a> |
1700 |
|
1701 |
<dd> |
1702 |
Mixtext uses one modifier for the text foreground, and one for the background: |
1703 |
|
1704 |
<pre> |
1705 |
mod mixtext id |
1706 |
4 foreground background fontfile textfile |
1707 |
0 |
1708 |
9+ |
1709 |
Ox Oy Oz |
1710 |
Rx Ry Rz |
1711 |
Dx Dy Dz |
1712 |
[spacing] |
1713 |
</pre> |
1714 |
|
1715 |
or: |
1716 |
|
1717 |
<pre> |
1718 |
mod mixtext id |
1719 |
4+N |
1720 |
foreground background fontfile . |
1721 |
This is a line with N words ... |
1722 |
0 |
1723 |
9+ |
1724 |
Ox Oy Oz |
1725 |
Rx Ry Rz |
1726 |
Dx Dy Dz |
1727 |
[spacing] |
1728 |
</pre> |
1729 |
|
1730 |
</dl> |
1731 |
|
1732 |
<p> |
1733 |
<hr> |
1734 |
|
1735 |
<h3> |
1736 |
<a NAME="Auxiliary">2.2. Auxiliary Files</a> |
1737 |
</h3> |
1738 |
|
1739 |
Auxiliary files used in <a HREF="#Textures">textures</a> and <a HREF="#Patterns">patterns</a> |
1740 |
are accessed by the programs during image generation. |
1741 |
These files may be located in the working directory, or in a library directory. |
1742 |
The environment variable RAYPATH can be assigned an alternate set of search directories. |
1743 |
Following is a brief description of some common file types. |
1744 |
|
1745 |
<p> |
1746 |
|
1747 |
<h4> |
1748 |
<a NAME="Function">12.2.1. Function Files</a> |
1749 |
</h4> |
1750 |
|
1751 |
A function file contains the definitions of variables, functions and constants used by a primitive. |
1752 |
The transformation that accompanies the file name contains the necessary rotations, translations and scalings |
1753 |
to bring the coordinates of the function file into agreement with the world coordinates. |
1754 |
The transformation specification is the same as for the <a HREF="#Generators">xform</a> command. |
1755 |
An example function file is given below: |
1756 |
|
1757 |
<pre> |
1758 |
{ |
1759 |
This is a comment, enclosed in curly braces. |
1760 |
{Comments can be nested.} |
1761 |
} |
1762 |
{ standard expressions use +,-,*,/,^,(,) } |
1763 |
vname = Ny * func(A1) ; |
1764 |
{ constants are defined with a colon } |
1765 |
const : sqrt(PI/2) ; |
1766 |
{ user-defined functions add to library } |
1767 |
func(x) = 5 + A1*sin(x/3) ; |
1768 |
{ functions may be passed and recursive } |
1769 |
rfunc(f,x) = if(x,f(x),f(-x)*rfunc(f,x+1)) ; |
1770 |
{ constant functions may also be defined } |
1771 |
cfunc(x) : 10*x / sqrt(x) ; |
1772 |
</pre> |
1773 |
|
1774 |
Many variables and functions are already defined by the program, and they are listed in the file rayinit.cal. |
1775 |
The following variables are particularly important: |
1776 |
|
1777 |
<pre> |
1778 |
Dx, Dy, Dz - incident ray direction |
1779 |
Nx, Ny, Nz - surface normal at intersection point |
1780 |
Px, Py, Pz - intersection point |
1781 |
T - distance from start |
1782 |
Ts - single ray (shadow) distance |
1783 |
Rdot - cosine between ray and normal |
1784 |
arg(0) - number of real arguments |
1785 |
arg(i) - i'th real argument |
1786 |
</pre> |
1787 |
|
1788 |
For mesh objects, the local surface coordinates are available: |
1789 |
|
1790 |
<pre> |
1791 |
Lu, Lv - local (u,v) coordinates |
1792 |
</pre> |
1793 |
|
1794 |
For BRDF types, the following variables are defined as well: |
1795 |
|
1796 |
<pre> |
1797 |
NxP, NyP, NzP - perturbed surface normal |
1798 |
RdotP - perturbed dot product |
1799 |
CrP, CgP, CbP - perturbed material color |
1800 |
</pre> |
1801 |
|
1802 |
A unique context is set up for each file so |
1803 |
that the same variable may appear in different |
1804 |
function files without conflict. |
1805 |
The variables listed above and any others defined in |
1806 |
rayinit.cal are available globally. |
1807 |
If no file is needed by a given primitive because all |
1808 |
the required variables are global, |
1809 |
a period (`.') can be given in place of the file name. |
1810 |
It is also possible to give an expression instead |
1811 |
of a straight variable name in a scene file. |
1812 |
Functions (requiring parameters) must be given |
1813 |
as names and not as expressions. |
1814 |
|
1815 |
<p> |
1816 |
Constant expressions are used as an optimization in function files. |
1817 |
They are replaced wherever they occur in an expression by their value. |
1818 |
Constant expressions are evaluated only once, so they must not contain any variables or values that can change, |
1819 |
such as the ray variables Px and Ny or the primitive argument function arg(). |
1820 |
All the math library functions such as sqrt() and cos() have the constant attribute, |
1821 |
so they will be replaced by immediate values whenever they are given constant arguments. |
1822 |
Thus, the subexpression cos(PI*sqrt(2)) is immediately replaced by its value, -.266255342, |
1823 |
and does not cause any additional overhead in the calculation. |
1824 |
|
1825 |
<p> |
1826 |
It is generally a good idea to define constants and variables before they are referred to in a function file. |
1827 |
Although evaluation does not take place until later, the interpreter does variable scoping and |
1828 |
constant subexpression evaluation based on what it has compiled already. |
1829 |
For example, a variable that is defined globally in rayinit.cal |
1830 |
then referenced in the local context of a function file |
1831 |
cannot subsequently be redefined in the same file |
1832 |
because the compiler has already determined the scope of the referenced variable as global. |
1833 |
To avoid such conflicts, one can state the scope of a variable explicitly by |
1834 |
preceding the variable name with a context mark (a back-quote) for a local variable, |
1835 |
or following the name with a context mark for a global variable. |
1836 |
|
1837 |
<p> |
1838 |
|
1839 |
<h4> |
1840 |
<a NAME="Data">2.2.2. Data Files</a> |
1841 |
</h4> |
1842 |
|
1843 |
Data files contain n-dimensional arrays of real numbers used for interpolation. |
1844 |
Typically, definitions in a function file determine how to index and use interpolated data values. |
1845 |
The basic data file format is as follows: |
1846 |
|
1847 |
<pre> |
1848 |
N |
1849 |
beg1 end1 m1 |
1850 |
0 0 m2 x2.1 x2.2 x2.3 x2.4 .. x2.m2 |
1851 |
... |
1852 |
begN endN mN |
1853 |
DATA, later dimensions changing faster. |
1854 |
</pre> |
1855 |
|
1856 |
N is the number of dimensions. |
1857 |
For each dimension, the beginning and ending coordinate values and the dimension size is given. |
1858 |
Alternatively, individual coordinate values can be given when the points are not evenly spaced. |
1859 |
These values must either be increasing or decreasing monotonically. |
1860 |
The data is m1*m2*...*mN real numbers in ASCII form. |
1861 |
Comments may appear anywhere in the file, beginning with a pound |
1862 |
sign ('#') and continuing to the end of line. |
1863 |
|
1864 |
<p> |
1865 |
|
1866 |
<h4> |
1867 |
<a NAME="Font">2.2.3. Font Files</a> |
1868 |
</h4> |
1869 |
|
1870 |
A font file lists the polygons which make up a character set. |
1871 |
Comments may appear anywhere in the file, beginning with a pound |
1872 |
sign ('#') and continuing to the end of line. |
1873 |
All numbers are decimal integers: |
1874 |
|
1875 |
<pre> |
1876 |
code n |
1877 |
x0 y0 |
1878 |
x1 y1 |
1879 |
... |
1880 |
xn yn |
1881 |
... |
1882 |
</pre> |
1883 |
|
1884 |
The ASCII codes can appear in any order. N is the number of vertices, and the last is automatically connected to the first. |
1885 |
Separate polygonal sections are joined by coincident sides. |
1886 |
The character coordinate system is a square with lower left corner at (0,0), lower right at (255,0) and upper right at (255,255). |
1887 |
|
1888 |
<p> |
1889 |
|
1890 |
<hr> |
1891 |
|
1892 |
<h3> |
1893 |
<a NAME="Generators">2.3. Generators</a> |
1894 |
</h3> |
1895 |
|
1896 |
A generator is any program that produces a scene description as its output. |
1897 |
They usually appear as commands in a scene description file. |
1898 |
An example of a simple generator is genbox. |
1899 |
|
1900 |
<ul> |
1901 |
|
1902 |
<li> |
1903 |
<a NAME="Genbox" HREF="../man_html/genbox.1.html"> |
1904 |
<b>Genbox</b> |
1905 |
</a> |
1906 |
takes the arguments of width, height and depth to produce a parallelepiped description. |
1907 |
<li> |
1908 |
<a NAME="Genprism" HREF="../man_html/genprism.1.html"> |
1909 |
<b>Genprism</b> |
1910 |
</a> |
1911 |
takes a list of 2-dimensional coordinates and extrudes them along a vector to |
1912 |
produce a 3-dimensional prism. |
1913 |
<li> |
1914 |
<a NAME="Genrev" HREF="../man_html/genrev.1.html"> |
1915 |
<b>Genrev</b> |
1916 |
</a> |
1917 |
is a more sophisticated generator that produces an object of rotation from parametric functions for radius and axis position. |
1918 |
<li> |
1919 |
<a NAME="Gensurf" HREF="../man_html/gensurf.1.html"> |
1920 |
<b>Gensurf</b> |
1921 |
</a> |
1922 |
tessellates a surface defined by the parametric functions x(s,t), y(s,t), and z(s,t). |
1923 |
<li> |
1924 |
<a NAME="Genworm" HREF="../man_html/genworm.1.html"> |
1925 |
<b>Genworm</b> |
1926 |
</a> |
1927 |
links cylinders and spheres along a curve. |
1928 |
<li> |
1929 |
<a NAME="Gensky" HREF="../man_html/gensky.1.html"> |
1930 |
<b>Gensky</b> |
1931 |
</a> |
1932 |
produces a sun and sky distribution corresponding to a given time and date. |
1933 |
<li> |
1934 |
<a NAME="Xform" HREF="../man_html/xform.1.html"> |
1935 |
<b>Xform</b> |
1936 |
</a> |
1937 |
is a program that transforms a scene description from one coordinate space to another. |
1938 |
Xform does rotation, translation, scaling, and mirroring. |
1939 |
|
1940 |
</ul> |
1941 |
|
1942 |
<p> |
1943 |
<hr> |
1944 |
|
1945 |
<h2> |
1946 |
<a NAME="Image">3. Image Generation</a> |
1947 |
</h2> |
1948 |
|
1949 |
Once the scene has been described in three-dimensions, it is possible to generate a two-dimensional image from a given perspective. |
1950 |
|
1951 |
<p> |
1952 |
The image generating programs use an <a NAME="octree"><b>octree</b></a> to efficiently trace rays through the scene. |
1953 |
An octree subdivides space into nested octants which contain sets of surfaces. |
1954 |
In RADIANCE, an octree is created from a scene description by <a NAME="oconv1" HREF="../man_html/oconv.1.html"><b>oconv</b></a>. |
1955 |
The details of this process are not important, but the octree will serve as input to the ray-tracing programs and |
1956 |
directs the use of a scene description. |
1957 |
<ul> |
1958 |
<li> |
1959 |
<a NAME="rvu" HREF="../man_html/rvu.1.html"><b>Rvu</b></a> is ray-tracing program for viewing a scene interactively. |
1960 |
When the user specifies a new perspective, rvu quickly displays a rough image on the terminal, |
1961 |
then progressively increases the resolution as the user looks on. |
1962 |
He can select a particular section of the image to improve, or move to a different view and start over. |
1963 |
This mode of interaction is useful for debugging scenes as well as determining the best view for a final image. |
1964 |
|
1965 |
<li> |
1966 |
<a NAME="rpict" HREF="../man_html/rpict.1.html"><b>Rpict</b></a> produces a high-resolution picture of a scene from a particular perspective. |
1967 |
This program features adaptive sampling, crash recovery and progress reporting, all of which are important for time-consuming images. |
1968 |
</ul> |
1969 |
<p> |
1970 |
A number of <a NAME="filters"><b>filters</b></a> are available for manipulating picture files: |
1971 |
<ul> |
1972 |
<li> <a HREF="../man_html/pfilt.1.html"><b>Pfilt</b></a> |
1973 |
sets the exposure and performs antialiasing. |
1974 |
<li> <a HREF="../man_html/pcompos.1.html"><b>Pcompos</b></a> |
1975 |
composites (cuts and pastes) pictures. |
1976 |
<li> <a HREF="../man_html/pcomb.1.html"><b>Pcomb</b></a> |
1977 |
performs arbitrary math on one or more pictures. |
1978 |
<li> <a HREF="../man_html/pcond.1.html"><b>Pcond</b></a> |
1979 |
conditions a picture for a specific display device. |
1980 |
<li> <a HREF="../man_html/protate.1.html"><b>Protate</b></a> |
1981 |
rotates a picture 90 degrees clockwise. |
1982 |
<li> <a HREF="../man_html/pflip.1.html"><b>Pflip</b></a> |
1983 |
flips a picture horizontally, vertically, or both |
1984 |
(180 degree rotation). |
1985 |
<li> <a HREF="../man_html/pvalue.1.html"><b>Pvalue</b></a> |
1986 |
converts a picture to and from simpler formats. |
1987 |
</ul> |
1988 |
|
1989 |
<p> |
1990 |
Pictures may be displayed directly under X11 using the program |
1991 |
<a HREF="../man_html/ximage.1.html">ximage</a>, |
1992 |
or converted a standard image format using one of the following |
1993 |
<b>translators</b>: |
1994 |
<ul> |
1995 |
<li> <a HREF="../man_html/ra_bmp.1.html"><b>Ra_bmp</b></a> |
1996 |
converts to and from BMP image format. |
1997 |
<li> <a HREF="../man_html/ra_ppm.1.html"><b>Ra_ppm</b></a> |
1998 |
converts to and from Poskanzer Portable Pixmap formats. |
1999 |
<li> <a HREF="../man_html/ra_ps.1.html"><b>Ra_ps</b></a> |
2000 |
converts to PostScript color and greyscale formats. |
2001 |
<li> <a HREF="../man_html/ra_rgbe.1.html"><b>Ra_rgbe</b></a> |
2002 |
converts to and from Radiance uncompressed picture format. |
2003 |
<li> <a HREF="../man_html/ra_t16.1.html"><b>Ra_t16</b></a> |
2004 |
converts to and from Targa 16 and 24-bit image formats. |
2005 |
<li> <a HREF="../man_html/ra_t8.1.html"><b>Ra_t8</b></a> |
2006 |
converts to and from Targa 8-bit image format. |
2007 |
<li> <a HREF="../man_html/ra_tiff.1.html"><b>Ra_tiff</b></a> |
2008 |
converts to and from TIFF. |
2009 |
<li> <a HREF="../man_html/ra_xyze.1.html"><b>Ra_xyze</b></a> |
2010 |
converts to and from Radiance CIE picture format. |
2011 |
</ul> |
2012 |
|
2013 |
<p> |
2014 |
|
2015 |
<hr> |
2016 |
|
2017 |
<h2> |
2018 |
<a NAME="License">4. License</a> |
2019 |
</h2> |
2020 |
|
2021 |
<pre> |
2022 |
The Radiance Software License, Version 1.0 |
2023 |
|
2024 |
Copyright (c) 1990 - 2021 The Regents of the University of California, |
2025 |
through Lawrence Berkeley National Laboratory. All rights reserved. |
2026 |
|
2027 |
Redistribution and use in source and binary forms, with or without |
2028 |
modification, are permitted provided that the following conditions |
2029 |
are met: |
2030 |
|
2031 |
1. Redistributions of source code must retain the above copyright |
2032 |
notice, this list of conditions and the following disclaimer. |
2033 |
|
2034 |
2. Redistributions in binary form must reproduce the above copyright |
2035 |
notice, this list of conditions and the following disclaimer in |
2036 |
the documentation and/or other materials provided with the |
2037 |
distribution. |
2038 |
|
2039 |
3. The end-user documentation included with the redistribution, |
2040 |
if any, must include the following acknowledgment: |
2041 |
"This product includes Radiance software |
2042 |
(<a HREF="http://radsite.lbl.gov/">http://radsite.lbl.gov/</a>) |
2043 |
developed by the Lawrence Berkeley National Laboratory |
2044 |
(<a HREF="http://www.lbl.gov/">http://www.lbl.gov/</a>)." |
2045 |
Alternately, this acknowledgment may appear in the software itself, |
2046 |
if and wherever such third-party acknowledgments normally appear. |
2047 |
|
2048 |
4. The names "Radiance," "Lawrence Berkeley National Laboratory" |
2049 |
and "The Regents of the University of California" must |
2050 |
not be used to endorse or promote products derived from this |
2051 |
software without prior written permission. For written |
2052 |
permission, please contact [email protected]. |
2053 |
|
2054 |
5. Products derived from this software may not be called "Radiance", |
2055 |
nor may "Radiance" appear in their name, without prior written |
2056 |
permission of Lawrence Berkeley National Laboratory. |
2057 |
|
2058 |
THIS SOFTWARE IS PROVIDED ``AS IS" AND ANY EXPRESSED OR IMPLIED |
2059 |
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES |
2060 |
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE |
2061 |
DISCLAIMED. IN NO EVENT SHALL Lawrence Berkeley National Laboratory OR |
2062 |
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, |
2063 |
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT |
2064 |
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF |
2065 |
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND |
2066 |
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, |
2067 |
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT |
2068 |
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF |
2069 |
SUCH DAMAGE. |
2070 |
</pre> |
2071 |
|
2072 |
<hr> |
2073 |
|
2074 |
<h2> |
2075 |
<a NAME="Ack">5. Acknowledgements</a> |
2076 |
</h2> |
2077 |
|
2078 |
This work was supported by the Assistant Secretary of Conservation and Renewable Energy, |
2079 |
Office of Building Energy Research and Development, |
2080 |
Buildings Equipment Division of the U.S. Department of Energy under Contract No. DE-AC03-76SF00098. |
2081 |
|
2082 |
<p> |
2083 |
Additional work was sponsored by the Swiss federal government |
2084 |
under the Swiss LUMEN Project and was carried out in the |
2085 |
Laboratoire d'Energie Solaire (LESO Group) at the |
2086 |
Ecole Polytechnique Federale de Lausanne (EPFL University) in Lausanne, Switzerland. |
2087 |
|
2088 |
<p> |
2089 |
|
2090 |
<hr> |
2091 |
|
2092 |
<h2> |
2093 |
<a NAME="Ref">6.</a> References |
2094 |
</h2> |
2095 |
<p> |
2096 |
<ul> |
2097 |
<li>Ward, Gregory J., Bruno Bueno, David Geisler-Moroder, |
2098 |
Lars O. Grobe, Jacob C. Jonsson, Eleanor |
2099 |
S. Lee, Taoning Wang, Helen Rose Wilson, |
2100 |
"<a href="https://doi.org/10.1016/j.enbuild.2022.111890">Daylight |
2101 |
Simulation Workflows Incorporating Measured Bidirectional |
2102 |
Scattering Distribution Functions</a>" |
2103 |
<em>Energy & Buildings</em>, Vol. 259, No. 11890, 2022. |
2104 |
<li>Wang, Taoning, Gregory Ward, Eleanor Lee, |
2105 |
"<a href="https://authors.elsevier.com/a/1XQ0a1M7zGwT7v">Efficient |
2106 |
modeling of optically-complex, non-coplanar exterior shading: |
2107 |
Validation of matrix algebraic methods</a>" |
2108 |
<em>Energy & Buildings</em>, vol. 174, pp. 464-83, Sept. 2018. |
2109 |
<li>Lee, Eleanor S., David Geisler-Moroder, Gregory Ward, |
2110 |
"<a href="https://eta.lbl.gov/sites/default/files/publications/solar_energy.pdf">Modeling |
2111 |
the direct sun component in buildings using matrix |
2112 |
algebraic approaches: Methods and |
2113 |
validation</a>," <em>Solar Energy</em>, |
2114 |
vol. 160, 15 January 2018, pp 380-395. |
2115 |
<li>Narain, Rahul, Rachel A. Albert, Abdullah Bulbul, |
2116 |
Gregory J. Ward, Marty Banks, James F. O'Brien, |
2117 |
"<a href="http://graphics.berkeley.edu/papers/Narain-OPI-2015-08/index.html">Optimal |
2118 |
Presentation of Imagery with Focus |
2119 |
Cues on Multi-Plane Displays</a>," |
2120 |
<em>SIGGRAPH 2015</em>. |
2121 |
<li>Ward, Greg, Murat Kurt, and Nicolas Bonneel, |
2122 |
"<a href="papers/WMAM14_Tensor_Tree_Representation.pdf">Reducing |
2123 |
Anisotropic BSDF Measurement to Common Practice</a>," |
2124 |
<em>Workshop on Material Appearance Modeling</em>, 2014. |
2125 |
<li>Banks, Martin, Abdullah Bulbul, Rachel Albert, Rahul Narain, |
2126 |
James F. O'Brien, Gregory Ward, |
2127 |
"<a href="http://graphics.berkeley.edu/papers/Banks-TPO-2014-05/index.html">The |
2128 |
Perception of Surface Material from Disparity and Focus Cues</a>," |
2129 |
<em>VSS 2014</em>. |
2130 |
<li>McNeil, A., C.J. Jonsson, D. Appelfeld, G. Ward, E.S. Lee, |
2131 |
"<a href="http://gaia.lbl.gov/btech/papers/4414.pdf"> |
2132 |
A validation of a ray-tracing tool used to generate |
2133 |
bi-directional scattering distribution functions for |
2134 |
complex fenestration systems</a>," |
2135 |
<em>Solar Energy</em>, 98, 404-14, |
2136 |
November 2013. |
2137 |
<li>Ward, G., R. Mistrick, E.S. Lee, A. McNeil, J. Jonsson, |
2138 |
"<a href="http://gaia.lbl.gov/btech/papers/4414.pdf">Simulating |
2139 |
the Daylight Performance of Complex Fenestration Systems |
2140 |
Using Bidirectional Scattering Distribution Functions within |
2141 |
Radiance</a>," |
2142 |
<em>Leukos</em>, 7(4) |
2143 |
April 2011. |
2144 |
<li>Cater, Kirsten, Alan Chalmers, Greg Ward, |
2145 |
"<a href="http://www.anyhere.com/gward/papers/egsr2003.pdf">Detail to Attention: |
2146 |
Exploiting Visual Tasks for Selective Rendering</a>," |
2147 |
<em>Eurographics Symposium |
2148 |
on Rendering 2003</em>, June 2003. |
2149 |
<li>Ward, Greg, Elena Eydelberg-Vileshin, |
2150 |
"<a HREF="http://www.anyhere.com/gward/papers/egwr02/index.html">Picture Perfect RGB |
2151 |
Rendering Using Spectral Prefiltering and Sharp Color Primaries</a>," |
2152 |
Thirteenth Eurographics Workshop on Rendering (2002), |
2153 |
P. Debevec and S. Gibson (Editors), June 2002. |
2154 |
<li>Ward, Gregory, |
2155 |
"<a HREF="http://www.anyhere.com/gward/papers/cic01.pdf">High Dynamic Range Imaging</a>," |
2156 |
Proceedings of the Ninth Color Imaging Conference, November 2001. |
2157 |
<li>Ward, Gregory and Maryann Simmons, |
2158 |
"<a HREF="http://www.anyhere.com/gward/papers/tog99.pdf"> |
2159 |
The Holodeck Ray Cache: An Interactive Rendering System for Global Illumination in Nondiffuse |
2160 |
Environments</a>," ACM Transactions on Graphics, 18(4):361-98, October 1999. |
2161 |
<li>Larson, G.W., "<a HREF="http://www.anyhere.com/gward/papers/ewp98.pdf">The Holodeck: A Parallel |
2162 |
Ray-caching Rendering System</a>," Proceedings of the Second |
2163 |
Eurographics Workshop on Parallel Graphics and Visualisation, |
2164 |
September 1998. |
2165 |
<li>Larson, G.W. and R.A. Shakespeare, |
2166 |
<a HREF="http://radsite.lbl.gov/radiance/book/index.html"><em>Rendering with Radiance: |
2167 |
the Art and Science of Lighting Visualization</em></a>, |
2168 |
Morgan Kaufmann Publishers, 1998. |
2169 |
<li>Larson, G.W., H. Rushmeier, C. Piatko, |
2170 |
"<a HREF="http://radsite.lbl.gov/radiance/papers/lbnl39882/tonemap.pdf">A Visibility |
2171 |
Matching Tone Reproduction Operator for |
2172 |
High Dynamic Range Scenes</a>," LBNL Technical Report 39882, |
2173 |
January 1997. |
2174 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/erw95.1/paper.html">Making |
2175 |
Global Illumination User-Friendly</a>," Sixth |
2176 |
Eurographics Workshop on Rendering, Springer-Verlag, |
2177 |
Dublin, Ireland, June 1995.</li> |
2178 |
<li>Rushmeier, H., G. Ward, C. Piatko, P. Sanders, B. Rust, |
2179 |
"<a HREF="http://radsite.lbl.gov/mgf/compare.html"> |
2180 |
Comparing Real and Synthetic Images: Some Ideas about |
2181 |
Metrics</a>," Sixth Eurographics Workshop on Rendering, |
2182 |
Springer-Verlag, Dublin, Ireland, June 1995.</li> |
2183 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/sg94.1/paper.html">The RADIANCE |
2184 |
Lighting Simulation and Rendering System</a>," <em>Computer |
2185 |
Graphics</em>, July 1994.</li> |
2186 |
<li>Rushmeier, H., G. Ward, "<a HREF="http://radsite.lbl.gov/radiance/papers/sg94.2/energy.html">Energy |
2187 |
Preserving Non-Linear Filters</a>," <em>Computer |
2188 |
Graphics</em>, July 1994.</li> |
2189 |
<li>Ward, G., "A Contrast-Based Scalefactor for Luminance |
2190 |
Display," <em>Graphics Gems IV</em>, Edited by Paul Heckbert, |
2191 |
Academic Press 1994.</li> |
2192 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/sg92/paper.html">Measuring and |
2193 |
Modeling Anisotropic Reflection</a>," <em>Computer |
2194 |
Graphics</em>, Vol. 26, No. 2, July 1992. </li> |
2195 |
<li>Ward, G., P. Heckbert, "<a HREF="http://radsite.lbl.gov/radiance/papers/erw92/paper.html">Irradiance |
2196 |
Gradients</a>," Third Annual Eurographics Workshop on |
2197 |
Rendering, Springer-Verlag, May 1992. </li> |
2198 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/erw91/erw91.html">Adaptive Shadow |
2199 |
Testing for Ray Tracing</a>" Photorealistic Rendering in |
2200 |
Computer Graphics, proceedings of 1991 Eurographics |
2201 |
Rendering Workshop, edited by P. Brunet and F.W. Jansen, |
2202 |
Springer-Verlag. </li> |
2203 |
<li>Ward, G., "Visualization," <em>Lighting Design and |
2204 |
Application</em>, Vol. 20, No. 6, June 1990. </li> |
2205 |
<li>Ward, G., F. Rubinstein, R. Clear, "<a HREF="http://radsite.lbl.gov/radiance/papers/sg88/paper.html">A Ray Tracing Solution for |
2206 |
Diffuse Interreflection</a>," <em>Computer Graphics</em>, |
2207 |
Vol. 22, No. 4, August 1988. </li> |
2208 |
<li>Ward, G., F. Rubinstein, "A New Technique for Computer |
2209 |
Simulation of Illuminated Spaces," <em>Journal of the |
2210 |
Illuminating Engineering Society</em>, Vol. 17, No. 1, |
2211 |
Winter 1988. </li> |
2212 |
</ul> |
2213 |
<p> |
2214 |
See the <a HREF="index.html">RADIANCE Reference Materials</a> page |
2215 |
for additional information. |
2216 |
<hr> |
2217 |
|
2218 |
<a NAME="Index"><h2>7. Types Index</h2></a> |
2219 |
|
2220 |
<pre> |
2221 |
<h4> |
2222 |
SURFACES MATERIALS TEXTURES PATTERNS MIXTURES</h4> |
2223 |
<a HREF="#Source">Source</a> <a HREF="#Light">Light</a> <a HREF="#Texfunc">Texfunc</a> <a HREF="#Colorfunc">Colorfunc</a> <a HREF="#Mixfunc">Mixfunc</a> |
2224 |
<a HREF="#Sphere">Sphere</a> <a HREF="#Illum">Illum</a> <a HREF="#Texdata">Texdata</a> <a HREF="#Brightfunc">Brightfunc</a> <a HREF="#Mixdata">Mixdata</a> |
2225 |
<a HREF="#Bubble">Bubble</a> <a HREF="#Glow">Glow</a> <a HREF="#Colordata">Colordata</a> <a HREF="#Mixtext">Mixtext</a> |
2226 |
<a HREF="#Polygon">Polygon</a> <a HREF="#Spotlight">Spotlight</a> <a HREF="#Brightdata">Brightdata</a> |
2227 |
<a HREF="#Cone">Cone</a> <a HREF="#Mirror">Mirror</a> <a HREF="#Colorpict">Colorpict</a> |
2228 |
<a HREF="#Cup">Cup</a> <a HREF="#Prism1">Prism1</a> <a HREF="#Colortext">Colortext</a> |
2229 |
<a HREF="#Cylinder">Cylinder</a> <a HREF="#Prism2">Prism2</a> <a HREF="#Brighttext">Brighttext</a> |
2230 |
<a HREF="#Tube">Tube</a> <a HREF="#Plastic">Plastic</a> |
2231 |
<a HREF="#Ring">Ring</a> <a HREF="#Metal">Metal</a> |
2232 |
<a HREF="#Instance">Instance</a> <a HREF="#Trans">Trans</a> |
2233 |
<a HREF="#Mesh">Mesh</a> <a HREF="#Plastic2">Plastic2</a> |
2234 |
<a HREF="#Metal2">Metal2</a> |
2235 |
<a HREF="#Trans2">Trans2</a> |
2236 |
<a HREF="#Mist">Mist</a> |
2237 |
<a HREF="#Dielectric">Dielectric</a> |
2238 |
<a HREF="#Interface">Interface</a> |
2239 |
<a HREF="#Glass">Glass</a> |
2240 |
<a HREF="#Plasfunc">Plasfunc</a> |
2241 |
<a HREF="#Metfunc">Metfunc</a> |
2242 |
<a HREF="#Transfunc">Transfunc</a> |
2243 |
<a HREF="#BRTDfunc">BRTDfunc</a> |
2244 |
<a HREF="#Plasdata">Plasdata</a> |
2245 |
<a HREF="#Metdata">Metdata</a> |
2246 |
<a HREF="#Transdata">Transdata</a> |
2247 |
<a HREF="#BSDF">BSDF</a> |
2248 |
<a HREF="#Antimatter">Antimatter</a> |
2249 |
|
2250 |
</pre> |
2251 |
|
2252 |
<p> |
2253 |
|
2254 |
|
2255 |
<hr> |
2256 |
<center>Last Update: October 22, 1997</center> |
2257 |
</body> |
2258 |
</html> |
2259 |
|