1 |
<html> |
2 |
<!-- RCSid $Id: ray.html,v 1.26 2018/06/26 14:42:18 greg Exp $ --> |
3 |
<head> |
4 |
<title> |
5 |
The RADIANCE 5.2 Synthetic Imaging System |
6 |
</title> |
7 |
</head> |
8 |
<body> |
9 |
|
10 |
<p> |
11 |
|
12 |
<h1> |
13 |
The RADIANCE 5.2 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>Rview</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 |
<pre> |
826 |
mod ashik2 id |
827 |
4+ ux uy uz funcfile transform |
828 |
0 |
829 |
8 dred dgrn dblu sred sgrn sblu u-power v-power |
830 |
</pre> |
831 |
|
832 |
<p> |
833 |
|
834 |
<dt> |
835 |
<a NAME="Dielectric"> |
836 |
<b>Dielectric</b> |
837 |
</a> |
838 |
|
839 |
<dd> |
840 |
A dielectric material is transparent, and it refracts light as well as reflecting it. |
841 |
Its behavior is determined by the index of refraction and transmission coefficient in each wavelength band per unit length. |
842 |
Common glass has a index of refraction (n) around 1.5, and a transmission coefficient of roughly 0.92 over an inch. |
843 |
An additional number, the Hartmann constant, describes how the index of refraction changes as a function of wavelength. |
844 |
It is usually zero. (A <a HREF="#Patterns">pattern</a> modifies only the refracted value.) |
845 |
|
846 |
<pre> |
847 |
mod dielectric id |
848 |
0 |
849 |
0 |
850 |
5 rtn gtn btn n hc |
851 |
</pre> |
852 |
|
853 |
<p> |
854 |
|
855 |
<dt> |
856 |
<a NAME="Interface"> |
857 |
<b>Interface</b> |
858 |
</a> |
859 |
|
860 |
<dd> |
861 |
An interface is a boundary between two dielectrics. |
862 |
The first transmission coefficient and refractive index are for the inside; the second ones are for the outside. |
863 |
Ordinary dielectrics are surrounded by a vacuum (1 1 1 1). |
864 |
|
865 |
<pre> |
866 |
mod interface id |
867 |
0 |
868 |
0 |
869 |
8 rtn1 gtn1 btn1 n1 rtn2 gtn2 btn2 n2 |
870 |
</pre> |
871 |
|
872 |
<p> |
873 |
|
874 |
<dt> |
875 |
<a NAME="Glass"> |
876 |
<b>Glass</b> |
877 |
</a> |
878 |
|
879 |
<dd> |
880 |
Glass is similar to <a HREF="#Dielectric">dielectric</a>, but it is optimized for thin glass surfaces (n = 1.52). |
881 |
One transmitted ray and one reflected ray is produced. |
882 |
By using a single surface is in place of two, internal reflections are avoided. |
883 |
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>. |
884 |
The only specification required is the transmissivity at normal incidence. |
885 |
(Transmissivity is the amount of light not absorbed in one traversal |
886 |
of the material. |
887 |
Transmittance -- the value usually measured -- is the total light |
888 |
transmitted through the pane including multiple reflections.) |
889 |
To compute transmissivity (tn) from transmittance (Tn) use: |
890 |
|
891 |
<pre> |
892 |
tn = (sqrt(.8402528435+.0072522239*Tn*Tn)-.9166530661)/.0036261119/Tn |
893 |
</pre> |
894 |
|
895 |
Standard 88% transmittance glass has a transmissivity of 0.96. |
896 |
(A <a HREF="#Patterns">pattern</a> modifying glass will affect the transmissivity.) |
897 |
If a fourth real argument is given, it is interpreted as the index of refraction to use instead of 1.52. |
898 |
|
899 |
<pre> |
900 |
mod glass id |
901 |
0 |
902 |
0 |
903 |
3 rtn gtn btn |
904 |
</pre> |
905 |
|
906 |
<p> |
907 |
|
908 |
<dt> |
909 |
<a NAME="Plasfunc"> |
910 |
<b>Plasfunc</b> |
911 |
</a> |
912 |
|
913 |
<dd> |
914 |
Plasfunc in used for the procedural definition of plastic-like materials |
915 |
with arbitrary bidirectional reflectance distribution functions (BRDF's). |
916 |
The arguments to this material include the color and specularity, |
917 |
as well as the function defining the specular distribution and the auxiliary file where it may be found. |
918 |
|
919 |
<pre> |
920 |
mod plasfunc id |
921 |
2+ refl funcfile transform |
922 |
0 |
923 |
4+ red green blue spec A5 .. |
924 |
</pre> |
925 |
|
926 |
The function refl takes four arguments, the x, y and z |
927 |
direction towards the incident light, and the solid angle |
928 |
subtended by the source. |
929 |
The solid angle is provided to facilitate averaging, and is usually |
930 |
ignored. |
931 |
The refl function should integrate to 1 over |
932 |
the projected hemisphere to maintain energy balance. |
933 |
At least four real arguments must be given, and these are made available along with any additional values to the reflectance function. |
934 |
Currently, only the contribution from direct light sources is considered in the specular calculation. |
935 |
As in most material types, the surface normal is always altered to face the incoming ray. |
936 |
|
937 |
<p> |
938 |
|
939 |
<dt> |
940 |
<a NAME="Metfunc"> |
941 |
<b>Metfunc</b> |
942 |
</a> |
943 |
|
944 |
<dd> |
945 |
Metfunc is identical to <a HREF="#Plasfunc">plasfunc</a> and takes the same arguments, |
946 |
but the specular component is multiplied also by the material color. |
947 |
|
948 |
<p> |
949 |
|
950 |
<dt> |
951 |
<a NAME="Transfunc"> |
952 |
<b>Transfunc</b> |
953 |
</a> |
954 |
|
955 |
<dd> |
956 |
Transfunc is similar to <a HREF="#Plasfunc">plasfunc</a> but with an arbitrary bidirectional transmittance distribution |
957 |
as well as a reflectance distribution. |
958 |
Both reflectance and transmittance are specified with the same function. |
959 |
|
960 |
<pre> |
961 |
mod transfunc id |
962 |
2+ brtd funcfile transform |
963 |
0 |
964 |
6+ red green blue rspec trans tspec A7 .. |
965 |
</pre> |
966 |
|
967 |
Where trans is the total light transmitted and tspec is the non-Lambertian fraction of transmitted light. |
968 |
The function brtd should integrate to 1 over each projected hemisphere. |
969 |
|
970 |
<p> |
971 |
|
972 |
<dt> |
973 |
<a NAME="BRTDfunc"> |
974 |
<b>BRTDfunc</b> |
975 |
</a> |
976 |
|
977 |
<dd> |
978 |
The material BRTDfunc gives the maximum flexibility over surface reflectance and transmittance, |
979 |
providing for spectrally-dependent specular rays and reflectance and transmittance distribution functions. |
980 |
|
981 |
<pre> |
982 |
mod BRTDfunc id |
983 |
10+ rrefl grefl brefl |
984 |
rtrns gtrns btrns |
985 |
rbrtd gbrtd bbrtd |
986 |
funcfile transform |
987 |
0 |
988 |
9+ rfdif gfdif bfdif |
989 |
rbdif gbdif bbdif |
990 |
rtdif gtdif btdif |
991 |
A10 .. |
992 |
</pre> |
993 |
|
994 |
The variables rrefl, grefl and brefl specify the color coefficients for the ideal specular (mirror) reflection of the surface. |
995 |
The variables rtrns, gtrns and btrns specify the color coefficients for the ideal specular transmission. |
996 |
The functions rbrtd, gbrtd and bbrtd take the direction to the incident light (and its solid angle) and |
997 |
compute the color coefficients for the directional diffuse part of reflection and transmission. |
998 |
As a special case, three identical values of '0' may be given in place of these function names to indicate no directional diffuse component. |
999 |
|
1000 |
<p> |
1001 |
Unlike most other material types, the surface normal is not altered to face the incoming ray. |
1002 |
Thus, functions and variables must pay attention to the orientation of the surface and make adjustments appropriately. |
1003 |
However, the special variables for the perturbed dot product and surface normal, RdotP, NxP, NyP and NzP are reoriented |
1004 |
as if the ray hit the front surface for convenience. |
1005 |
|
1006 |
<p> |
1007 |
A diffuse reflection component may be given for the front side with rfdif, gfdif and bfdif for the front side of the surface |
1008 |
or rbdif, gbdif and bbdif for the back side. |
1009 |
The diffuse transmittance (must be the same for both sides by physical law) is given by rtdif, gtdif and btdif. |
1010 |
A pattern will modify these diffuse scattering values, and will be available through the special variables CrP, CgP and CbP. |
1011 |
|
1012 |
<p> |
1013 |
Care must be taken when using this material type to produce a physically valid reflection model. |
1014 |
The reflectance functions should be bidirectional, and under no circumstances should the sum of reflected diffuse, |
1015 |
transmitted diffuse, reflected specular, transmitted specular and the integrated directional diffuse component be greater than one. |
1016 |
|
1017 |
<p> |
1018 |
|
1019 |
<dt> |
1020 |
<a NAME="Plasdata"> |
1021 |
<b>Plasdata</b> |
1022 |
</a> |
1023 |
|
1024 |
<dd> |
1025 |
Plasdata is used for arbitrary BRDF's that are most conveniently given as interpolated data. |
1026 |
The arguments to this material are the <a HREF="#Data">data file</a> and coordinate index functions, |
1027 |
as well as a function to optionally modify the data values. |
1028 |
|
1029 |
<pre> |
1030 |
mod plasdata id |
1031 |
3+n+ |
1032 |
func datafile |
1033 |
funcfile x1 x2 .. xn transform |
1034 |
0 |
1035 |
4+ red green blue spec A5 .. |
1036 |
</pre> |
1037 |
|
1038 |
The coordinate indices (x1, x2, etc.) are themselves functions of the x, y and z direction to the incident light, plus the solid angle |
1039 |
subtended by the light source (usually ignored). |
1040 |
The data function (func) takes five variables, the |
1041 |
interpolated value from the n-dimensional data file, followed by the |
1042 |
x, y and z direction to the incident light and the solid angle of the source. |
1043 |
The light source direction and size may of course be ignored by the function. |
1044 |
|
1045 |
<p> |
1046 |
|
1047 |
<dt> |
1048 |
<a NAME="Metdata"> |
1049 |
<b>Metdata</b> |
1050 |
</a> |
1051 |
|
1052 |
<dd> |
1053 |
As metfunc is to plasfunc, metdata is to <a HREF="#Plasdata">plasdata</a>. |
1054 |
Metdata takes the same arguments as plasdata, but the specular component is modified by the given material color. |
1055 |
|
1056 |
<p> |
1057 |
|
1058 |
<dt> |
1059 |
<a NAME="Transdata"> |
1060 |
<b>Transdata</b> |
1061 |
</a> |
1062 |
|
1063 |
<dd> |
1064 |
Transdata is like <a HREF="#Plasdata">plasdata</a> but the specification includes transmittance as well as reflectance. |
1065 |
The parameters are as follows. |
1066 |
|
1067 |
<pre> |
1068 |
mod transdata id |
1069 |
3+n+ |
1070 |
func datafile |
1071 |
funcfile x1 x2 .. xn transform |
1072 |
0 |
1073 |
6+ red green blue rspec trans tspec A7 .. |
1074 |
</pre> |
1075 |
|
1076 |
<p> |
1077 |
|
1078 |
<dt> |
1079 |
<a NAME="BSDF"> |
1080 |
<b>BSDF</b> |
1081 |
</a> |
1082 |
|
1083 |
<dd> |
1084 |
The BSDF material type loads an XML (eXtensible Markup Language) |
1085 |
file describing a bidirectional scattering distribution function. |
1086 |
Real arguments to this material may define additional |
1087 |
diffuse components that augment the BSDF data. |
1088 |
String arguments are used to define thickness for proxied |
1089 |
surfaces and the "up" orientation for the material. |
1090 |
|
1091 |
<pre> |
1092 |
mod BSDF id |
1093 |
6+ thick BSDFfile ux uy uz funcfile transform |
1094 |
0 |
1095 |
0|3|6|9 |
1096 |
rfdif gfdif bfdif |
1097 |
rbdif gbdif bbdif |
1098 |
rtdif gtdif btdif |
1099 |
</pre> |
1100 |
|
1101 |
<p> |
1102 |
The first string argument is a "thickness" parameter that may be used |
1103 |
to hide detail geometry being proxied by an aggregate BSDF material. |
1104 |
If a view or shadow ray hits a BSDF proxy with non-zero thickness, |
1105 |
it will pass directly through as if the surface were not there. |
1106 |
Similar to the illum type, this permits direct viewing and |
1107 |
shadow testing of complex geometry. |
1108 |
The BSDF is used when a scattered (indirect) ray hits the surface, |
1109 |
and any transmitted sample rays will be offset by the thickness amount |
1110 |
to avoid the hidden geometry and gather samples from the other side. |
1111 |
In this manner, BSDF surfaces can improve the results for indirect |
1112 |
scattering from complex systems without sacrificing appearance or |
1113 |
shadow accuracy. |
1114 |
If the BSDF has transmission and back-side reflection data, |
1115 |
a parallel BSDF surface may be |
1116 |
placed slightly less than the given thickness away from the front surface |
1117 |
to enclose the complex geometry on both sides. |
1118 |
The sign of the thickness is important, as it indicates |
1119 |
whether the proxied geometry is behind the BSDF |
1120 |
surface (when thickness is positive) or in front (when |
1121 |
thickness is negative). |
1122 |
<p> |
1123 |
The second string argument is the name of the BSDF file, |
1124 |
which is found in the usual auxiliary locations. The |
1125 |
following three string parameters name variables for an |
1126 |
"up" vector, which together with the surface |
1127 |
normal, define the local coordinate system that orients the |
1128 |
BSDF. These variables, along with the thickness, are defined |
1129 |
in a function file given as the next string argument. An |
1130 |
optional transform is used to scale the thickness and |
1131 |
reorient the up vector. |
1132 |
<p> |
1133 |
If no real arguments are given, the BSDF is used by itself |
1134 |
to determine reflection and transmission. If there are at |
1135 |
least 3 real arguments, the first triplet is an additional |
1136 |
diffuse reflectance for the front side. At least 6 real |
1137 |
arguments adds diffuse reflectance to the rear side of the |
1138 |
surface. If there are 9 real arguments, the final triplet |
1139 |
will be taken as an additional diffuse transmittance. All |
1140 |
diffuse components as well as the non-diffuse transmission |
1141 |
are modified by patterns applied to this material. The |
1142 |
non-diffuse reflection from either side are unaffected. |
1143 |
Textures perturb the effective surface normal in the usual |
1144 |
way. |
1145 |
<p> |
1146 |
The surface normal of this type is not altered to face the |
1147 |
incoming ray, so the front and back BSDF reflections may |
1148 |
differ. (Transmission is identical front-to-back by physical |
1149 |
law.) If back visibility is turned off during rendering and |
1150 |
there is no transmission or back-side reflection, only then |
1151 |
the surface will be invisible from behind. Unlike other |
1152 |
data-driven material types, the BSDF type is fully supported |
1153 |
and all parts of the distribution are properly sampled. |
1154 |
<p> |
1155 |
|
1156 |
<dt> |
1157 |
<a NAME="aBSDF"> |
1158 |
<b>aBSDF</b> |
1159 |
</a> |
1160 |
|
1161 |
<dd> |
1162 |
The aBSDF material is identical to the BSDF type with two |
1163 |
important differences. First, proxy geometry is not |
1164 |
supported, so there is no thickness parameter. Second, an |
1165 |
aBSDF is assumed to have some specular through component |
1166 |
(the ’a’ stands for "aperture"), |
1167 |
which is treated specially during the direct calculation |
1168 |
and when viewing the material. Based on the BSDF data, the |
1169 |
coefficient of specular transmission is determined and used |
1170 |
for modifying unscattered shadow and view rays. |
1171 |
|
1172 |
<pre> |
1173 |
mod aBSDF id |
1174 |
5+ BSDFfile ux uy uz funcfile transform |
1175 |
0 |
1176 |
0|3|6|9 |
1177 |
rfdif gfdif bfdif |
1178 |
rbdif gbdif bbdif |
1179 |
rtdif gtdif btdif |
1180 |
</pre> |
1181 |
|
1182 |
<p> |
1183 |
If a material has no specular transmitted component, it is |
1184 |
much better to use the BSDF type with a zero thickness |
1185 |
than to use aBSDF. |
1186 |
<p> |
1187 |
|
1188 |
<dt> |
1189 |
<a NAME="Antimatter"> |
1190 |
<b>Antimatter</b> |
1191 |
</a> |
1192 |
|
1193 |
<dd> |
1194 |
Antimatter is a material that can "subtract" volumes from other volumes. |
1195 |
A ray passing into an antimatter object becomes blind to all the specified modifiers: |
1196 |
|
1197 |
<pre> |
1198 |
mod antimatter id |
1199 |
N mod1 mod2 .. modN |
1200 |
0 |
1201 |
0 |
1202 |
</pre> |
1203 |
|
1204 |
The first modifier will also be used to shade the area leaving the antimatter volume and entering the regular volume. |
1205 |
If mod1 is void, the antimatter volume is completely invisible. |
1206 |
Antimatter does not work properly with the material type <a HREF="#Trans">"trans"</a>, |
1207 |
and multiple antimatter surfaces should be disjoint. |
1208 |
The viewpoint must be outside all volumes concerned for a correct rendering. |
1209 |
|
1210 |
</dl> |
1211 |
|
1212 |
<p> |
1213 |
<hr> |
1214 |
|
1215 |
<h4> |
1216 |
<a NAME="Textures">2.1.3. Textures</a> |
1217 |
</h4> |
1218 |
|
1219 |
A texture is a perturbation of the surface normal, and is given by either a function or data. |
1220 |
|
1221 |
<p> |
1222 |
|
1223 |
<dl> |
1224 |
|
1225 |
<dt> |
1226 |
<a NAME="Texfunc"> |
1227 |
<b>Texfunc</b> |
1228 |
</a> |
1229 |
|
1230 |
<dd> |
1231 |
A texfunc uses an auxiliary function file to specify a procedural texture: |
1232 |
|
1233 |
<pre> |
1234 |
mod texfunc id |
1235 |
4+ xpert ypert zpert funcfile transform |
1236 |
0 |
1237 |
n A1 A2 .. An |
1238 |
</pre> |
1239 |
|
1240 |
<p> |
1241 |
|
1242 |
<dt> |
1243 |
<a NAME="Texdata"> |
1244 |
<b>Texdata</b> |
1245 |
</a> |
1246 |
|
1247 |
<dd> |
1248 |
A texdata texture uses three data files to get the surface normal perturbations. |
1249 |
The variables xfunc, yfunc and zfunc take three arguments each from the interpolated values in xdfname, ydfname and zdfname. |
1250 |
|
1251 |
<pre> |
1252 |
mod texdata id |
1253 |
8+ xfunc yfunc zfunc xdfname ydfname zdfname vfname x0 x1 .. xf |
1254 |
0 |
1255 |
n A1 A2 .. An |
1256 |
</pre> |
1257 |
|
1258 |
</dl> |
1259 |
|
1260 |
<p> |
1261 |
<hr> |
1262 |
|
1263 |
<h4> |
1264 |
<a NAME="Patterns">2.1.4. Patterns</a> |
1265 |
</h4> |
1266 |
|
1267 |
Patterns are used to modify the reflectance of materials. The basic types are given below. |
1268 |
|
1269 |
<p> |
1270 |
|
1271 |
<dl> |
1272 |
|
1273 |
<dt> |
1274 |
<a NAME="Colorfunc"> |
1275 |
<b>Colorfunc</b> |
1276 |
</a> |
1277 |
|
1278 |
<dd> |
1279 |
A colorfunc is a procedurally defined color pattern. It is specified as follows: |
1280 |
|
1281 |
<pre> |
1282 |
mod colorfunc id |
1283 |
4+ red green blue funcfile transform |
1284 |
0 |
1285 |
n A1 A2 .. An |
1286 |
</pre> |
1287 |
|
1288 |
<p> |
1289 |
|
1290 |
<dt> |
1291 |
<a NAME="Brightfunc"> |
1292 |
<b>Brightfunc</b> |
1293 |
</a> |
1294 |
|
1295 |
<dd> |
1296 |
A brightfunc is the same as a colorfunc, except it is monochromatic. |
1297 |
|
1298 |
<pre> |
1299 |
mod brightfunc id |
1300 |
2+ refl funcfile transform |
1301 |
0 |
1302 |
n A1 A2 .. An |
1303 |
</pre> |
1304 |
|
1305 |
<p> |
1306 |
|
1307 |
<dt> |
1308 |
<a NAME="Colordata"> |
1309 |
<b>Colordata</b> |
1310 |
</a> |
1311 |
|
1312 |
<dd> |
1313 |
Colordata uses an interpolated data map to modify a material's color. |
1314 |
The map is n-dimensional, and is stored in three auxiliary files, one for each color. |
1315 |
The coordinates used to look up and interpolate the data are defined in another auxiliary file. |
1316 |
The interpolated data values are modified by functions of one or three variables. |
1317 |
If the functions are of one variable, then they are passed the corresponding color component (red or green or blue). |
1318 |
If the functions are of three variables, then they are passed the original red, green, and blue values as parameters. |
1319 |
|
1320 |
<pre> |
1321 |
mod colordata id |
1322 |
7+n+ |
1323 |
rfunc gfunc bfunc rdatafile gdatafile bdatafile |
1324 |
funcfile x1 x2 .. xn transform |
1325 |
0 |
1326 |
m A1 A2 .. Am |
1327 |
</pre> |
1328 |
|
1329 |
<p> |
1330 |
|
1331 |
<dt> |
1332 |
<a NAME="Brightdata"> |
1333 |
<b>Brightdata</b> |
1334 |
</a> |
1335 |
|
1336 |
<dd> |
1337 |
Brightdata is like colordata, except monochromatic. |
1338 |
|
1339 |
<pre> |
1340 |
mod brightdata id |
1341 |
3+n+ |
1342 |
func datafile |
1343 |
funcfile x1 x2 .. xn transform |
1344 |
0 |
1345 |
m A1 A2 .. Am |
1346 |
</pre> |
1347 |
|
1348 |
<p> |
1349 |
|
1350 |
<dt> |
1351 |
<a NAME="Colorpict"> |
1352 |
<b>Colorpict</b> |
1353 |
</a> |
1354 |
|
1355 |
<dd> |
1356 |
Colorpict is a special case of colordata, where the pattern is a two-dimensional image stored in the RADIANCE picture format. |
1357 |
The dimensions of the image data are determined by the picture such that the smaller dimension is always 1, |
1358 |
and the other is the ratio between the larger and the smaller. |
1359 |
For example, a 500x338 picture would have coordinates (u,v) in the rectangle between (0,0) and (1.48,1). |
1360 |
|
1361 |
<pre> |
1362 |
mod colorpict id |
1363 |
7+ |
1364 |
rfunc gfunc bfunc pictfile |
1365 |
funcfile u v transform |
1366 |
0 |
1367 |
m A1 A2 .. Am |
1368 |
</pre> |
1369 |
|
1370 |
<p> |
1371 |
|
1372 |
<dt> |
1373 |
<a NAME="Colortext"> |
1374 |
<b>Colortext</b> |
1375 |
</a> |
1376 |
|
1377 |
<dd> |
1378 |
Colortext is dichromatic writing in a polygonal font. |
1379 |
The font is defined in an auxiliary file, such as helvet.fnt. |
1380 |
The text itself is also specified in a separate file, or can be part of the material arguments. |
1381 |
The character size, orientation, aspect ratio and slant is determined by right and down motion vectors. |
1382 |
The upper left origin for the text block as well as the foreground and background colors must also be given. |
1383 |
|
1384 |
<pre> |
1385 |
mod colortext id |
1386 |
2 fontfile textfile |
1387 |
0 |
1388 |
15+ |
1389 |
Ox Oy Oz |
1390 |
Rx Ry Rz |
1391 |
Dx Dy Dz |
1392 |
rfore gfore bfore |
1393 |
rback gback bback |
1394 |
[spacing] |
1395 |
</pre> |
1396 |
|
1397 |
or: |
1398 |
|
1399 |
<pre> |
1400 |
mod colortext id |
1401 |
2+N fontfile . This is a line with N words ... |
1402 |
0 |
1403 |
15+ |
1404 |
Ox Oy Oz |
1405 |
Rx Ry Rz |
1406 |
Dx Dy Dz |
1407 |
rfore gfore bfore |
1408 |
rback gback bback |
1409 |
[spacing] |
1410 |
</pre> |
1411 |
|
1412 |
<p> |
1413 |
|
1414 |
<dt> |
1415 |
<a NAME="Brighttext"> |
1416 |
<b>Brighttext</b> |
1417 |
</a> |
1418 |
|
1419 |
<dd> |
1420 |
Brighttext is like colortext, but the writing is monochromatic. |
1421 |
|
1422 |
<pre> |
1423 |
mod brighttext id |
1424 |
2 fontfile textfile |
1425 |
0 |
1426 |
11+ |
1427 |
Ox Oy Oz |
1428 |
Rx Ry Rz |
1429 |
Dx Dy Dz |
1430 |
foreground background |
1431 |
[spacing] |
1432 |
</pre> |
1433 |
|
1434 |
or: |
1435 |
|
1436 |
<pre> |
1437 |
mod brighttext id |
1438 |
2+N fontfile . This is a line with N words ... |
1439 |
0 |
1440 |
11+ |
1441 |
Ox Oy Oz |
1442 |
Rx Ry Rz |
1443 |
Dx Dy Dz |
1444 |
foreground background |
1445 |
[spacing] |
1446 |
</pre> |
1447 |
|
1448 |
<p> |
1449 |
|
1450 |
By default, a uniform spacing algorithm is used that guarantees every character will appear in a precisely determined position. |
1451 |
Unfortunately, such a scheme results in rather unattractive and difficult to read text with most fonts. |
1452 |
The optional spacing value defines the distance between characters for proportional spacing. |
1453 |
A positive value selects a spacing algorithm that preserves right margins and indentation, |
1454 |
but does not provide the ultimate in proportionally spaced text. |
1455 |
A negative value insures that characters are properly spaced, but the placement of words then varies unpredictably. |
1456 |
The choice depends on the relative importance of spacing versus formatting. |
1457 |
When presenting a section of formatted text, a positive spacing value is usually preferred. |
1458 |
A single line of text will often be accompanied by a negative spacing value. |
1459 |
A section of text meant to depict a picture, perhaps using a special purpose font such as hexbit4x1.fnt, calls for uniform spacing. |
1460 |
Reasonable magnitudes for proportional spacing are between 0.1 (for tightly spaced characters) and 0.3 (for wide spacing). |
1461 |
|
1462 |
</dl> |
1463 |
|
1464 |
<p> |
1465 |
<hr> |
1466 |
|
1467 |
<h4> |
1468 |
<a NAME="Mixtures">2.1.5. Mixtures</a> |
1469 |
</h4> |
1470 |
|
1471 |
A mixture is a blend of one or more materials or textures and patterns. |
1472 |
Blended materials should not be light source types or virtual source types. |
1473 |
The basic types are given below. |
1474 |
|
1475 |
<p> |
1476 |
|
1477 |
<dl> |
1478 |
|
1479 |
<dt> |
1480 |
<a NAME="Mixfunc"> |
1481 |
<b>Mixfunc</b> |
1482 |
</a> |
1483 |
|
1484 |
<dd> |
1485 |
A mixfunc mixes two modifiers procedurally. It is specified as follows: |
1486 |
|
1487 |
<pre> |
1488 |
mod mixfunc id |
1489 |
4+ foreground background vname funcfile transform |
1490 |
0 |
1491 |
n A1 A2 .. An |
1492 |
</pre> |
1493 |
|
1494 |
Foreground and background are modifier names that must be |
1495 |
defined earlier in the scene description. |
1496 |
If one of these is a material, then |
1497 |
the modifier of the mixfunc must be "void". |
1498 |
(Either the foreground or background modifier may be "void", |
1499 |
which serves as a form of opacity control when used with a material.) |
1500 |
Vname is the coefficient defined in funcfile that determines the influence of foreground. |
1501 |
The background coefficient is always (1-vname). |
1502 |
|
1503 |
<p> |
1504 |
|
1505 |
<dt> |
1506 |
<a NAME="Mixdata"> |
1507 |
<b>Mixdata</b> |
1508 |
</a> |
1509 |
|
1510 |
<dd> |
1511 |
Mixdata combines two modifiers using an auxiliary data file: |
1512 |
|
1513 |
<pre> |
1514 |
mod mixdata id |
1515 |
5+n+ |
1516 |
foreground background func datafile |
1517 |
funcfile x1 x2 .. xn transform |
1518 |
0 |
1519 |
m A1 A2 .. Am |
1520 |
</pre> |
1521 |
|
1522 |
<dt> |
1523 |
<a NAME="Mixpict"> |
1524 |
<b>Mixpict</b> |
1525 |
</a> |
1526 |
|
1527 |
<dd> |
1528 |
Mixpict combines two modifiers based on a picture: |
1529 |
|
1530 |
<pre> |
1531 |
mod mixpict id |
1532 |
7+ |
1533 |
foreground background func pictfile |
1534 |
funcfile u v transform |
1535 |
0 |
1536 |
m A1 A2 .. Am |
1537 |
</pre> |
1538 |
|
1539 |
<p> |
1540 |
|
1541 |
The mixing coefficient function "func" takes three |
1542 |
arguments, the red, green and blue values |
1543 |
corresponding to the pixel at (u,v). |
1544 |
|
1545 |
<p> |
1546 |
|
1547 |
<dt> |
1548 |
<a NAME="Mixtext"> |
1549 |
<b>Mixtext</b> |
1550 |
</a> |
1551 |
|
1552 |
<dd> |
1553 |
Mixtext uses one modifier for the text foreground, and one for the background: |
1554 |
|
1555 |
<pre> |
1556 |
mod mixtext id |
1557 |
4 foreground background fontfile textfile |
1558 |
0 |
1559 |
9+ |
1560 |
Ox Oy Oz |
1561 |
Rx Ry Rz |
1562 |
Dx Dy Dz |
1563 |
[spacing] |
1564 |
</pre> |
1565 |
|
1566 |
or: |
1567 |
|
1568 |
<pre> |
1569 |
mod mixtext id |
1570 |
4+N |
1571 |
foreground background fontfile . |
1572 |
This is a line with N words ... |
1573 |
0 |
1574 |
9+ |
1575 |
Ox Oy Oz |
1576 |
Rx Ry Rz |
1577 |
Dx Dy Dz |
1578 |
[spacing] |
1579 |
</pre> |
1580 |
|
1581 |
</dl> |
1582 |
|
1583 |
<p> |
1584 |
<hr> |
1585 |
|
1586 |
<h3> |
1587 |
<a NAME="Auxiliary">2.2. Auxiliary Files</a> |
1588 |
</h3> |
1589 |
|
1590 |
Auxiliary files used in <a HREF="#Textures">textures</a> and <a HREF="#Patterns">patterns</a> |
1591 |
are accessed by the programs during image generation. |
1592 |
These files may be located in the working directory, or in a library directory. |
1593 |
The environment variable RAYPATH can be assigned an alternate set of search directories. |
1594 |
Following is a brief description of some common file types. |
1595 |
|
1596 |
<p> |
1597 |
|
1598 |
<h4> |
1599 |
<a NAME="Function">12.2.1. Function Files</a> |
1600 |
</h4> |
1601 |
|
1602 |
A function file contains the definitions of variables, functions and constants used by a primitive. |
1603 |
The transformation that accompanies the file name contains the necessary rotations, translations and scalings |
1604 |
to bring the coordinates of the function file into agreement with the world coordinates. |
1605 |
The transformation specification is the same as for the <a HREF="#Generators">xform</a> command. |
1606 |
An example function file is given below: |
1607 |
|
1608 |
<pre> |
1609 |
{ |
1610 |
This is a comment, enclosed in curly braces. |
1611 |
{Comments can be nested.} |
1612 |
} |
1613 |
{ standard expressions use +,-,*,/,^,(,) } |
1614 |
vname = Ny * func(A1) ; |
1615 |
{ constants are defined with a colon } |
1616 |
const : sqrt(PI/2) ; |
1617 |
{ user-defined functions add to library } |
1618 |
func(x) = 5 + A1*sin(x/3) ; |
1619 |
{ functions may be passed and recursive } |
1620 |
rfunc(f,x) = if(x,f(x),f(-x)*rfunc(f,x+1)) ; |
1621 |
{ constant functions may also be defined } |
1622 |
cfunc(x) : 10*x / sqrt(x) ; |
1623 |
</pre> |
1624 |
|
1625 |
Many variables and functions are already defined by the program, and they are listed in the file rayinit.cal. |
1626 |
The following variables are particularly important: |
1627 |
|
1628 |
<pre> |
1629 |
Dx, Dy, Dz - incident ray direction |
1630 |
Nx, Ny, Nz - surface normal at intersection point |
1631 |
Px, Py, Pz - intersection point |
1632 |
T - distance from start |
1633 |
Ts - single ray (shadow) distance |
1634 |
Rdot - cosine between ray and normal |
1635 |
arg(0) - number of real arguments |
1636 |
arg(i) - i'th real argument |
1637 |
</pre> |
1638 |
|
1639 |
For mesh objects, the local surface coordinates are available: |
1640 |
|
1641 |
<pre> |
1642 |
Lu, Lv - local (u,v) coordinates |
1643 |
</pre> |
1644 |
|
1645 |
For BRDF types, the following variables are defined as well: |
1646 |
|
1647 |
<pre> |
1648 |
NxP, NyP, NzP - perturbed surface normal |
1649 |
RdotP - perturbed dot product |
1650 |
CrP, CgP, CbP - perturbed material color |
1651 |
</pre> |
1652 |
|
1653 |
A unique context is set up for each file so |
1654 |
that the same variable may appear in different |
1655 |
function files without conflict. |
1656 |
The variables listed above and any others defined in |
1657 |
rayinit.cal are available globally. |
1658 |
If no file is needed by a given primitive because all |
1659 |
the required variables are global, |
1660 |
a period (`.') can be given in place of the file name. |
1661 |
It is also possible to give an expression instead |
1662 |
of a straight variable name in a scene file. |
1663 |
Functions (requiring parameters) must be given |
1664 |
as names and not as expressions. |
1665 |
|
1666 |
<p> |
1667 |
Constant expressions are used as an optimization in function files. |
1668 |
They are replaced wherever they occur in an expression by their value. |
1669 |
Constant expressions are evaluated only once, so they must not contain any variables or values that can change, |
1670 |
such as the ray variables Px and Ny or the primitive argument function arg(). |
1671 |
All the math library functions such as sqrt() and cos() have the constant attribute, |
1672 |
so they will be replaced by immediate values whenever they are given constant arguments. |
1673 |
Thus, the subexpression cos(PI*sqrt(2)) is immediately replaced by its value, -.266255342, |
1674 |
and does not cause any additional overhead in the calculation. |
1675 |
|
1676 |
<p> |
1677 |
It is generally a good idea to define constants and variables before they are referred to in a function file. |
1678 |
Although evaluation does not take place until later, the interpreter does variable scoping and |
1679 |
constant subexpression evaluation based on what it has compiled already. |
1680 |
For example, a variable that is defined globally in rayinit.cal |
1681 |
then referenced in the local context of a function file |
1682 |
cannot subsequently be redefined in the same file |
1683 |
because the compiler has already determined the scope of the referenced variable as global. |
1684 |
To avoid such conflicts, one can state the scope of a variable explicitly by |
1685 |
preceding the variable name with a context mark (a back-quote) for a local variable, |
1686 |
or following the name with a context mark for a global variable. |
1687 |
|
1688 |
<p> |
1689 |
|
1690 |
<h4> |
1691 |
<a NAME="Data">2.2.2. Data Files</a> |
1692 |
</h4> |
1693 |
|
1694 |
Data files contain n-dimensional arrays of real numbers used for interpolation. |
1695 |
Typically, definitions in a function file determine how to index and use interpolated data values. |
1696 |
The basic data file format is as follows: |
1697 |
|
1698 |
<pre> |
1699 |
N |
1700 |
beg1 end1 m1 |
1701 |
0 0 m2 x2.1 x2.2 x2.3 x2.4 .. x2.m2 |
1702 |
... |
1703 |
begN endN mN |
1704 |
DATA, later dimensions changing faster. |
1705 |
</pre> |
1706 |
|
1707 |
N is the number of dimensions. |
1708 |
For each dimension, the beginning and ending coordinate values and the dimension size is given. |
1709 |
Alternatively, individual coordinate values can be given when the points are not evenly spaced. |
1710 |
These values must either be increasing or decreasing monotonically. |
1711 |
The data is m1*m2*...*mN real numbers in ASCII form. |
1712 |
Comments may appear anywhere in the file, beginning with a pound |
1713 |
sign ('#') and continuing to the end of line. |
1714 |
|
1715 |
<p> |
1716 |
|
1717 |
<h4> |
1718 |
<a NAME="Font">2.2.3. Font Files</a> |
1719 |
</h4> |
1720 |
|
1721 |
A font file lists the polygons which make up a character set. |
1722 |
Comments may appear anywhere in the file, beginning with a pound |
1723 |
sign ('#') and continuing to the end of line. |
1724 |
All numbers are decimal integers: |
1725 |
|
1726 |
<pre> |
1727 |
code n |
1728 |
x0 y0 |
1729 |
x1 y1 |
1730 |
... |
1731 |
xn yn |
1732 |
... |
1733 |
</pre> |
1734 |
|
1735 |
The ASCII codes can appear in any order. N is the number of vertices, and the last is automatically connected to the first. |
1736 |
Separate polygonal sections are joined by coincident sides. |
1737 |
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). |
1738 |
|
1739 |
<p> |
1740 |
|
1741 |
<hr> |
1742 |
|
1743 |
<h3> |
1744 |
<a NAME="Generators">2.3. Generators</a> |
1745 |
</h3> |
1746 |
|
1747 |
A generator is any program that produces a scene description as its output. |
1748 |
They usually appear as commands in a scene description file. |
1749 |
An example of a simple generator is genbox. |
1750 |
|
1751 |
<ul> |
1752 |
|
1753 |
<li> |
1754 |
<a NAME="Genbox" HREF="../man_html/genbox.1.html"> |
1755 |
<b>Genbox</b> |
1756 |
</a> |
1757 |
takes the arguments of width, height and depth to produce a parallelepiped description. |
1758 |
<li> |
1759 |
<a NAME="Genprism" HREF="../man_html/genprism.1.html"> |
1760 |
<b>Genprism</b> |
1761 |
</a> |
1762 |
takes a list of 2-dimensional coordinates and extrudes them along a vector to |
1763 |
produce a 3-dimensional prism. |
1764 |
<li> |
1765 |
<a NAME="Genrev" HREF="../man_html/genrev.1.html"> |
1766 |
<b>Genrev</b> |
1767 |
</a> |
1768 |
is a more sophisticated generator that produces an object of rotation from parametric functions for radius and axis position. |
1769 |
<li> |
1770 |
<a NAME="Gensurf" HREF="../man_html/gensurf.1.html"> |
1771 |
<b>Gensurf</b> |
1772 |
</a> |
1773 |
tessellates a surface defined by the parametric functions x(s,t), y(s,t), and z(s,t). |
1774 |
<li> |
1775 |
<a NAME="Genworm" HREF="../man_html/genworm.1.html"> |
1776 |
<b>Genworm</b> |
1777 |
</a> |
1778 |
links cylinders and spheres along a curve. |
1779 |
<li> |
1780 |
<a NAME="Gensky" HREF="../man_html/gensky.1.html"> |
1781 |
<b>Gensky</b> |
1782 |
</a> |
1783 |
produces a sun and sky distribution corresponding to a given time and date. |
1784 |
<li> |
1785 |
<a NAME="Xform" HREF="../man_html/xform.1.html"> |
1786 |
<b>Xform</b> |
1787 |
</a> |
1788 |
is a program that transforms a scene description from one coordinate space to another. |
1789 |
Xform does rotation, translation, scaling, and mirroring. |
1790 |
|
1791 |
</ul> |
1792 |
|
1793 |
<p> |
1794 |
<hr> |
1795 |
|
1796 |
<h2> |
1797 |
<a NAME="Image">3. Image Generation</a> |
1798 |
</h2> |
1799 |
|
1800 |
Once the scene has been described in three-dimensions, it is possible to generate a two-dimensional image from a given perspective. |
1801 |
|
1802 |
<p> |
1803 |
The image generating programs use an <a NAME="octree"><b>octree</b></a> to efficiently trace rays through the scene. |
1804 |
An octree subdivides space into nested octants which contain sets of surfaces. |
1805 |
In RADIANCE, an octree is created from a scene description by <a NAME="oconv1" HREF="../man_html/oconv.1.html"><b>oconv</b></a>. |
1806 |
The details of this process are not important, but the octree will serve as input to the ray-tracing programs and |
1807 |
directs the use of a scene description. |
1808 |
<ul> |
1809 |
<li> |
1810 |
<a NAME="rvu" HREF="../man_html/rvu.1.html"><b>Rview</b></a> is ray-tracing program for viewing a scene interactively. |
1811 |
When the user specifies a new perspective, rvu quickly displays a rough image on the terminal, |
1812 |
then progressively increases the resolution as the user looks on. |
1813 |
He can select a particular section of the image to improve, or move to a different view and start over. |
1814 |
This mode of interaction is useful for debugging scenes as well as determining the best view for a final image. |
1815 |
|
1816 |
<li> |
1817 |
<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. |
1818 |
This program features adaptive sampling, crash recovery and progress reporting, all of which are important for time-consuming images. |
1819 |
</ul> |
1820 |
<p> |
1821 |
A number of <a NAME="filters"><b>filters</b></a> are available for manipulating picture files: |
1822 |
<ul> |
1823 |
<li> <a HREF="../man_html/pfilt.1.html"><b>Pfilt</b></a> |
1824 |
sets the exposure and performs antialiasing. |
1825 |
<li> <a HREF="../man_html/pcompos.1.html"><b>Pcompos</b></a> |
1826 |
composites (cuts and pastes) pictures. |
1827 |
<li> <a HREF="../man_html/pcomb.1.html"><b>Pcomb</b></a> |
1828 |
performs arbitrary math on one or more pictures. |
1829 |
<li> <a HREF="../man_html/pcond.1.html"><b>Pcond</b></a> |
1830 |
conditions a picture for a specific display device. |
1831 |
<li> <a HREF="../man_html/protate.1.html"><b>Protate</b></a> |
1832 |
rotates a picture 90 degrees clockwise. |
1833 |
<li> <a HREF="../man_html/pflip.1.html"><b>Pflip</b></a> |
1834 |
flips a picture horizontally, vertically, or both |
1835 |
(180 degree rotation). |
1836 |
<li> <a HREF="../man_html/pvalue.1.html"><b>Pvalue</b></a> |
1837 |
converts a picture to and from simpler formats. |
1838 |
</ul> |
1839 |
|
1840 |
<p> |
1841 |
Pictures may be displayed directly under X11 using the program |
1842 |
<a HREF="../man_html/ximage.1.html">ximage</a>, |
1843 |
or converted a standard image format using one of the following |
1844 |
<b>translators</b>: |
1845 |
<ul> |
1846 |
<li> <a HREF="../man_html/ra_bmp.1.html"><b>Ra_bmp</b> |
1847 |
converts to and from BMP image format. |
1848 |
<li> <a HREF="../man_html/ra_ppm.1.html"><b>Ra_ppm</b></a> |
1849 |
converts to and from Poskanzer Portable Pixmap formats. |
1850 |
<li> <a HREF="../man_html/ra_ps.1.html"><b>Ra_ps</b></a> |
1851 |
converts to PostScript color and greyscale formats. |
1852 |
<li> <a HREF="../man_html/ra_rgbe.1.html"><b>Ra_rgbe</b></a> |
1853 |
converts to and from Radiance uncompressed picture format. |
1854 |
<li> <a HREF="../man_html/ra_t16.1.html"><b>Ra_t16</b></a> |
1855 |
converts to and from Targa 16 and 24-bit image formats. |
1856 |
<li> <a HREF="../man_html/ra_t8.1.html"><b>Ra_t8</b></a> |
1857 |
converts to and from Targa 8-bit image format. |
1858 |
<li> <a HREF="../man_html/ra_tiff.1.html"><b>Ra_tiff</b></a> |
1859 |
converts to and from TIFF. |
1860 |
<li> <a HREF="../man_html/ra_xyze.1.html"><b>Ra_xyze</b></a> |
1861 |
converts to and from Radiance CIE picture format. |
1862 |
</ul> |
1863 |
|
1864 |
<p> |
1865 |
|
1866 |
<hr> |
1867 |
|
1868 |
<h2> |
1869 |
<a NAME="License">4. License</a> |
1870 |
</h2> |
1871 |
|
1872 |
<pre> |
1873 |
The Radiance Software License, Version 1.0 |
1874 |
|
1875 |
Copyright (c) 1990 - 2014 The Regents of the University of California, |
1876 |
through Lawrence Berkeley National Laboratory. All rights reserved. |
1877 |
|
1878 |
Redistribution and use in source and binary forms, with or without |
1879 |
modification, are permitted provided that the following conditions |
1880 |
are met: |
1881 |
|
1882 |
1. Redistributions of source code must retain the above copyright |
1883 |
notice, this list of conditions and the following disclaimer. |
1884 |
|
1885 |
2. Redistributions in binary form must reproduce the above copyright |
1886 |
notice, this list of conditions and the following disclaimer in |
1887 |
the documentation and/or other materials provided with the |
1888 |
distribution. |
1889 |
|
1890 |
3. The end-user documentation included with the redistribution, |
1891 |
if any, must include the following acknowledgment: |
1892 |
"This product includes Radiance software |
1893 |
(<a HREF="http://radsite.lbl.gov/">http://radsite.lbl.gov/</a>) |
1894 |
developed by the Lawrence Berkeley National Laboratory |
1895 |
(<a HREF="http://www.lbl.gov/">http://www.lbl.gov/</a>)." |
1896 |
Alternately, this acknowledgment may appear in the software itself, |
1897 |
if and wherever such third-party acknowledgments normally appear. |
1898 |
|
1899 |
4. The names "Radiance," "Lawrence Berkeley National Laboratory" |
1900 |
and "The Regents of the University of California" must |
1901 |
not be used to endorse or promote products derived from this |
1902 |
software without prior written permission. For written |
1903 |
permission, please contact [email protected]. |
1904 |
|
1905 |
5. Products derived from this software may not be called "Radiance", |
1906 |
nor may "Radiance" appear in their name, without prior written |
1907 |
permission of Lawrence Berkeley National Laboratory. |
1908 |
|
1909 |
THIS SOFTWARE IS PROVIDED ``AS IS" AND ANY EXPRESSED OR IMPLIED |
1910 |
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES |
1911 |
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE |
1912 |
DISCLAIMED. IN NO EVENT SHALL Lawrence Berkeley National Laboratory OR |
1913 |
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, |
1914 |
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT |
1915 |
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF |
1916 |
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND |
1917 |
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, |
1918 |
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT |
1919 |
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF |
1920 |
SUCH DAMAGE. |
1921 |
</pre> |
1922 |
|
1923 |
<hr> |
1924 |
|
1925 |
<h2> |
1926 |
<a NAME="Ack">5. Acknowledgements</a> |
1927 |
</h2> |
1928 |
|
1929 |
This work was supported by the Assistant Secretary of Conservation and Renewable Energy, |
1930 |
Office of Building Energy Research and Development, |
1931 |
Buildings Equipment Division of the U.S. Department of Energy under Contract No. DE-AC03-76SF00098. |
1932 |
|
1933 |
<p> |
1934 |
Additional work was sponsored by the Swiss federal government |
1935 |
under the Swiss LUMEN Project and was carried out in the |
1936 |
Laboratoire d'Energie Solaire (LESO Group) at the |
1937 |
Ecole Polytechnique Federale de Lausanne (EPFL University) in Lausanne, Switzerland. |
1938 |
|
1939 |
<p> |
1940 |
|
1941 |
<hr> |
1942 |
|
1943 |
<h2> |
1944 |
<a NAME="Ref">6.</a> References |
1945 |
</h2> |
1946 |
<p> |
1947 |
<ul> |
1948 |
<li>Wang, Taoning, Gregory Ward, Eleanor Lee, |
1949 |
"<a href="https://authors.elsevier.com/a/1XQ0a1M7zGwT7v">Efficient |
1950 |
modeling of optically-complex, non-coplanar exterior shading: |
1951 |
Validation of matrix algebraic methods</a>" |
1952 |
<em>Energy & Buildings</em>, vol. 174, pp. 464-83, Sept. 2018. |
1953 |
<li>Lee, Eleanor S., David Geisler-Moroder, Gregory Ward, |
1954 |
"<a href="https://eta.lbl.gov/sites/default/files/publications/solar_energy.pdf">Modeling |
1955 |
the direct sun component in buildings using matrix |
1956 |
algebraic approaches: Methods and |
1957 |
validation</a>," <em>Solar Energy</em>, |
1958 |
vol. 160, 15 January 2018, pp 380-395. |
1959 |
<li>Narain, Rahul, Rachel A. Albert, Abdullah Bulbul, |
1960 |
Gregory J. Ward, Marty Banks, James F. O'Brien, |
1961 |
"<a href="http://graphics.berkeley.edu/papers/Narain-OPI-2015-08/index.html">Optimal |
1962 |
Presentation of Imagery with Focus |
1963 |
Cues on Multi-Plane Displays</a>," |
1964 |
<em>SIGGRAPH 2015</em>. |
1965 |
<li>Ward, Greg, Murat Kurt, and Nicolas Bonneel, |
1966 |
"<a href="papers/WMAM14_Tensor_Tree_Representation.pdf">Reducing |
1967 |
Anisotropic BSDF Measurement to Common Practice</a>," |
1968 |
<em>Workshop on Material Appearance Modeling</em>, 2014. |
1969 |
<li>Banks, Martin, Abdullah Bulbul, Rachel Albert, Rahul Narain, |
1970 |
James F. O'Brien, Gregory Ward, |
1971 |
"<a href="http://graphics.berkeley.edu/papers/Banks-TPO-2014-05/index.html">The |
1972 |
Perception of Surface Material from Disparity and Focus Cues</a>," |
1973 |
<em>VSS 2014</em>. |
1974 |
<li>McNeil, A., C.J. Jonsson, D. Appelfeld, G. Ward, E.S. Lee, |
1975 |
"<a href="http://gaia.lbl.gov/btech/papers/4414.pdf"> |
1976 |
A validation of a ray-tracing tool used to generate |
1977 |
bi-directional scattering distribution functions for |
1978 |
complex fenestration systems</a>," |
1979 |
<em>Solar Energy</em>, 98, 404-14, |
1980 |
November 2013. |
1981 |
<li>Ward, G., R. Mistrick, E.S. Lee, A. McNeil, J. Jonsson, |
1982 |
"<a href="http://gaia.lbl.gov/btech/papers/4414.pdf">Simulating |
1983 |
the Daylight Performance of Complex Fenestration Systems |
1984 |
Using Bidirectional Scattering Distribution Functions within |
1985 |
Radiance</a>," |
1986 |
<em>Leukos</em>, 7(4) |
1987 |
April 2011. |
1988 |
<li>Cater, Kirsten, Alan Chalmers, Greg Ward, |
1989 |
"<a href="http://www.anyhere.com/gward/papers/egsr2003.pdf">Detail to Attention: |
1990 |
Exploiting Visual Tasks for Selective Rendering</a>," |
1991 |
<em>Eurographics Symposium |
1992 |
on Rendering 2003</em>, June 2003. |
1993 |
<li>Ward, Greg, Elena Eydelberg-Vileshin, |
1994 |
"<a HREF="http://www.anyhere.com/gward/papers/egwr02/index.html">Picture Perfect RGB |
1995 |
Rendering Using Spectral Prefiltering and Sharp Color Primaries</a>," |
1996 |
Thirteenth Eurographics Workshop on Rendering (2002), |
1997 |
P. Debevec and S. Gibson (Editors), June 2002. |
1998 |
<li>Ward, Gregory, |
1999 |
"<a HREF="http://www.anyhere.com/gward/papers/cic01.pdf">High Dynamic Range Imaging</a>," |
2000 |
Proceedings of the Ninth Color Imaging Conference, November 2001. |
2001 |
<li>Ward, Gregory and Maryann Simmons, |
2002 |
"<a HREF="http://www.anyhere.com/gward/papers/tog99.pdf"> |
2003 |
The Holodeck Ray Cache: An Interactive Rendering System for Global Illumination in Nondiffuse |
2004 |
Environments</a>," ACM Transactions on Graphics, 18(4):361-98, October 1999. |
2005 |
<li>Larson, G.W., "<a HREF="http://www.anyhere.com/gward/papers/ewp98.pdf">The Holodeck: A Parallel |
2006 |
Ray-caching Rendering System</a>," Proceedings of the Second |
2007 |
Eurographics Workshop on Parallel Graphics and Visualisation, |
2008 |
September 1998. |
2009 |
<li>Larson, G.W. and R.A. Shakespeare, |
2010 |
<a HREF="http://radsite.lbl.gov/radiance/book/index.html"><em>Rendering with Radiance: |
2011 |
the Art and Science of Lighting Visualization</em></a>, |
2012 |
Morgan Kaufmann Publishers, 1998. |
2013 |
<li>Larson, G.W., H. Rushmeier, C. Piatko, |
2014 |
"<a HREF="http://radsite.lbl.gov/radiance/papers/lbnl39882/tonemap.pdf">A Visibility |
2015 |
Matching Tone Reproduction Operator for |
2016 |
High Dynamic Range Scenes</a>," LBNL Technical Report 39882, |
2017 |
January 1997. |
2018 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/erw95.1/paper.html">Making |
2019 |
Global Illumination User-Friendly</a>," Sixth |
2020 |
Eurographics Workshop on Rendering, Springer-Verlag, |
2021 |
Dublin, Ireland, June 1995.</li> |
2022 |
<li>Rushmeier, H., G. Ward, C. Piatko, P. Sanders, B. Rust, |
2023 |
"<a HREF="http://radsite.lbl.gov/mgf/compare.html"> |
2024 |
Comparing Real and Synthetic Images: Some Ideas about |
2025 |
Metrics</a>," Sixth Eurographics Workshop on Rendering, |
2026 |
Springer-Verlag, Dublin, Ireland, June 1995.</li> |
2027 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/sg94.1/paper.html">The RADIANCE |
2028 |
Lighting Simulation and Rendering System</a>," <em>Computer |
2029 |
Graphics</em>, July 1994.</li> |
2030 |
<li>Rushmeier, H., G. Ward, "<a HREF="http://radsite.lbl.gov/radiance/papers/sg94.2/energy.html">Energy |
2031 |
Preserving Non-Linear Filters</a>," <em>Computer |
2032 |
Graphics</em>, July 1994.</li> |
2033 |
<li>Ward, G., "A Contrast-Based Scalefactor for Luminance |
2034 |
Display," <em>Graphics Gems IV</em>, Edited by Paul Heckbert, |
2035 |
Academic Press 1994.</li> |
2036 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/sg92/paper.html">Measuring and |
2037 |
Modeling Anisotropic Reflection</a>," <em>Computer |
2038 |
Graphics</em>, Vol. 26, No. 2, July 1992. </li> |
2039 |
<li>Ward, G., P. Heckbert, "<a HREF="http://radsite.lbl.gov/radiance/papers/erw92/paper.html">Irradiance |
2040 |
Gradients</a>," Third Annual Eurographics Workshop on |
2041 |
Rendering, Springer-Verlag, May 1992. </li> |
2042 |
<li>Ward, G., "<a HREF="http://radsite.lbl.gov/radiance/papers/erw91/erw91.html">Adaptive Shadow |
2043 |
Testing for Ray Tracing</a>" Photorealistic Rendering in |
2044 |
Computer Graphics, proceedings of 1991 Eurographics |
2045 |
Rendering Workshop, edited by P. Brunet and F.W. Jansen, |
2046 |
Springer-Verlag. </li> |
2047 |
<li>Ward, G., "Visualization," <em>Lighting Design and |
2048 |
Application</em>, Vol. 20, No. 6, June 1990. </li> |
2049 |
<li>Ward, G., F. Rubinstein, R. Clear, "<a HREF="http://radsite.lbl.gov/radiance/papers/sg88/paper.html">A Ray Tracing Solution for |
2050 |
Diffuse Interreflection</a>," <em>Computer Graphics</em>, |
2051 |
Vol. 22, No. 4, August 1988. </li> |
2052 |
<li>Ward, G., F. Rubinstein, "A New Technique for Computer |
2053 |
Simulation of Illuminated Spaces," <em>Journal of the |
2054 |
Illuminating Engineering Society</em>, Vol. 17, No. 1, |
2055 |
Winter 1988. </li> |
2056 |
</ul> |
2057 |
<p> |
2058 |
See the <a HREF="index.html">RADIANCE Reference Materials</a> page |
2059 |
for additional information. |
2060 |
<hr> |
2061 |
|
2062 |
<a NAME="Index"><h2>7. Types Index</h2></a> |
2063 |
|
2064 |
<pre> |
2065 |
<h4> |
2066 |
SURFACES MATERIALS TEXTURES PATTERNS MIXTURES</h4> |
2067 |
<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> |
2068 |
<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> |
2069 |
<a HREF="#Bubble">Bubble</a> <a HREF="#Glow">Glow</a> <a HREF="#Colordata">Colordata</a> <a HREF="#Mixtext">Mixtext</a> |
2070 |
<a HREF="#Polygon">Polygon</a> <a HREF="#Spotlight">Spotlight</a> <a HREF="#Brightdata">Brightdata</a> |
2071 |
<a HREF="#Cone">Cone</a> <a HREF="#Mirror">Mirror</a> <a HREF="#Colorpict">Colorpict</a> |
2072 |
<a HREF="#Cup">Cup</a> <a HREF="#Prism1">Prism1</a> <a HREF="#Colortext">Colortext</a> |
2073 |
<a HREF="#Cylinder">Cylinder</a> <a HREF="#Prism2">Prism2</a> <a HREF="#Brighttext">Brighttext</a> |
2074 |
<a HREF="#Tube">Tube</a> <a HREF="#Plastic">Plastic</a> |
2075 |
<a HREF="#Ring">Ring</a> <a HREF="#Metal">Metal</a> |
2076 |
<a HREF="#Instance">Instance</a> <a HREF="#Trans">Trans</a> |
2077 |
<a HREF="#Mesh">Mesh</a> <a HREF="#Plastic2">Plastic2</a> |
2078 |
<a HREF="#Metal2">Metal2</a> |
2079 |
<a HREF="#Trans2">Trans2</a> |
2080 |
<a HREF="#Mist">Mist</a> |
2081 |
<a HREF="#Dielectric">Dielectric</a> |
2082 |
<a HREF="#Interface">Interface</a> |
2083 |
<a HREF="#Glass">Glass</a> |
2084 |
<a HREF="#Plasfunc">Plasfunc</a> |
2085 |
<a HREF="#Metfunc">Metfunc</a> |
2086 |
<a HREF="#Transfunc">Transfunc</a> |
2087 |
<a HREF="#BRTDfunc">BRTDfunc</a> |
2088 |
<a HREF="#Plasdata">Plasdata</a> |
2089 |
<a HREF="#Metdata">Metdata</a> |
2090 |
<a HREF="#Transdata">Transdata</a> |
2091 |
<a HREF="#BSDF">BSDF</a> |
2092 |
<a HREF="#Antimatter">Antimatter</a> |
2093 |
|
2094 |
</pre> |
2095 |
|
2096 |
<p> |
2097 |
|
2098 |
|
2099 |
<hr> |
2100 |
<center>Last Update: October 22, 1997</center> |
2101 |
</body> |
2102 |
</html> |
2103 |
|