1 |
greg |
1.2 |
.\" RCSid $Id$ |
2 |
greg |
1.1 |
.EQ |
3 |
|
|
delim @@ |
4 |
|
|
.EN |
5 |
|
|
.SH 1 |
6 |
|
|
\f[BI]Radiance\f[B] File Formats |
7 |
|
|
.pdfhref O 1 "Radiance File Formats" |
8 |
|
|
.pdfhref M "radiance-file-formats" |
9 |
|
|
.LP |
10 |
|
|
This chapter discusses the standard file formats specific to |
11 |
|
|
\f[I]Radiance\f[R], and gives their internal structure, with pointers to |
12 |
|
|
routines for reading and writing them. |
13 |
|
|
The following file formats (listed with their conventional suffixes) are |
14 |
|
|
covered: |
15 |
|
|
.IP "\f[B]Scene Description (.rad suffix)\f[R]" 3 |
16 |
|
|
This is the main input file type, describing materials and geometry for |
17 |
|
|
the rendering programs, and must be compiled into an octree by oconv |
18 |
|
|
prior to ray-tracing. |
19 |
|
|
It is an ASCII text format, and is often translated from a CAD |
20 |
|
|
description, but may be created or edited by a text editor as well. |
21 |
|
|
.RS 3 |
22 |
|
|
.RE |
23 |
|
|
.IP "\f[B]Function File (.cal suffix)\f[R]" 3 |
24 |
|
|
Also a text format, these files describe mathematical patterns, |
25 |
|
|
textures, and surface shapes. |
26 |
|
|
In the case of patterns and textures, the functions serve as input |
27 |
|
|
directly to the rendering programs. |
28 |
|
|
In the case of surfaces, the functions serve as input to one of the |
29 |
|
|
generator programs, \f[B]gensurf\f[R], \f[B]genrev\f[R] or |
30 |
|
|
\f[B]genworm\f[R]. |
31 |
|
|
Additionally, \f[B]pcomb\f[R] may be used to perform math on |
32 |
|
|
\f[I]Radiance\f[R] pictures and the \f[B]rcalc\f[R] utility may be used |
33 |
|
|
in creative ways to manipulate data for scene generation and data |
34 |
|
|
analysis. |
35 |
|
|
.RS 3 |
36 |
|
|
.RE |
37 |
|
|
.IP "\f[B]Data File (.dat suffix)\f[R]" 3 |
38 |
|
|
Another ASCII format, data files are used directly by the rendering |
39 |
|
|
programs to interpolate values for luminaire photometry, among other |
40 |
|
|
things. |
41 |
|
|
.RS 3 |
42 |
|
|
.RE |
43 |
|
|
.IP "\f[B]Font File (.fnt suffix)\f[R]" 3 |
44 |
|
|
A simple, polygonal font representation for rendering text patterns. |
45 |
|
|
This ASCII format describes each character \[lq]glyph\[rq] as a sequence |
46 |
|
|
of vertices in rectangular, integer coordinates ranging from 0 to 255. |
47 |
|
|
.RS 3 |
48 |
|
|
.RE |
49 |
|
|
.IP "\f[B]Octree (.oct suffix)\f[R]" 3 |
50 |
|
|
A binary data structure computed from one or more scene description |
51 |
|
|
files by the oconv program. |
52 |
|
|
It may contain frozen scene data in binary form, or merely references to |
53 |
|
|
the original scene files. |
54 |
|
|
.RS 3 |
55 |
|
|
.RE |
56 |
|
|
.IP "\f[B]Picture (.hdr suffix)\f[R]" 3 |
57 |
|
|
A binary image file containing calibrated, real radiance values at each |
58 |
|
|
pixel. |
59 |
|
|
\f[I]Radiance\f[R] pictures may be displayed, analyzed, and converted to |
60 |
|
|
other image formats. |
61 |
|
|
.RS 3 |
62 |
|
|
.RE |
63 |
|
|
.IP "\f[B]Z-buffer (.zbf suffix)\f[R]" 3 |
64 |
|
|
A binary file with the distances to each pixel in a corresponding |
65 |
|
|
picture. |
66 |
|
|
.RS 3 |
67 |
|
|
.RE |
68 |
|
|
.IP "\f[B]Ambient File (.amb suffix)\f[R]" 3 |
69 |
|
|
A binary file used to store diffuse interreflection values, which are |
70 |
|
|
shared between cooperating rendering processes running sequentially or |
71 |
|
|
in parallel. |
72 |
|
|
Since these values are view-independent, sharing this information across |
73 |
|
|
multiple runs is highly economical. |
74 |
|
|
.RS 3 |
75 |
|
|
.RE |
76 |
|
|
.LP |
77 |
|
|
We will discuss each of these formats in turn, giving examples and |
78 |
|
|
pointers to routines in the source code for reading and writing them, |
79 |
|
|
and the programs that use them. |
80 |
|
|
In general, the ASCII text formats have no standard routines for writing |
81 |
|
|
them, since they generally originate outside of \f[I]Radiance\f[R] or |
82 |
|
|
are created with simple \f[I]printf(3)\f[R] statements. |
83 |
|
|
Most binary file formats are machine and system independent, meaning |
84 |
|
|
they can be moved safely from one place to another and |
85 |
|
|
\f[I]Radiance\f[R] will still understand them (provided no unintentional |
86 |
|
|
character translation takes place along the way)\**. |
87 |
|
|
.FS |
88 |
|
|
The single exception to this rule is the Z-buffer file, whose contents |
89 |
|
|
are dictated by the floating point representation and byte order of the |
90 |
|
|
originating machine. |
91 |
|
|
This choice was made for economic reasons, and is rarely a problem. |
92 |
|
|
.FE |
93 |
|
|
Most binary files also include a standard ASCII header at their |
94 |
|
|
beginning that may be read by the \f[B]getinfo\f[R] program. |
95 |
|
|
This offers a convenient method for identifying the file contents when |
96 |
|
|
the file name is ambiguous. |
97 |
|
|
.SH 2 |
98 |
|
|
Scene Description Format (.rad suffix) |
99 |
|
|
.pdfhref O 2 "Scene Description Format \(.rad suffix\)" |
100 |
|
|
.pdfhref M "scene-description-format-.rad-suffix" |
101 |
|
|
.LP |
102 |
|
|
The semantics of the \f[I]Radiance\f[R] scene description format are |
103 |
|
|
covered in the Reference Manual. |
104 |
|
|
We will therefore focus on the file syntax and structure, which are |
105 |
|
|
simple and straightforward. |
106 |
|
|
In fact, some would say that the \f[I]Radiance\f[R] scene description |
107 |
|
|
format is brain-dead, in the sense that it offers few language amenities |
108 |
|
|
and requires the awkward counting of string and real arguments (not to |
109 |
|
|
mention those non-existent integer arguments). |
110 |
|
|
We have little to offer in its defense. |
111 |
|
|
.PP |
112 |
|
|
The truth is, the scene format was designed to grow with |
113 |
|
|
\f[I]Radiance\f[R], and we wanted to keep it as simple as possible so as |
114 |
|
|
to encourage others to write translators to and from it. |
115 |
|
|
Specifically, we wanted to be able to read files using the |
116 |
|
|
\f[I]scanf(3)\f[R] library function and write files using |
117 |
|
|
\f[I]printf(3)\f[R]. |
118 |
|
|
Furthermore, we wanted everyone\[cq]s parsers to be stable over time, |
119 |
|
|
which meant no primitive-specific syntax. |
120 |
|
|
We also decided that a flat file structure was most practical, since |
121 |
|
|
hierarchies are typically lost on the first translation, and sufficient |
122 |
|
|
structure could be provided by the file system itself. |
123 |
|
|
Since we did not intend text editing to be the primary input method, we |
124 |
|
|
felt the effects of these programming decisions on the human readability |
125 |
|
|
and writability of the format were less important. |
126 |
|
|
.PP |
127 |
|
|
Even so, the format is relatively easy to read and write once you get |
128 |
|
|
used to it, and with the \f[I]Radiance\f[R] generator programs and |
129 |
|
|
in-line command expansion, the text editor becomes a powerful modeling |
130 |
|
|
tool in the hands of an experienced user. |
131 |
|
|
Together with the need for editing material descriptions, our assumption |
132 |
|
|
that users would rarely edit these files turned out to be mistaken. |
133 |
|
|
Consequently, it is a good idea for all users to familiarize themselves |
134 |
|
|
with the scene description format, awkward or not. |
135 |
|
|
.SH 3 |
136 |
|
|
Basic File Structure |
137 |
|
|
.pdfhref O 3 "Basic File Structure" |
138 |
|
|
.pdfhref M "basic-file-structure" |
139 |
|
|
.LP |
140 |
|
|
There are four statement types in a scene description file: comments, |
141 |
|
|
commands, primitives and aliases. |
142 |
|
|
These may be interspersed in the file, and the only structural |
143 |
|
|
requirement is that modifiers precede the primitives they modify. |
144 |
|
|
.SH 4 |
145 |
|
|
Comments |
146 |
|
|
.pdfhref O 4 "Comments" |
147 |
|
|
.pdfhref M "comments" |
148 |
|
|
.LP |
149 |
|
|
The simplest statement type is a comment statement begins with a pound |
150 |
|
|
sign (`#') and continues to the end of line: |
151 |
|
|
.IP |
152 |
|
|
.nf |
153 |
|
|
\f[C] |
154 |
|
|
# This is a comment. |
155 |
|
|
\f[] |
156 |
|
|
.fi |
157 |
|
|
.SH 4 |
158 |
|
|
Commands |
159 |
|
|
.pdfhref O 4 "Commands" |
160 |
|
|
.pdfhref M "commands" |
161 |
|
|
.LP |
162 |
|
|
An in-line command, which begins with an exclamation mark (`!') and |
163 |
|
|
continues to the end of line: |
164 |
|
|
.IP |
165 |
|
|
.nf |
166 |
|
|
\f[C] |
167 |
|
|
!xform -n chair1 -t 10 5 8 chair.rad |
168 |
|
|
\f[] |
169 |
|
|
.fi |
170 |
|
|
.LP |
171 |
|
|
The command is executed during file parsing, and its output is read as |
172 |
|
|
more input. |
173 |
|
|
Long commands may be continued on multiple lines by escaping the newline |
174 |
|
|
character with a backslash (`\[rs]'): |
175 |
|
|
.IP |
176 |
|
|
.nf |
177 |
|
|
\f[C] |
178 |
|
|
!gensurf marble sink \[aq]15.5+x(theta(s),phi(t))\[aq] \[rs] |
179 |
|
|
\[aq]10.5+y(theta(s),phi(t))\[aq] \[rs] |
180 |
|
|
\[aq]30.75+z(theta(s),phi(t))\[aq] \[rs] |
181 |
|
|
8 29 -f basin.cal -s |
182 |
|
|
\f[] |
183 |
|
|
.fi |
184 |
|
|
.LP |
185 |
|
|
Since the command is executed by the shell, pipes and other facilities |
186 |
|
|
are available as well. |
187 |
|
|
The following command creates a counter with a precisely cut hole for |
188 |
|
|
the sink basin just given: |
189 |
|
|
.IP |
190 |
|
|
.nf |
191 |
|
|
\f[C] |
192 |
|
|
!( echo marble polygon sink_top 0 0 108 31 \[rs] |
193 |
|
|
10.5 30.75 31 22 30.75 0 22 30.75 0 0 \[rs] |
194 |
|
|
30.75 31 0 30.75 31 10.5 30.75 ; \[rs] |
195 |
|
|
cnt 30 | rcalc \[rs] |
196 |
|
|
-e \[aq]$1=15.5+x(theta(0),phi(1-$1/29))\[aq] \[rs] |
197 |
|
|
-e \[aq]$2=10.5+y(theta(0),phi(1-$1/29))\[aq] \[rs] |
198 |
|
|
-e \[aq]$3=30.75\[aq] -f basin.cal ) |
199 |
|
|
\f[] |
200 |
|
|
.fi |
201 |
|
|
.LP |
202 |
|
|
Note in the above example that two commands are executed in sequence. |
203 |
|
|
The first creates the counter perimeter, and the second cuts the hole. |
204 |
|
|
The two commands are enclosed in parentheses, so if a final |
205 |
|
|
transformation is added by \f[B]xform\f[R] with the \f[B]-c\f[R] option, |
206 |
|
|
it will be applied to both commands, not just the last one. |
207 |
|
|
.SH 4 |
208 |
|
|
Primitives |
209 |
|
|
.pdfhref O 4 "Primitives" |
210 |
|
|
.pdfhref M "primitives" |
211 |
|
|
.LP |
212 |
|
|
A primitive can be thought of as an indivisible unit of scene |
213 |
|
|
information. |
214 |
|
|
It can be a surface, material, pattern, texture or mixture. |
215 |
|
|
The basic structure of a primitive is as follows: |
216 |
|
|
.IP |
217 |
|
|
.nf |
218 |
|
|
\f[C] |
219 |
|
|
modifier type identifier |
220 |
|
|
n S1 S2 S3 ..Sn |
221 |
|
|
0 |
222 |
|
|
m R1 R2 R3 ..Rm |
223 |
|
|
\f[] |
224 |
|
|
.fi |
225 |
|
|
.LP |
226 |
|
|
The \f[C]modifier\f[R] is the \f[C]identifier\f[R] of a previously |
227 |
|
|
defined primitive, or \f[C]void\f[R] if no modifier is appropriate. |
228 |
|
|
The type is one of the supported \f[I]Radiance\f[R] primitive keywords, |
229 |
|
|
such as \f[I]polygon\f[R] or \f[I]plastic\f[R]. |
230 |
|
|
Following the \f[C]modifier\f[R], type and identifier are the string |
231 |
|
|
arguments, preceded by the number of string arguments and separated by |
232 |
|
|
white space. |
233 |
|
|
If there are no string arguments, then 0 should be given for |
234 |
|
|
\f[C]n\f[R]. |
235 |
|
|
The string arguments are followed by the integer arguments in the same |
236 |
|
|
fashion. |
237 |
|
|
(Since there are no \f[I]Radiance\f[R] primitives currently using |
238 |
|
|
integer arguments, the count is always 0.) |
239 |
|
|
Finally, the number of real arguments is given, followed by the real |
240 |
|
|
arguments. |
241 |
|
|
.PP |
242 |
|
|
The location of the primitive in the scene description has no |
243 |
|
|
importance, except that its modifier refers to the most recently defined |
244 |
|
|
primitive with that identifier. |
245 |
|
|
If no such modifier was defined, an error results. |
246 |
|
|
In fact, \[lq]undefined modifier\[rq] is the most frequently reported |
247 |
|
|
error when parsing an invalid scene description, since any random bit of |
248 |
|
|
junk encountered where a statement is expected will be interpreted as a |
249 |
|
|
modifier. |
250 |
|
|
One final note about modifiers \[em] since surfaces never modify |
251 |
|
|
anything, their identifiers are neither stored nor referenced in the |
252 |
|
|
parser\[cq]s modifier list, and serve only for debugging purposes during |
253 |
|
|
editing and rendering. |
254 |
|
|
.PP |
255 |
|
|
Within a primitive, white space serves only to separate words, and |
256 |
|
|
multiple spaces, tabs, form feeds, returns, and newlines are all |
257 |
|
|
considered as one separator. |
258 |
|
|
Consequently, it is not possible for a string argument to contain any |
259 |
|
|
white space, which is OK because no \f[I]Radiance\f[R] primitive needs |
260 |
|
|
this. |
261 |
|
|
.SH 4 |
262 |
|
|
Aliases |
263 |
|
|
.pdfhref O 4 "Aliases" |
264 |
|
|
.pdfhref M "aliases" |
265 |
|
|
.LP |
266 |
|
|
An alias simply associates a new modifier and identifier with a |
267 |
|
|
previously defined primitive. |
268 |
|
|
The syntax is as follows: |
269 |
|
|
.IP |
270 |
|
|
.nf |
271 |
|
|
\f[C] |
272 |
|
|
modifier alias new_identifier old_identifier |
273 |
|
|
\f[] |
274 |
|
|
.fi |
275 |
|
|
.LP |
276 |
|
|
The \f[C]old_identifier\f[R] should be associated with some modifier |
277 |
|
|
primitive (i.e., non-surface) given earlier. |
278 |
|
|
The \f[C]modifier\f[R], if different from the original, will be used |
279 |
|
|
instead in later applications of \f[C]new_identifier\f[R]. |
280 |
|
|
.PP |
281 |
|
|
Aliases are most often used to give new names to previously defined |
282 |
|
|
materials. |
283 |
|
|
They may also be used to associate different patterns or textures with |
284 |
|
|
the same material. |
285 |
|
|
.SH 3 |
286 |
|
|
Scene Hierarchy |
287 |
|
|
.pdfhref O 3 "Scene Hierarchy" |
288 |
|
|
.pdfhref M "scene-hierarchy" |
289 |
|
|
.LP |
290 |
|
|
Hierarchical scene descriptions are achieved through expansion of |
291 |
|
|
in-line \f[B]xform\f[R] commands. |
292 |
|
|
The \f[B]xform\f[R] command is used to read and place other |
293 |
|
|
\f[I]Radiance\f[R] scene description files in the calling file, and |
294 |
|
|
these other descriptions may in turn read others, and so on down the |
295 |
|
|
tree. |
296 |
|
|
No check is made to assure that none of the calling files is called |
297 |
|
|
again, even by itself. |
298 |
|
|
If this happens, commands open commands until the system runs out of |
299 |
|
|
processes, which is a very nasty business and to be avoided. |
300 |
|
|
.SH 3 |
301 |
|
|
\f[BI]Radiance\f[B] Programs |
302 |
|
|
.pdfhref O 3 "Radiance Programs" |
303 |
|
|
.pdfhref M "radiance-programs" |
304 |
|
|
.LP |
305 |
|
|
The following table shows programs in the main \f[I]Radiance\f[R] |
306 |
|
|
distribution that read and write scene description files. |
307 |
|
|
Additionally, there are other translators that write scene files, which |
308 |
|
|
are available separately as free contributions or as part of other (CAD) |
309 |
|
|
programs. |
310 |
|
|
.PP |
311 |
|
|
.na |
312 |
|
|
.TS |
313 |
|
|
delim(@@) tab( ); |
314 |
|
|
l l l l. |
315 |
|
|
T{ |
316 |
|
|
Program |
317 |
|
|
T} T{ |
318 |
|
|
Read |
319 |
|
|
T} T{ |
320 |
|
|
Write |
321 |
|
|
T} T{ |
322 |
|
|
Function |
323 |
|
|
T} |
324 |
|
|
_ |
325 |
|
|
T{ |
326 |
|
|
\f[B]arch2rad\f[R] |
327 |
|
|
T} T{ |
328 |
|
|
T} T{ |
329 |
|
|
X |
330 |
|
|
T} T{ |
331 |
|
|
Convert Architrion text file to \f[I]Radiance\f[R] |
332 |
|
|
T} |
333 |
|
|
T{ |
334 |
|
|
\f[B]genblinds\f[R] |
335 |
|
|
T} T{ |
336 |
|
|
T} T{ |
337 |
|
|
X |
338 |
|
|
T} T{ |
339 |
|
|
Generate curved venetian blinds |
340 |
|
|
T} |
341 |
|
|
T{ |
342 |
|
|
\f[B]genbox\f[R] |
343 |
|
|
T} T{ |
344 |
|
|
T} T{ |
345 |
|
|
X |
346 |
|
|
T} T{ |
347 |
|
|
Generate parallelepiped |
348 |
|
|
T} |
349 |
|
|
T{ |
350 |
|
|
\f[B]genclock\f[R] |
351 |
|
|
T} T{ |
352 |
|
|
T} T{ |
353 |
|
|
X |
354 |
|
|
T} T{ |
355 |
|
|
Generate analog clock |
356 |
|
|
T} |
357 |
|
|
T{ |
358 |
|
|
\f[B]genprism\f[R] |
359 |
|
|
T} T{ |
360 |
|
|
T} T{ |
361 |
|
|
X |
362 |
|
|
T} T{ |
363 |
|
|
Generate extruded polygon |
364 |
|
|
T} |
365 |
|
|
T{ |
366 |
|
|
\f[B]genrev\f[R] |
367 |
|
|
T} T{ |
368 |
|
|
T} T{ |
369 |
|
|
X |
370 |
|
|
T} T{ |
371 |
|
|
Generate surface of revolution |
372 |
|
|
T} |
373 |
|
|
T{ |
374 |
|
|
\f[B]gensky\f[R] |
375 |
|
|
T} T{ |
376 |
|
|
T} T{ |
377 |
|
|
X |
378 |
|
|
T} T{ |
379 |
|
|
Generate CIE sky distribution |
380 |
|
|
T} |
381 |
|
|
T{ |
382 |
|
|
\f[B]gensurf\f[R] |
383 |
|
|
T} T{ |
384 |
|
|
T} T{ |
385 |
|
|
X |
386 |
|
|
T} T{ |
387 |
|
|
Generate arbitrary surface patch |
388 |
|
|
T} |
389 |
|
|
T{ |
390 |
|
|
\f[B]genworm\f[R] |
391 |
|
|
T} T{ |
392 |
|
|
T} T{ |
393 |
|
|
X |
394 |
|
|
T} T{ |
395 |
|
|
Generate varying diameter curved path |
396 |
|
|
T} |
397 |
|
|
T{ |
398 |
|
|
\f[B]ies2rad\f[R] |
399 |
|
|
T} T{ |
400 |
|
|
T} T{ |
401 |
|
|
X |
402 |
|
|
T} T{ |
403 |
|
|
Convert IES luminaire file to \f[I]Radiance\f[R] |
404 |
|
|
T} |
405 |
|
|
T{ |
406 |
|
|
\f[B]mgf2rad\f[R] |
407 |
|
|
T} T{ |
408 |
|
|
T} T{ |
409 |
|
|
X |
410 |
|
|
T} T{ |
411 |
|
|
Convert MGF file to \f[I]Radiance\f[R] |
412 |
|
|
T} |
413 |
|
|
T{ |
414 |
|
|
\f[B]mkillum\f[R] |
415 |
|
|
T} T{ |
416 |
|
|
X |
417 |
|
|
T} T{ |
418 |
|
|
X |
419 |
|
|
T} T{ |
420 |
|
|
Compute \f[I]illum\f[R] secondary sources |
421 |
|
|
T} |
422 |
|
|
T{ |
423 |
|
|
\f[B]nff2rad\f[R] |
424 |
|
|
T} T{ |
425 |
|
|
T} T{ |
426 |
|
|
X |
427 |
|
|
T} T{ |
428 |
|
|
Convert NFF file to \f[I]Radiance\f[R] |
429 |
|
|
T} |
430 |
|
|
T{ |
431 |
|
|
\f[B]objline\f[R] |
432 |
|
|
T} T{ |
433 |
|
|
T} T{ |
434 |
|
|
X |
435 |
|
|
T} T{ |
436 |
|
|
Generate line drawing of \f[I]Radiance\f[R] file |
437 |
|
|
T} |
438 |
|
|
T{ |
439 |
|
|
\f[B]objview\f[R] |
440 |
|
|
T} T{ |
441 |
|
|
T} T{ |
442 |
|
|
X |
443 |
|
|
T} T{ |
444 |
|
|
Quick view of \f[I]Radiance\f[R] object |
445 |
|
|
T} |
446 |
|
|
T{ |
447 |
|
|
\f[B]oconv\f[R] |
448 |
|
|
T} T{ |
449 |
|
|
T} T{ |
450 |
|
|
X |
451 |
|
|
T} T{ |
452 |
|
|
Compile \f[I]Radiance\f[R] scene description |
453 |
|
|
T} |
454 |
|
|
T{ |
455 |
|
|
\f[B]obj2rad\f[R] |
456 |
|
|
T} T{ |
457 |
|
|
T} T{ |
458 |
|
|
X |
459 |
|
|
T} T{ |
460 |
|
|
Convert Wavefront .OBJ file to \f[I]Radiance\f[R] |
461 |
|
|
T} |
462 |
|
|
T{ |
463 |
|
|
\f[B]rad\f[R] |
464 |
|
|
T} T{ |
465 |
|
|
X |
466 |
|
|
T} T{ |
467 |
|
|
T} T{ |
468 |
|
|
Render \f[I]Radiance\f[R] scene |
469 |
|
|
T} |
470 |
|
|
T{ |
471 |
|
|
\f[B]rad2mgf\f[R] |
472 |
|
|
T} T{ |
473 |
|
|
X |
474 |
|
|
T} T{ |
475 |
|
|
T} T{ |
476 |
|
|
Convert \f[I]Radiance\f[R] file to MGF |
477 |
|
|
T} |
478 |
|
|
T{ |
479 |
|
|
\f[B]raddepend\f[R] |
480 |
|
|
T} T{ |
481 |
|
|
X |
482 |
|
|
T} T{ |
483 |
|
|
T} T{ |
484 |
|
|
Determine scene file dependencies |
485 |
|
|
T} |
486 |
|
|
T{ |
487 |
|
|
\f[B]replmarks\f[R] |
488 |
|
|
T} T{ |
489 |
|
|
X |
490 |
|
|
T} T{ |
491 |
|
|
X |
492 |
|
|
T} T{ |
493 |
|
|
Replace triangular markers with objects |
494 |
|
|
T} |
495 |
|
|
T{ |
496 |
|
|
\f[B]rpict\f[R] |
497 |
|
|
T} T{ |
498 |
|
|
X |
499 |
|
|
T} T{ |
500 |
|
|
T} T{ |
501 |
|
|
Batch rendering program |
502 |
|
|
T} |
503 |
|
|
T{ |
504 |
|
|
\f[B]rtrace\f[R] |
505 |
|
|
T} T{ |
506 |
|
|
X |
507 |
|
|
T} T{ |
508 |
|
|
T} T{ |
509 |
|
|
Customizable ray-tracer |
510 |
|
|
T} |
511 |
|
|
T{ |
512 |
|
|
\f[B]rview\f[R] |
513 |
|
|
T} T{ |
514 |
|
|
X |
515 |
|
|
T} T{ |
516 |
|
|
T} T{ |
517 |
|
|
Interactive renderer |
518 |
|
|
T} |
519 |
|
|
T{ |
520 |
|
|
\f[B]thf2rad\f[R] |
521 |
|
|
T} T{ |
522 |
|
|
T} T{ |
523 |
|
|
X |
524 |
|
|
T} T{ |
525 |
|
|
Convert GDS things file to \f[I]Radiance\f[R] |
526 |
|
|
T} |
527 |
|
|
T{ |
528 |
|
|
\f[B]tmesh2rad\f[R] |
529 |
|
|
T} T{ |
530 |
|
|
T} T{ |
531 |
|
|
X |
532 |
|
|
T} T{ |
533 |
|
|
Convert triangle mesh file to \f[I]Radiance\f[R] |
534 |
|
|
T} |
535 |
|
|
T{ |
536 |
|
|
\f[B]xform\f[R] |
537 |
|
|
T} T{ |
538 |
|
|
X |
539 |
|
|
T} T{ |
540 |
|
|
X |
541 |
|
|
T} T{ |
542 |
|
|
Transform Radiance objects |
543 |
|
|
T} |
544 |
|
|
.TE |
545 |
|
|
.ad |
546 |
|
|
.LP |
547 |
|
|
\f[B]Table 1.\f[R] Radiance programs that read and write scene |
548 |
|
|
descriptions. |
549 |
|
|
.SH 3 |
550 |
|
|
\f[BI]Radiance\f[B] C Library |
551 |
|
|
.pdfhref O 3 "Radiance C Library" |
552 |
|
|
.pdfhref M "radiance-c-library" |
553 |
|
|
.LP |
554 |
|
|
The principal library function for reading scene description files is |
555 |
|
|
\f[C]readobj(inpspec)\f[R], defined in \f[C]src/common/readobj.c\f[R]. |
556 |
|
|
This routine takes the name of a file, or command beginning with `!', or |
557 |
|
|
\f[C]NULL\f[R] if standard input is to be read, and loads the |
558 |
|
|
\f[I]Radiance\f[R] data structures defined in |
559 |
|
|
\f[C]src/common/object.h\f[R]. |
560 |
|
|
If loading \f[I]Radiance\f[R] data structures is not the action desired, |
561 |
|
|
then a more custom approach is necessary, such as that used in |
562 |
|
|
\f[C]src/gen/xform.c\f[R]. |
563 |
|
|
If using \f[I]Radiance\f[R] data structures is acceptable, but the data |
564 |
|
|
need not remain resident in memory, then follow the lead in |
565 |
|
|
\f[C]src/ot/getbbox.c\f[R] and use \f[C]src/ot/readobj2.c\f[R] instead. |
566 |
|
|
In any case, the list of defined primitive types in |
567 |
|
|
\f[C]src/common/otypes.h\f[R] is crucial. |
568 |
|
|
.SH 2 |
569 |
|
|
Function File Format (.cal suffix) |
570 |
|
|
.pdfhref O 2 "Function File Format \(.cal suffix\)" |
571 |
|
|
.pdfhref M "function-file-format-.cal-suffix" |
572 |
|
|
.LP |
573 |
|
|
Function files are used throughout \f[I]Radiance\f[R] to specify |
574 |
|
|
mathematical formulas and relations for procedural textures, patterns |
575 |
|
|
and surfaces. |
576 |
|
|
They are also used by filter programs such as rcalc to manipulate data, |
577 |
|
|
and pcomb to manipulate pictures. |
578 |
|
|
.PP |
579 |
|
|
Function file syntax is simple and should be familiar to most |
580 |
|
|
programmers, as it is based on fairly standard algebraic expressions. |
581 |
|
|
Here is an example, which corresponds to the in-line commands given in |
582 |
|
|
the previous section: |
583 |
|
|
.IP |
584 |
|
|
.nf |
585 |
|
|
\f[C] |
586 |
|
|
{ |
587 |
|
|
basin.cal - calculate coordinates for basin sink. |
588 |
|
|
} |
589 |
|
|
|
590 |
|
|
theta(s) = PI*(0.5+0.5*s); |
591 |
|
|
phi(t) = 2*PI*t; |
592 |
|
|
|
593 |
|
|
R(th,p) = 5 + ( 3.25*cos(p)\[ha]2 + |
594 |
|
|
1.75*sin(p)\[ha]2 ) * sin(th)\[ha]2; |
595 |
|
|
|
596 |
|
|
x(th,p) = R(th,p)*sin(th)*cos(p); |
597 |
|
|
y(th,p) = R(th,p)*sin(th)*sin(p); |
598 |
|
|
z(th,p) = R(th,p)*cos(th); |
599 |
|
|
\f[] |
600 |
|
|
.fi |
601 |
|
|
.LP |
602 |
|
|
In contrast to the usual semantics in programs where each statement |
603 |
|
|
corresponds to an evaluation, statements in function files correspond to |
604 |
|
|
\f[I]definitions\f[R]. |
605 |
|
|
Once a function or variable has been defined, it may be used in later |
606 |
|
|
definitions, along with predefined functions such as \f[C]sin(x)\f[R] |
607 |
|
|
and \f[C]cos(x)\f[R] and constants such as PI \**. |
608 |
|
|
.FS |
609 |
|
|
TBD - There once was a footnote here |
610 |
|
|
.FE |
611 |
|
|
(All math functions use standard C conventions, hence trigonometry is |
612 |
|
|
done in radians rather than degrees.) |
613 |
|
|
.PP |
614 |
|
|
Evaluation order (operator precedence) follows standard rules of |
615 |
|
|
algebra. |
616 |
|
|
Exponentiation is performed first \f[C](x\[ha]y)\f[R], followed by |
617 |
|
|
multiplication and division \f[C](x*y, x/y)\f[R], then addition and |
618 |
|
|
subtraction \f[C](x+y, x-y)\f[R]. |
619 |
|
|
Unary minus is most tightly associated \f[C](-x)\f[R], and parentheses |
620 |
|
|
override operator precedence in the usual way. |
621 |
|
|
Semicolons separate statements, and white space is generally ignored. |
622 |
|
|
Comments are enclosed by curly braces, which may be nested. |
623 |
|
|
.PP |
624 |
|
|
The above file does not actually \f[I]do\f[R] anything, it merely |
625 |
|
|
defines functions that are useful by a program that does. |
626 |
|
|
Taking our \f[B]gensurf\f[R] example from the previous section: |
627 |
|
|
.IP |
628 |
|
|
.nf |
629 |
|
|
\f[C] |
630 |
|
|
!gensurf marble sink \[aq]15.5+x(theta(s),phi(t))\[aq] \[rs] |
631 |
|
|
\[aq]10.5+y(theta(s),phi(t))\[aq] \[rs] |
632 |
|
|
\[aq]30.75+z(theta(s),phi(t))\[aq] \[rs] |
633 |
|
|
8 29 -f basin.cal -s |
634 |
|
|
\f[] |
635 |
|
|
.fi |
636 |
|
|
.LP |
637 |
|
|
The \f[B]-f\f[R] option loads in our file, which is then used to |
638 |
|
|
evaluate expressions such as \f[C]15.5+x(theta(s),phi(t))\f[R] for |
639 |
|
|
specific values of \f[C]s\f[R] and \f[C]t\f[R]. |
640 |
|
|
These variables range from 0 to 1 over the surface patch in increments |
641 |
|
|
of @1 / 8@ and @1 / 29@, respectively. |
642 |
|
|
(See the \f[B]gensurf\f[R] manual page for details.) |
643 |
|
|
The entire expression for each evaluation could have been written in the |
644 |
|
|
command line, but it is much more convenient to create a function file. |
645 |
|
|
.SH 3 |
646 |
|
|
Language Features |
647 |
|
|
.pdfhref O 3 "Language Features" |
648 |
|
|
.pdfhref M "language-features" |
649 |
|
|
.LP |
650 |
|
|
Subtle features of the functional language provide much greater power |
651 |
|
|
than first meets the eye. |
652 |
|
|
One of these is the ability to define recursive functions. |
653 |
|
|
The following example defines the factorial function (\f[I]n!\f[R]): |
654 |
|
|
.IP |
655 |
|
|
.nf |
656 |
|
|
\f[C] |
657 |
|
|
fact(n) : if(n-1.5, n*fact(n-1), 1); |
658 |
|
|
\f[] |
659 |
|
|
.fi |
660 |
|
|
.LP |
661 |
|
|
This uses the library function \f[C]if(cond,e1,e0)\f[R], which returns |
662 |
|
|
\f[C]e1\f[R] if cond is greater than zero, and \f[C]e0\f[R] otherwise. |
663 |
|
|
Since only one of these expressions is evaluated, \f[C]fact(n)\f[R] will |
664 |
|
|
call itself until \f[C]n\f[R] is less than 2, when the \f[C]if\f[R] |
665 |
|
|
expression returns 1\**. |
666 |
|
|
.FS |
667 |
|
|
Note that we compare \f[C]n\f[R] to 1.5, so as to avoid any round-off |
668 |
|
|
problems caused by floating point math. |
669 |
|
|
Caution is advised because all expressions are evaluated as |
670 |
|
|
double-precision real, and comparisons to zero are unreliable. |
671 |
|
|
.FE |
672 |
|
|
The colon (`:') is used in place of the usual equals assignment (`=') |
673 |
|
|
because we want this function to have the constant attribute, which |
674 |
|
|
means any later appearance in an expression of \f[C]fact(ce)\f[R] where |
675 |
|
|
ce is also a constant expression will be replaced by its value. |
676 |
|
|
This can be an important savings in cases where an expression or |
677 |
|
|
subexpression is expensive to evaluate, and only needs to be computed |
678 |
|
|
once. |
679 |
|
|
All of the standard library functions have the constant attribute. |
680 |
|
|
(See the following section for a complete list.) |
681 |
|
|
.PP |
682 |
|
|
Another handy language feature is the ability to pass function names as |
683 |
|
|
arguments. |
684 |
|
|
A simple example of this is the following function, which computes the |
685 |
|
|
numerical derivative of a function given as its first argument: |
686 |
|
|
.IP |
687 |
|
|
.nf |
688 |
|
|
\f[C] |
689 |
|
|
FTINY : 1e-7; |
690 |
|
|
d1(f,x) = (f(x+FTINY)-f(x-FTINY))/FTINY/2; |
691 |
|
|
\f[] |
692 |
|
|
.fi |
693 |
|
|
.LP |
694 |
|
|
Evaluating \f[C]d1(sin,1.1)\f[R] using this formula yields 0.4536, which |
695 |
|
|
is fairly close to the true derivative, which is \f[C]cos(1.1)\f[R]. |
696 |
|
|
.PP |
697 |
|
|
A third language feature, which is normally transparent to the user, is |
698 |
|
|
the notion of \f[I]contexts\f[R]. |
699 |
|
|
Identifiers may be composed of parts, starting with a name and |
700 |
|
|
continuing with one or more context names. |
701 |
|
|
Each name is delimited by a back-quote (`\[ga]'). |
702 |
|
|
Names themselves begin with a letter and continue with any sequence of |
703 |
|
|
letters, digits, underscores and decimal points. |
704 |
|
|
The following are examples of valid identifiers: |
705 |
|
|
.IP |
706 |
|
|
.nf |
707 |
|
|
\f[C] |
708 |
|
|
v1, V.W, x_rand\[ga]local, \[ga]A_, Qa_5\[ga] |
709 |
|
|
\f[] |
710 |
|
|
.fi |
711 |
|
|
.LP |
712 |
|
|
If a context mark appears at the beginning of the identifier, then its |
713 |
|
|
reference must be local. |
714 |
|
|
If it appears at the end, then its reference must be global. |
715 |
|
|
A local reference must be resolved in the local context, i.e., no |
716 |
|
|
contexts above this one will be searched. |
717 |
|
|
A global reference must correspond to the original context, ignoring any |
718 |
|
|
local redefinitions. |
719 |
|
|
.PP |
720 |
|
|
The reason that contexts are normally transparent is that they are |
721 |
|
|
controlled by the calling program \[em] there are no explicit language |
722 |
|
|
features for establishing contexts. |
723 |
|
|
A new context is established automatically for each function file loaded |
724 |
|
|
by the rendering programs. |
725 |
|
|
That way, it is safe to reuse variable names that have been used in |
726 |
|
|
other files, and even in the main initialization file, |
727 |
|
|
\f[C]rayinit.cal\f[R]. |
728 |
|
|
.PP |
729 |
|
|
Although not strictly necessary, there are two good reasons to define |
730 |
|
|
variables and functions before referencing them in a function file. |
731 |
|
|
One is related to contexts. |
732 |
|
|
If a previous definition of a variable name is given in an enclosing |
733 |
|
|
context (e.g., \f[C]rayinit.cal\f[R]), then that reference will be used |
734 |
|
|
rather than a later one in the current context, unless the reference is |
735 |
|
|
made explicitly local by starting the identifier with a context mark. |
736 |
|
|
The second reason for defining before referencing is constant |
737 |
|
|
expressions. |
738 |
|
|
If a variable or function has the constant attribute (i.e., defined with |
739 |
|
|
`:' instead of `='), then a later subexpression referencing it can be |
740 |
|
|
replaced by its evaluated result during compilation. |
741 |
|
|
If the constant is not defined until after it is referenced, it remains |
742 |
|
|
as a reference, which takes time to evaluate each time. |
743 |
|
|
.PP |
744 |
|
|
Other features of the language are truly transparent, but knowledge of |
745 |
|
|
them can help one to write more efficient function files: |
746 |
|
|
.IP \[bu] 3 |
747 |
|
|
Once a variable has been evaluated, the result is cached and it is not |
748 |
|
|
reevaluated unless the client program changes an internal counter |
749 |
|
|
(\f[C]eclock\f[R]), which indicates that something has changed. |
750 |
|
|
This means that using variables to hold frequently used values will not |
751 |
|
|
only simplify the function file, it will save time during evaluation. |
752 |
|
|
.IP \[bu] 3 |
753 |
|
|
An argument passed in a function call is not evaluated until the |
754 |
|
|
function calls for it specifically, and the result is also cached to |
755 |
|
|
avoid redundant calculation. |
756 |
|
|
The conditional evaluation feature is actually a requirement for |
757 |
|
|
recursive functions to work, but caching is not. |
758 |
|
|
Argument value caching means it is more efficient to pass an |
759 |
|
|
expensive-to-compute expression than to have the function compute it |
760 |
|
|
internally if it appears more than once in the function definition. |
761 |
|
|
This is especially true for recursive functions with deep call trees. |
762 |
|
|
.SH 3 |
763 |
|
|
Standard Definitions (Library) |
764 |
|
|
.pdfhref O 3 "Standard Definitions \(Library\)" |
765 |
|
|
.pdfhref M "standard-definitions-library" |
766 |
|
|
.LP |
767 |
|
|
The following are always defined: |
768 |
|
|
.IP "\f[B]\f[CB]if(a, b, c)\f[B]\f[R]" 3 |
769 |
|
|
Conditional expression. |
770 |
|
|
If a is positive, return b, else return c. |
771 |
|
|
.RS 3 |
772 |
|
|
.RE |
773 |
|
|
.IP "\f[B]\f[CB]select(N, a1, a2, ..)\f[B]\f[R]" 3 |
774 |
|
|
Return Nth argument. |
775 |
|
|
If N is 0, then return the count of arguments excluding the first. |
776 |
|
|
This provides basic array functionality. |
777 |
|
|
.RS 3 |
778 |
|
|
.RE |
779 |
|
|
.IP "\f[B]\f[CB]sqrt(x)\f[B]\f[R]" 3 |
780 |
|
|
Return square root of \f[C]x\f[R], where \f[C]x >= 0\f[R]. |
781 |
|
|
.RS 3 |
782 |
|
|
.RE |
783 |
|
|
.IP "\f[B]\f[CB]sin(x), cos(x), tan(x), asin(x), acos(x), atan(x), atan2(y,x)\f[B]\f[R]" 3 |
784 |
|
|
Standard trigonometry functions. |
785 |
|
|
.RS 3 |
786 |
|
|
.RE |
787 |
|
|
.IP "\f[B]\f[CB]floor(x), ceil(x)\f[B]\f[R]" 3 |
788 |
|
|
Greatest lower bound and least upper bound (integer). |
789 |
|
|
.RS 3 |
790 |
|
|
.RE |
791 |
|
|
.IP "\f[B]\f[CB]exp(x), log(x), log10(x)\f[B]\f[R]" 3 |
792 |
|
|
Exponent and logarithm functions. |
793 |
|
|
.RS 3 |
794 |
|
|
.RE |
795 |
|
|
.IP "\f[B]\f[CB]rand(x)\f[B]\f[R]" 3 |
796 |
|
|
Return pseudo-random number in the range [0,1) for any argument x. |
797 |
|
|
The same return value is guaranteed for the same argument. |
798 |
|
|
.RS 3 |
799 |
|
|
.RE |
800 |
|
|
.LP |
801 |
|
|
The following are sometimes defined, depending on the program: |
802 |
|
|
.IP "\f[B]PI\f[R]" 3 |
803 |
|
|
The ratio of a circle\[cq]s circumference to its diameter. |
804 |
|
|
.RS 3 |
805 |
|
|
.RE |
806 |
|
|
.IP "\f[B]\f[CB]erf(z), erfc(z)\f[B]\f[R]" 3 |
807 |
|
|
Error function and complimentary error function. |
808 |
|
|
.RS 3 |
809 |
|
|
.RE |
810 |
|
|
.IP "\f[B]\f[CB]j0(x), j1(x), jn(n,x), y0(x), y1(x), yn(n,x)\f[B]\f[R]" 3 |
811 |
|
|
Bessel functions. |
812 |
|
|
.RS 3 |
813 |
|
|
.RE |
814 |
|
|
.IP "\f[B]\f[CB]hermite(p0,p1,r0,r1,t)\f[B]\f[R]" 3 |
815 |
|
|
One-dimensional Hermite polynomial. |
816 |
|
|
.RS 3 |
817 |
|
|
.RE |
818 |
|
|
.LP |
819 |
|
|
The rendering programs also define the following noise functions: |
820 |
|
|
.IP "\f[B]\f[CB]noise3(x,y,z), noise3x(x,y,z), noise3y(x,y,z), noise3z(x,y,z)\f[B]\f[R]" 3 |
821 |
|
|
Perlin noise function and its gradient [Perlin85][Arvo91,p.396]. |
822 |
|
|
.RS 3 |
823 |
|
|
.RE |
824 |
|
|
.IP "\f[B]\f[CB]fnoise3(x,y,z)\f[B]\f[R]" 3 |
825 |
|
|
Fractal noise function, ranging from -1 to 1. |
826 |
|
|
.RS 3 |
827 |
|
|
.RE |
828 |
|
|
.LP |
829 |
|
|
Interaction with the renderer is achieved via special purpose variables |
830 |
|
|
and functions whose values correspond to the current ray intersection |
831 |
|
|
and the calling primitive. |
832 |
|
|
Unlike the above functions, none of these have the constant attribute |
833 |
|
|
since their values change from one ray to the next: |
834 |
|
|
.IP "\f[B]\f[CB]Dx, Dy, Dz\f[B]\f[R]" 3 |
835 |
|
|
ray direction |
836 |
|
|
.RS 3 |
837 |
|
|
.RE |
838 |
|
|
.IP "\f[B]\f[CB]Nx, Ny, Nz\f[B]\f[R]" 3 |
839 |
|
|
surface normal |
840 |
|
|
.RS 3 |
841 |
|
|
.RE |
842 |
greg |
1.2 |
.IP "\f[B]\f[CB]Px, Py, Pz\f[B]\f[R]" 3 |
843 |
|
|
intersection point |
844 |
|
|
.RS 3 |
845 |
|
|
.RE |
846 |
greg |
1.1 |
.IP "\f[B]\f[CB]T\f[B]\f[R]" 3 |
847 |
|
|
distance from start |
848 |
|
|
.RS 3 |
849 |
|
|
.RE |
850 |
|
|
.IP "\f[B]\f[CB]Ts\f[B]\f[R]" 3 |
851 |
|
|
single ray (shadow) distance |
852 |
|
|
.RS 3 |
853 |
|
|
.RE |
854 |
|
|
.IP "\f[B]\f[CB]Rdot\f[B]\f[R]" 3 |
855 |
|
|
ray dot product |
856 |
|
|
.RS 3 |
857 |
|
|
.RE |
858 |
|
|
.IP "\f[B]\f[CB]S\f[B]\f[R]" 3 |
859 |
|
|
world scale |
860 |
|
|
.RS 3 |
861 |
|
|
.RE |
862 |
|
|
.IP "\f[B]\f[CB]Tx, Ty, Tz\f[B]\f[R]" 3 |
863 |
|
|
world origin |
864 |
|
|
.RS 3 |
865 |
|
|
.RE |
866 |
|
|
.IP "\f[B]\f[CB]Ix, Iy, Iz\f[B]\f[R]" 3 |
867 |
|
|
world i unit vector |
868 |
|
|
.RS 3 |
869 |
|
|
.RE |
870 |
|
|
.IP "\f[B]\f[CB]Jx, Jy, Jz\f[B]\f[R]" 3 |
871 |
|
|
world j unit vector |
872 |
|
|
.RS 3 |
873 |
|
|
.RE |
874 |
|
|
.IP "\f[B]\f[CB]Kx, Ky, Kz\f[B]\f[R]" 3 |
875 |
|
|
world k unit vector |
876 |
|
|
.RS 3 |
877 |
|
|
.RE |
878 |
|
|
.IP "\f[B]\f[CB]arg(n)\f[B]\f[R]" 3 |
879 |
|
|
real arguments, arg(0) is count |
880 |
|
|
.RS 3 |
881 |
|
|
.RE |
882 |
|
|
.LP |
883 |
|
|
For BRDF primitives, the following variables are also available: |
884 |
|
|
.IP "\f[B]\f[CB]NxP, NyP, NzP\f[B]\f[R]" 3 |
885 |
|
|
perturbed surface normal |
886 |
|
|
.RS 3 |
887 |
|
|
.RE |
888 |
|
|
.IP "\f[B]\f[CB]RdotP\f[B]\f[R]" 3 |
889 |
|
|
perturbed ray dot product |
890 |
|
|
.RS 3 |
891 |
|
|
.RE |
892 |
|
|
.IP "\f[B]\f[CB]CrP, CgP, CbP\f[B]\f[R]" 3 |
893 |
|
|
perturbed material color |
894 |
|
|
.RS 3 |
895 |
|
|
.RE |
896 |
|
|
.LP |
897 |
|
|
For prism1 and prism2 primitives, the following are available: |
898 |
|
|
.IP "\f[B]\f[CB]DxA, DyA, DzA\f[B]\f[R]" 3 |
899 |
|
|
direction to target light source |
900 |
|
|
.RS 3 |
901 |
|
|
.RE |
902 |
|
|
.LP |
903 |
|
|
Other functions, variables and constants are defined as well in the file |
904 |
|
|
\f[C]src/rt/rayinit.cal\f[R], which gets installed in the standard |
905 |
|
|
\f[I]Radiance\f[R] library directory and can be modified or appended as |
906 |
|
|
desired\**. |
907 |
|
|
.FS |
908 |
|
|
It is usually a good idea to store any such customized files in a |
909 |
|
|
personal library location and set the \f[C]RAYPATH\f[R] environment |
910 |
|
|
variable to search there first. |
911 |
|
|
This way, it does not affect other users or get overwritten during the |
912 |
|
|
next system installation. |
913 |
|
|
.FE |
914 |
|
|
.SH 3 |
915 |
|
|
\f[BI]Radiance\f[B] Programs |
916 |
|
|
.pdfhref O 3 "Radiance Programs" |
917 |
|
|
.pdfhref M "radiance-programs-1" |
918 |
|
|
.LP |
919 |
|
|
Table 2 shows \f[I]Radiance\f[R] programs that read and write function |
920 |
|
|
files. |
921 |
|
|
.PP |
922 |
|
|
.na |
923 |
|
|
.TS |
924 |
|
|
delim(@@) tab( ); |
925 |
|
|
l l l l. |
926 |
|
|
T{ |
927 |
|
|
Program |
928 |
|
|
T} T{ |
929 |
|
|
Read |
930 |
|
|
T} T{ |
931 |
|
|
Write |
932 |
|
|
T} T{ |
933 |
|
|
Function |
934 |
|
|
T} |
935 |
|
|
_ |
936 |
|
|
T{ |
937 |
|
|
\f[B]calc\f[R] |
938 |
|
|
T} T{ |
939 |
|
|
X |
940 |
|
|
T} T{ |
941 |
|
|
X |
942 |
|
|
T} T{ |
943 |
|
|
Interactive calculator |
944 |
|
|
T} |
945 |
|
|
T{ |
946 |
|
|
\f[B]genrev\f[R] |
947 |
|
|
T} T{ |
948 |
|
|
X |
949 |
|
|
T} T{ |
950 |
|
|
T} T{ |
951 |
|
|
Generate surface of revolution |
952 |
|
|
T} |
953 |
|
|
T{ |
954 |
|
|
\f[B]gensurf\f[R] |
955 |
|
|
T} T{ |
956 |
|
|
X |
957 |
|
|
T} T{ |
958 |
|
|
T} T{ |
959 |
|
|
Generate arbitrary surface patch |
960 |
|
|
T} |
961 |
|
|
T{ |
962 |
|
|
\f[B]genworm\f[R] |
963 |
|
|
T} T{ |
964 |
|
|
X |
965 |
|
|
T} T{ |
966 |
|
|
T} T{ |
967 |
|
|
Generate varying diameter curved path |
968 |
|
|
T} |
969 |
|
|
T{ |
970 |
|
|
\f[B]macbethcal\f[R] |
971 |
|
|
T} T{ |
972 |
|
|
T} T{ |
973 |
|
|
X |
974 |
|
|
T} T{ |
975 |
|
|
Compute image color & contrast correction |
976 |
|
|
T} |
977 |
|
|
T{ |
978 |
|
|
\f[B]pcomb\f[R] |
979 |
|
|
T} T{ |
980 |
|
|
X |
981 |
|
|
T} T{ |
982 |
|
|
T} T{ |
983 |
|
|
Perform arbitrary math on picture(s) |
984 |
|
|
T} |
985 |
|
|
T{ |
986 |
|
|
\f[B]rcalc\f[R] |
987 |
|
|
T} T{ |
988 |
|
|
X |
989 |
|
|
T} T{ |
990 |
|
|
T} T{ |
991 |
|
|
Record stream calculator |
992 |
|
|
T} |
993 |
|
|
T{ |
994 |
|
|
\f[B]rpict\f[R] |
995 |
|
|
T} T{ |
996 |
|
|
X |
997 |
|
|
T} T{ |
998 |
|
|
T} T{ |
999 |
|
|
Batch rendering program |
1000 |
|
|
T} |
1001 |
|
|
T{ |
1002 |
|
|
\f[B]rtrace\f[R] |
1003 |
|
|
T} T{ |
1004 |
|
|
X |
1005 |
|
|
T} T{ |
1006 |
|
|
T} T{ |
1007 |
|
|
Customizable ray-tracer |
1008 |
|
|
T} |
1009 |
|
|
T{ |
1010 |
|
|
\f[B]rview\f[R] |
1011 |
|
|
T} T{ |
1012 |
|
|
X |
1013 |
|
|
T} T{ |
1014 |
|
|
T} T{ |
1015 |
|
|
Interactive renderer |
1016 |
|
|
T} |
1017 |
|
|
T{ |
1018 |
|
|
\f[B]tabfunc\f[R] |
1019 |
|
|
T} T{ |
1020 |
|
|
T} T{ |
1021 |
|
|
X |
1022 |
|
|
T} T{ |
1023 |
|
|
Create function file from tabulated data |
1024 |
|
|
T} |
1025 |
|
|
.TE |
1026 |
|
|
.ad |
1027 |
|
|
.LP |
1028 |
|
|
\f[B]Table 2.\f[R] Programs in the \f[I]Radiance\f[R] distribution that |
1029 |
|
|
read and write function files. |
1030 |
|
|
.PP |
1031 |
|
|
In addition, the program \f[B]ev\f[R] evaluates expressions given as |
1032 |
|
|
command line arguments, though it does not handle function files or |
1033 |
|
|
definitions. |
1034 |
|
|
There are also a number of 2-d plotting routines that use a slightly |
1035 |
|
|
modified statement syntax, called \f[B]bgraph\f[R], \f[B]dgraph\f[R], |
1036 |
|
|
\f[B]gcomp\f[R], and \f[B]igraph\f[R]. |
1037 |
|
|
Additional utility programs are useful in combination with rcalc for |
1038 |
|
|
data analysis and scene generation. |
1039 |
|
|
The program \f[B]cnt\f[R] generates simple records to drive |
1040 |
|
|
\f[B]rcalc\f[R], and the \f[B]total\f[R] program is handy for adding up |
1041 |
|
|
results. |
1042 |
|
|
The \f[B]histo\f[R] program computes histograms needed for certain types |
1043 |
|
|
of statistical analysis. |
1044 |
|
|
The \f[B]lam\f[R] program concatenates columns from multiple input |
1045 |
|
|
files, and \f[B]neat\f[R] neatens up columns for better display. |
1046 |
|
|
.SH 3 |
1047 |
|
|
\f[BI]Radiance\f[B] C Library |
1048 |
|
|
.pdfhref O 3 "Radiance C Library" |
1049 |
|
|
.pdfhref M "radiance-c-library-1" |
1050 |
|
|
.LP |
1051 |
|
|
The standard routines for loading and evaluating function files are |
1052 |
|
|
divided into three modules, \f[C]src/common/calexpr.c\f[R] for |
1053 |
|
|
expression parsing and evaluation, \f[C]src/common/caldefn.c\f[R] for |
1054 |
|
|
variable and function storage and lookup, and |
1055 |
|
|
\f[C]src/common/calfunc.c\f[R] for library function storage and function |
1056 |
|
|
evaluation. |
1057 |
|
|
There is a fourth module for writing out expressions called |
1058 |
|
|
\f[C]src/common/calprnt.c\f[R], which we will not discuss. |
1059 |
|
|
They all use the header file \f[C]src/common/calcomp.h\f[R], which |
1060 |
|
|
defines common data structures and evaluation macros. |
1061 |
|
|
Of these, the three most often used declarations for external routines |
1062 |
|
|
are: |
1063 |
|
|
.IP "\f[B]\f[CB]typedef struct epnode EPNODE;\f[B]\f[R]" 3 |
1064 |
|
|
Expression parse tree node. |
1065 |
|
|
Some routines return pointers to this structure type, and the main |
1066 |
|
|
evaluation macro, \f[C]evalue(ep)\f[R], takes an argument of this type. |
1067 |
|
|
.RS 3 |
1068 |
|
|
.RE |
1069 |
|
|
.IP "\f[B]\f[CB](double) evalue(ep);\f[B]\f[R]" 3 |
1070 |
|
|
Evaluate an expression parse tree. |
1071 |
|
|
Uses node type table to access appropriate function depending on root |
1072 |
|
|
node type. |
1073 |
|
|
(E.g., an addition node calls \f[C]eadd(ep)\f[R].) |
1074 |
|
|
.RS 3 |
1075 |
|
|
.RE |
1076 |
|
|
.IP "\f[B]\f[CB]extern unsigned long eclock;\f[B]\f[R]" 3 |
1077 |
|
|
This is a counter used to determine when variable values need updating. |
1078 |
|
|
The initial value is 0, which tells the routines always to reevaluate |
1079 |
|
|
variables. |
1080 |
|
|
Once incremented to 1, variable evaluations are cached and not |
1081 |
|
|
recomputed until \f[C]eclock\f[R] is incremented again. |
1082 |
|
|
Usually, client programs increment \f[C]eclock\f[R] each time |
1083 |
|
|
definitions or internal states affecting returned values change. |
1084 |
|
|
This assures the quickest evaluation of correct results. |
1085 |
|
|
.RS 3 |
1086 |
|
|
.RE |
1087 |
|
|
.LP |
1088 |
|
|
The usual approach to handling definitions is to compile them into the |
1089 |
|
|
central lookup table; variable and function references are later |
1090 |
|
|
evaluated by traversing the stored parse trees. |
1091 |
|
|
Syntax errors and undefined symbol errors during evaluation result in |
1092 |
|
|
calls to the user-definable routine \f[C]eputs(s)\f[R] to report the |
1093 |
|
|
error and \f[C]quit(status)\f[R] to exit the program. |
1094 |
|
|
Domain and range errors during evaluation set \f[C]errno\f[R], then call |
1095 |
|
|
the user-definable routine \f[C]wputs(s)\f[R] to report the error and |
1096 |
|
|
return zero as the expression result. |
1097 |
|
|
Following are standard routines provided for parsing from a file and |
1098 |
|
|
parsing from a string: |
1099 |
|
|
.IP "\f[B]\f[CB]EPNODE *eparse(char *expr);\f[B]\f[R]" 3 |
1100 |
|
|
Compile the string expr into a parse tree for later evaluation with |
1101 |
|
|
evalue(ep). |
1102 |
|
|
.RS 3 |
1103 |
|
|
.RE |
1104 |
|
|
.IP "\f[B]\f[CB]epfree(EPNODE *ep);\f[B]\f[R]" 3 |
1105 |
|
|
Free memory associated with ep, including any variables referenced if |
1106 |
|
|
they are no longer defined. |
1107 |
|
|
.RS 3 |
1108 |
|
|
.RE |
1109 |
|
|
.IP "\f[B]\f[CB]double eval(char *expr);\f[B]\f[R]" 3 |
1110 |
|
|
Immediately parse, evaluate and free the given string expression. |
1111 |
|
|
.RS 3 |
1112 |
|
|
.RE |
1113 |
|
|
.IP "\f[B]\f[CB]fcompile(char *fname);\f[B]\f[R]" 3 |
1114 |
|
|
Compile definitions from the given file, or standard input if fname is |
1115 |
|
|
NULL. |
1116 |
|
|
.RS 3 |
1117 |
|
|
.RE |
1118 |
|
|
.IP "\f[B]\f[CB]scompile(char *str, char *fn, int ln);\f[B]\f[R]" 3 |
1119 |
|
|
Compile definitions from the string str, taken from file fn at line |
1120 |
|
|
number ln. |
1121 |
|
|
If no file is associated, fn can be NULL, and ln can be 0. |
1122 |
|
|
.RS 3 |
1123 |
|
|
.RE |
1124 |
|
|
.LP |
1125 |
|
|
The following routines allow one to control the current context for |
1126 |
|
|
definition lookup and storage: |
1127 |
|
|
.IP "\f[B]\f[CB]char *setcontext(char *ctx);\f[B]\f[R]" 3 |
1128 |
|
|
Set the current context to ctx. |
1129 |
|
|
If ctx is NULL, then simply return the current context. |
1130 |
|
|
An empty string sets the global context. |
1131 |
|
|
.RS 3 |
1132 |
|
|
.RE |
1133 |
|
|
.IP "\f[B]\f[CB]char *pushcontext(char *name);\f[B]\f[R]" 3 |
1134 |
|
|
Push another context onto the stack. |
1135 |
|
|
Return the new (full) context. |
1136 |
|
|
.RS 3 |
1137 |
|
|
.RE |
1138 |
|
|
.IP "\f[B]\f[CB]char *popcontext();\f[B]\f[R]" 3 |
1139 |
|
|
Pop the top context name off the stack. |
1140 |
|
|
Return the new (full) context. |
1141 |
|
|
.RS 3 |
1142 |
|
|
.RE |
1143 |
|
|
.LP |
1144 |
|
|
The following functions permit the explicit setting of variable and |
1145 |
|
|
function values: |
1146 |
|
|
.IP "\f[B]\f[CB]varset(char *vname, int assign, double val);\f[B]\f[R]" 3 |
1147 |
|
|
Set the specified variable to the given value, using a constant |
1148 |
|
|
assignment if assign is `:' or a regular one if it is `='. |
1149 |
|
|
This is always faster than compiling a string to do the same thing. |
1150 |
|
|
.RS 3 |
1151 |
|
|
.RE |
1152 |
|
|
.IP "\f[B]\f[CB]funset(char *fname, int nargs, int assign, double (*fptr)(char *fn));\f[B]\f[R]" 3 |
1153 |
|
|
Assign the specified library function, which takes a minimum of nargs |
1154 |
|
|
arguments. |
1155 |
|
|
The function will have the constant attribute if assign is `:', or not |
1156 |
|
|
if it is `='. |
1157 |
|
|
The only argument to the referenced function pointer is the function |
1158 |
|
|
name, which will equal fname. |
1159 |
|
|
(This string must therefore be declared static.) |
1160 |
|
|
This offers a convenient method to identify calls to an identical |
1161 |
|
|
function assigned multiple tasks. |
1162 |
|
|
Argument values are obtained with calls back to the argument(n) library |
1163 |
|
|
function. |
1164 |
|
|
.RS 3 |
1165 |
|
|
.RE |
1166 |
|
|
.LP |
1167 |
|
|
The following functions are provided for evaluating a function or |
1168 |
|
|
variable in the current definition set: |
1169 |
|
|
.IP "\f[B]\f[CB]double varvalue(char *vname);\f[B]\f[R]" 3 |
1170 |
|
|
Evaluate the given variable and return the result. |
1171 |
|
|
Since a hash lookup is necessary to resolve the reference, this is |
1172 |
|
|
slightly less efficient than evaluating a compiled expression via |
1173 |
|
|
evalue(ep), which uses soft links generated and maintained during |
1174 |
|
|
compilation. |
1175 |
|
|
.RS 3 |
1176 |
|
|
.RE |
1177 |
|
|
.IP "\f[B]\f[CB]double funvalue(char *fn, int n, double a);\f[B]\f[R]" 3 |
1178 |
|
|
Evaluate the function fn, passing n real arguments in the array a. |
1179 |
|
|
There is currently no mechanism for passing functions or function name |
1180 |
|
|
arguments from client programs. |
1181 |
|
|
.RS 3 |
1182 |
|
|
.RE |
1183 |
|
|
.LP |
1184 |
|
|
These routines can be used to check the existence of a specific function |
1185 |
|
|
or variable: |
1186 |
|
|
.IP "\f[B]\f[CB]int vardefined(char *vname);\f[B]\f[R]" 3 |
1187 |
|
|
Return non-zero if the named variable is defined. |
1188 |
|
|
(If the symbol is defined as a function, zero is returned.) |
1189 |
|
|
.RS 3 |
1190 |
|
|
.RE |
1191 |
|
|
.IP "\f[B]\f[CB]int fundefined(char *fname);\f[B]\f[R]" 3 |
1192 |
|
|
Return the number of required arguments for the named function if it is |
1193 |
|
|
defined, or zero if it is not defined. |
1194 |
|
|
(If the symbol is defined as a variable, zero is returned.) |
1195 |
|
|
.RS 3 |
1196 |
|
|
.RE |
1197 |
|
|
.LP |
1198 |
|
|
These routines allow definitions to be cleared: |
1199 |
|
|
.IP "\f[B]\f[CB]dclear(char *dname);\f[B]\f[R]" 3 |
1200 |
|
|
Clear the given variable or function, unless it is a constant |
1201 |
|
|
expression. |
1202 |
|
|
.RS 3 |
1203 |
|
|
.RE |
1204 |
|
|
.IP "\f[B]\f[CB]dremove(char *dname);\f[B]\f[R]" 3 |
1205 |
|
|
Clear the given variable or function, even if it is a constant |
1206 |
|
|
expression. |
1207 |
|
|
Library definitions cannot be removed, except by calling funset with a |
1208 |
|
|
\f[C]NULL\f[R] pointer for the function argument. |
1209 |
|
|
.RS 3 |
1210 |
|
|
.RE |
1211 |
|
|
.IP "\f[B]\f[CB]dcleanup(int level);\f[B]\f[R]" 3 |
1212 |
|
|
Clear definitions. |
1213 |
|
|
If level is 0, then just clear variable definitions. |
1214 |
|
|
If level is 2, then clear constants as well. |
1215 |
|
|
If the current context is local, then only local definitions will be |
1216 |
|
|
affected. |
1217 |
|
|
If global, all definitions in all contexts will be affected. |
1218 |
|
|
.RS 3 |
1219 |
|
|
.RE |
1220 |
|
|
.LP |
1221 |
|
|
These routines may be used during library function evaluation: |
1222 |
|
|
.IP "\f[B]\f[CB]int nargum();\f[B]\f[R]" 3 |
1223 |
|
|
Determine the number of arguments available in the current function |
1224 |
|
|
evaluation context. |
1225 |
|
|
.RS 3 |
1226 |
|
|
.RE |
1227 |
|
|
.IP "\f[B]\f[CB]double argument(int n);\f[B]\f[R]" 3 |
1228 |
|
|
Evaluate and return the nth argument. |
1229 |
|
|
.RS 3 |
1230 |
|
|
.RE |
1231 |
|
|
.IP "\f[B]\f[CB]char *argfun(n);\f[B]\f[R]" 3 |
1232 |
|
|
Get the name of the function passed as argument n.\ (Generates an error |
1233 |
|
|
if the nth argument is not a function.) |
1234 |
|
|
.RS 3 |
1235 |
|
|
.RE |
1236 |
|
|
.LP |
1237 |
|
|
Other, even more specialized routines are provided for controlling the |
1238 |
|
|
parsing process, printing out expressions and sifting through stored |
1239 |
|
|
definitions, but these are not accessed by most client programs. |
1240 |
|
|
Worth noting are the various compile flags that affect which features of |
1241 |
|
|
the expression language are included. |
1242 |
|
|
The standard library sets the flags \f[C]-DVARIABLE\f[R], |
1243 |
|
|
\f[C]-DFUNCTION\f[R], \f[C]-DRCONST\f[R], and \f[C]-DBIGLIB\f[R]. |
1244 |
|
|
Here is a list of compile flags and their meanings: |
1245 |
|
|
.IP "\f[B]\f[CB]-DVARIABLE\f[B]\f[R]" 3 |
1246 |
|
|
Allow user-defined variables and (if \f[C]-DFUNCTION\f[R]) user- defined |
1247 |
|
|
functions. |
1248 |
|
|
.RS 3 |
1249 |
|
|
.RE |
1250 |
|
|
.IP "\f[B]\f[CB]-DFUNCTION\f[B]\f[R]" 3 |
1251 |
|
|
Compile in library functions and (if \f[C]-DVARIABLE\f[R]) allow |
1252 |
|
|
user-supplied function definitions. |
1253 |
|
|
.RS 3 |
1254 |
|
|
.RE |
1255 |
|
|
.IP "\f[B]\f[CB]-DBIGLIB\f[B]\f[R]" 3 |
1256 |
|
|
Include larger library of standard functions, i.e., standard C math |
1257 |
|
|
library. |
1258 |
|
|
Otherwise, only minimal library is compiled in, and other functions may |
1259 |
|
|
be added using \f[C]funset\f[R]. |
1260 |
|
|
.RS 3 |
1261 |
|
|
.RE |
1262 |
|
|
.IP "\f[B]\f[CB]-DRCONST\f[B]\f[R]" 3 |
1263 |
|
|
Reduce constant subexpressions during compilation. |
1264 |
|
|
This can result in substantial savings during later evaluation, but the |
1265 |
|
|
original user-supplied expressions are lost. |
1266 |
|
|
.RS 3 |
1267 |
|
|
.RE |
1268 |
|
|
.IP "\f[B]\f[CB]-DREDEFW\f[B]\f[R]" 3 |
1269 |
|
|
Issue a warning via \f[C]wputs(s)\f[R] if a new definition hides a |
1270 |
|
|
constant definition or library function, or replaces an existing, |
1271 |
|
|
distinct definition for the same symbol. |
1272 |
|
|
(The \f[C]varset\f[R] routine never generates warnings, however.) |
1273 |
|
|
.RS 3 |
1274 |
|
|
.RE |
1275 |
|
|
.IP "\f[B]\f[CB]-DINCHAN\f[B]\f[R]" 3 |
1276 |
|
|
Provide for \f[C]\[rs]$N\f[R] syntax for input channels, which result in |
1277 |
|
|
callbacks to client-supplied chanvalue(n) routine on each evaluation. |
1278 |
|
|
.RS 3 |
1279 |
|
|
.RE |
1280 |
|
|
.IP "\f[B]\f[CB]-DOUTCHAN\f[B]\f[R]" 3 |
1281 |
|
|
Provide for \f[C]\[rs]$N\f[R] lvalue syntax for output channels, which |
1282 |
|
|
are evaluated via the chanout(cs) library function, which calls |
1283 |
|
|
\f[C](*cs)(n, value)\f[R]for each assigned channel definition. |
1284 |
|
|
.RS 3 |
1285 |
|
|
.RE |
1286 |
|
|
.SH 2 |
1287 |
|
|
Data File Format (.dat suffix) |
1288 |
|
|
.pdfhref O 2 "Data File Format \(.dat suffix\)" |
1289 |
|
|
.pdfhref M "data-file-format-.dat-suffix" |
1290 |
|
|
.LP |
1291 |
|
|
Although it is possible to store tabular data in a function file using |
1292 |
|
|
the select library function, it is more convenient and efficient to |
1293 |
|
|
devote a special file format to this purpose. |
1294 |
|
|
\f[I]Radiance\f[R] data files store scalar values on an N-dimensional |
1295 |
|
|
rectangular grid. |
1296 |
|
|
Grid (independent) axes may be regularly or irregularly divided, as |
1297 |
|
|
shown in Figure 1. |
1298 |
|
|
This data is interpolated during rendering (using N-dimensional linear |
1299 |
|
|
interpolation) to compute the desired values. |
1300 |
|
|
.PSPIC "figure1.eps" |
1301 |
|
|
.ce 1000 |
1302 |
|
|
Division of axes in .dat file |
1303 |
|
|
.ce 0 |
1304 |
|
|
.PP |
1305 |
|
|
\f[B]Figure 1.\f[R] A 2-dimensional grid with one regularly divided axis |
1306 |
|
|
and one irregularly divided axis. |
1307 |
|
|
Each intersection corresponds to a data value that appears in the file. |
1308 |
|
|
.PP |
1309 |
|
|
Data files are broken into two sections, the header and the body. |
1310 |
|
|
The header specifies the grid, and the body contains the data values in |
1311 |
|
|
a standard order. |
1312 |
|
|
The first value in the file is a positive integer indicating the number |
1313 |
|
|
of dimensions. |
1314 |
|
|
Next comes that number of axis specifications, in one of two formats. |
1315 |
|
|
For a regularly divided axis, the starting and ending value is given, |
1316 |
|
|
followed by the number of divisions. |
1317 |
|
|
For an irregularly divided axis, two zeros are followed by the number of |
1318 |
|
|
divisions then that number of division values. |
1319 |
|
|
The two zeros are merely there to indicate an irregular spacing is being |
1320 |
|
|
specified. |
1321 |
|
|
Once all the axes have been given, the header is done and the body of |
1322 |
|
|
the file begins, which consists of one data value after another. |
1323 |
|
|
The ordering of the data is such that the last axis given is the one |
1324 |
|
|
being traversed most rapidly, similar to a static array assignment in C. |
1325 |
|
|
.PP |
1326 |
|
|
A file corresponding to the topology shown in Figure 1 is: |
1327 |
|
|
.IP |
1328 |
|
|
.nf |
1329 |
|
|
\f[C] |
1330 |
|
|
######### Header ######## |
1331 |
|
|
2 # Two-dimensional data array |
1332 |
|
|
0.5 0.1 5 # The regularly spaced axis |
1333 |
|
|
0 0 5 3 5 10 16 20 # The irregularly spaced axis |
1334 |
|
|
########## Body ######### |
1335 |
|
|
# The data values, starting with the |
1336 |
|
|
# upper left, moving right then down: |
1337 |
|
|
19.089 7.001 14.647 6.3671 8.0003 |
1338 |
|
|
3.8388 11.873 19.294 16.605 2.7435 |
1339 |
|
|
16.699 6.387 2.8123 16.195 17.615 |
1340 |
|
|
14.36 14.413 16.184 15.635 4.5403 |
1341 |
|
|
3.6740 14.550 10.332 15.932 1.2678 |
1342 |
|
|
\f[] |
1343 |
|
|
.fi |
1344 |
|
|
.LP |
1345 |
|
|
Comments begin with a pound sign (`#') and continue to the end of the |
1346 |
|
|
line. |
1347 |
|
|
White space is ignored except as a data separator, thus the position of |
1348 |
|
|
header and data values on each line is irrelevant except to improve |
1349 |
|
|
readability. |
1350 |
|
|
.SH 3 |
1351 |
|
|
\f[BI]Radiance\f[B] Programs |
1352 |
|
|
.pdfhref O 3 "Radiance Programs" |
1353 |
|
|
.pdfhref M "radiance-programs-2" |
1354 |
|
|
.LP |
1355 |
|
|
Table 3 shows \f[I]Radiance\f[R] programs that read and write data |
1356 |
|
|
files. |
1357 |
|
|
.PP |
1358 |
|
|
.na |
1359 |
|
|
.TS |
1360 |
|
|
delim(@@) tab( ); |
1361 |
|
|
l l l l. |
1362 |
|
|
T{ |
1363 |
|
|
Program |
1364 |
|
|
T} T{ |
1365 |
|
|
Read |
1366 |
|
|
T} T{ |
1367 |
|
|
Write |
1368 |
|
|
T} T{ |
1369 |
|
|
Function |
1370 |
|
|
T} |
1371 |
|
|
_ |
1372 |
|
|
T{ |
1373 |
|
|
\f[B]ies2rad\f[R] |
1374 |
|
|
T} T{ |
1375 |
|
|
T} T{ |
1376 |
|
|
X |
1377 |
|
|
T} T{ |
1378 |
|
|
Convert IES luminaire file to \f[I]Radiance\f[R] |
1379 |
|
|
T} |
1380 |
|
|
T{ |
1381 |
|
|
\f[B]mgf2rad\f[R] |
1382 |
|
|
T} T{ |
1383 |
|
|
T} T{ |
1384 |
|
|
X |
1385 |
|
|
T} T{ |
1386 |
|
|
Convert MGF file to \f[I]Radiance\f[R] |
1387 |
|
|
T} |
1388 |
|
|
T{ |
1389 |
|
|
\f[B]rpict\f[R] |
1390 |
|
|
T} T{ |
1391 |
|
|
X |
1392 |
|
|
T} T{ |
1393 |
|
|
T} T{ |
1394 |
|
|
Batch rendering program |
1395 |
|
|
T} |
1396 |
|
|
T{ |
1397 |
|
|
\f[B]rtrace\f[R] |
1398 |
|
|
T} T{ |
1399 |
|
|
X |
1400 |
|
|
T} T{ |
1401 |
|
|
T} T{ |
1402 |
|
|
Customizable ray-tracer |
1403 |
|
|
T} |
1404 |
|
|
T{ |
1405 |
|
|
\f[B]rview\f[R] |
1406 |
|
|
T} T{ |
1407 |
|
|
X |
1408 |
|
|
T} T{ |
1409 |
|
|
T} T{ |
1410 |
|
|
Interactive renderer |
1411 |
|
|
T} |
1412 |
|
|
.TE |
1413 |
|
|
.ad |
1414 |
|
|
.LP |
1415 |
|
|
\f[B]Table 3.\f[R] Programs in the \f[I]Radiance\f[R] distribution that |
1416 |
|
|
read and write data files. |
1417 |
|
|
.SH 3 |
1418 |
|
|
\f[BI]Radiance\f[B] C Library |
1419 |
|
|
.pdfhref O 3 "Radiance C Library" |
1420 |
|
|
.pdfhref M "radiance-c-library-2" |
1421 |
|
|
.LP |
1422 |
|
|
The header file \f[C]src/rt/data.h\f[R] gives the standard data |
1423 |
|
|
structures used by the routines in \f[C]src/rt/data.c\f[R] for reading |
1424 |
|
|
and interpolating data files. |
1425 |
|
|
The main data type is \f[C]DATARRAY\f[R], which is a structure |
1426 |
|
|
containing the grid specification and a pointer to the data array, which |
1427 |
|
|
is of the type \f[C]DATATYPE\f[R] (normally \f[B]float\f[R] to save |
1428 |
|
|
space). |
1429 |
|
|
.PP |
1430 |
|
|
The main routine for reading data files is \f[C]getdata(dname)\f[R], |
1431 |
|
|
which searches the standard \f[I]Radiance\f[R] library locations set by |
1432 |
|
|
the \f[C]RAYPATH\f[R] environment variable. |
1433 |
|
|
The return value is a pointer to the loaded \f[C]DATARRAY\f[R], which |
1434 |
|
|
may have been loaded by a previous call. |
1435 |
|
|
(The routine keeps a hash table of loaded files to minimize time and |
1436 |
|
|
memory requirements.) |
1437 |
|
|
The \f[C]freedata(dname)\f[R] routine frees memory associated with the |
1438 |
|
|
named data file, or all data arrays if \f[C]dname\f[R] is |
1439 |
|
|
\f[C]NULL\f[R]. |
1440 |
|
|
.PP |
1441 |
|
|
The routine that interpolates data values is \f[C]datavalue(dp,pt)\f[R], |
1442 |
|
|
which takes a \f[C]DATARRAY\f[R] pointer and an array of |
1443 |
|
|
\f[B]double\f[R]s of the appropriate length (the number of dimensions in |
1444 |
|
|
\f[C]dp\f[R]). |
1445 |
|
|
The \f[B]double\f[R] returned is the interpolated value at that point in |
1446 |
|
|
the scalar field. |
1447 |
|
|
If the requested point lies outside the data\[cq]s grid, it is |
1448 |
|
|
extrapolated from the perimeter values up to a distance of one division |
1449 |
|
|
in each dimension, and falls off harmonically to zero outside of that. |
1450 |
|
|
This was selected as the most robust compromise, but to be safe it is |
1451 |
|
|
generally best to avoid giving out-of-domain points to |
1452 |
|
|
\f[C]datavalue\f[R]. |
1453 |
|
|
.SH 2 |
1454 |
|
|
Font File Format (.fnt suffix) |
1455 |
|
|
.pdfhref O 2 "Font File Format \(.fnt suffix\)" |
1456 |
|
|
.pdfhref M "font-file-format-.fnt-suffix" |
1457 |
|
|
.LP |
1458 |
|
|
Font files are used for text patterns and mixtures, and by the |
1459 |
|
|
\f[B]psign\f[R] program to generate simple text labels. |
1460 |
|
|
Each character glyph is set up on a simple rectangular coordinate system |
1461 |
|
|
running from [0,255] in x and y, and the glyph itself is a polygon. |
1462 |
|
|
Figure 2 shows an example of the letter \[lq]A\[rq]. |
1463 |
|
|
.PSPIC "figure2.eps" |
1464 |
|
|
.ce 1000 |
1465 |
|
|
Drawing of an A, based on coordinates |
1466 |
|
|
.ce 0 |
1467 |
|
|
.PP |
1468 |
|
|
\f[B]Figure 2.\f[R] A glyph for an \[lq]A\[rq] character in standard |
1469 |
|
|
font coordinates. |
1470 |
|
|
Note that the hole is made via a seam, just as with \f[I]Radiance\f[R] |
1471 |
|
|
scene polygons. |
1472 |
|
|
The actual aspect and spacing of the character will be determined by the |
1473 |
|
|
client program. |
1474 |
|
|
.PP |
1475 |
|
|
Each glyph begins with the decimal value of that character\[cq]s index, |
1476 |
|
|
which is 65 for \[lq]A\[rq] according to the ASCII standard. |
1477 |
|
|
This is followed by the number of vertices, then the vertices themselves |
1478 |
|
|
in @left ( x sub 1 , y sub 1 right ) , left ( x sub 2 , y sub 2 right )@ |
1479 |
|
|
order. |
1480 |
|
|
White space again serves as a separator, and comments may begin with a |
1481 |
|
|
pound sign (`#') and continue to the end of line. |
1482 |
|
|
Here is the glyph entry for the letter \[lq]A\[rq] corresponding to |
1483 |
|
|
Figure 2: |
1484 |
|
|
.IP |
1485 |
|
|
.nf |
1486 |
|
|
\f[C] |
1487 |
|
|
65 15 # Helvetica \[dq]A\[dq] |
1488 |
|
|
155 222 242 48 185 48 168 86 |
1489 |
|
|
83 86 65 48 12 48 101 222 |
1490 |
|
|
155 222 128 179 126 179 97 116 |
1491 |
|
|
155 116 128 179 155 222 |
1492 |
|
|
\f[] |
1493 |
|
|
.fi |
1494 |
|
|
.LP |
1495 |
|
|
If the number of vertices given is zero, then the character is a space. |
1496 |
|
|
This is not the same as no entry, which means there is no valid glyph |
1497 |
|
|
for that character. |
1498 |
|
|
Glyphs may appear in any order, with indices ranging from 0 to 255. |
1499 |
|
|
The maximum number of vertices for a single glyph is 32767. |
1500 |
|
|
.PP |
1501 |
|
|
Two standard font files are provided, \f[C]helvet.fnt\f[R] and |
1502 |
|
|
\f[C]hexbit4x1.fnt\f[R]. |
1503 |
|
|
The former is a Helvetica font from the public domain Hershey font set. |
1504 |
|
|
The second is a simple bit pattern font for hexadecimal encodings of |
1505 |
|
|
bitmaps. |
1506 |
|
|
.SH 3 |
1507 |
|
|
\f[BI]Radiance\f[B] Programs |
1508 |
|
|
.pdfhref O 3 "Radiance Programs" |
1509 |
|
|
.pdfhref M "radiance-programs-3" |
1510 |
|
|
.LP |
1511 |
|
|
Table 4 shows \f[I]Radiance\f[R] programs that read and write font |
1512 |
|
|
files. |
1513 |
|
|
.PP |
1514 |
|
|
.na |
1515 |
|
|
.TS |
1516 |
|
|
delim(@@) tab( ); |
1517 |
|
|
l l l l. |
1518 |
|
|
T{ |
1519 |
|
|
Program |
1520 |
|
|
T} T{ |
1521 |
|
|
Read |
1522 |
|
|
T} T{ |
1523 |
|
|
Write |
1524 |
|
|
T} T{ |
1525 |
|
|
Function |
1526 |
|
|
T} |
1527 |
|
|
_ |
1528 |
|
|
T{ |
1529 |
|
|
\f[B]pcompos\f[R] |
1530 |
|
|
T} T{ |
1531 |
|
|
X |
1532 |
|
|
T} T{ |
1533 |
|
|
T} T{ |
1534 |
|
|
Compose \f[I]Radiance\f[R] pictures |
1535 |
|
|
T} |
1536 |
|
|
T{ |
1537 |
|
|
\f[B]psign\f[R] |
1538 |
|
|
T} T{ |
1539 |
|
|
X |
1540 |
|
|
T} T{ |
1541 |
|
|
T} T{ |
1542 |
|
|
Generate \f[I]Radiance\f[R] picture label |
1543 |
|
|
T} |
1544 |
|
|
T{ |
1545 |
|
|
\f[B]rpict\f[R] |
1546 |
|
|
T} T{ |
1547 |
|
|
X |
1548 |
|
|
T} T{ |
1549 |
|
|
T} T{ |
1550 |
|
|
Batch rendering program |
1551 |
|
|
T} |
1552 |
|
|
T{ |
1553 |
|
|
\f[B]rtrace\f[R] |
1554 |
|
|
T} T{ |
1555 |
|
|
X |
1556 |
|
|
T} T{ |
1557 |
|
|
T} T{ |
1558 |
|
|
Customizable ray-tracer |
1559 |
|
|
T} |
1560 |
|
|
T{ |
1561 |
|
|
\f[B]rview\f[R] |
1562 |
|
|
T} T{ |
1563 |
|
|
X |
1564 |
|
|
T} T{ |
1565 |
|
|
T} T{ |
1566 |
|
|
Interactive renderer |
1567 |
|
|
T} |
1568 |
|
|
.TE |
1569 |
|
|
.ad |
1570 |
|
|
.LP |
1571 |
|
|
\f[B]Table 4.\f[R] Programs in the \f[I]Radiance\f[R] distribution that |
1572 |
|
|
read and write font files. |
1573 |
|
|
.SH 3 |
1574 |
|
|
\f[BI]Radiance\f[B] C Library |
1575 |
|
|
.pdfhref O 3 "Radiance C Library" |
1576 |
|
|
.pdfhref M "radiance-c-library-3" |
1577 |
|
|
.LP |
1578 |
|
|
Similar to data files, font files are usually read and stored in a |
1579 |
|
|
lookup table. |
1580 |
greg |
1.2 |
The data structures for fonts are in \f[C]src/common/font.h\f[R], and |
1581 |
|
|
the routines for reading and spacing them are in |
1582 |
|
|
\f[C]src/common/font.c\f[R]. |
1583 |
greg |
1.1 |
The main structure type is \f[C]FONT\f[R]. |
1584 |
|
|
The routine \f[C]getfont(fname)\f[R] loads a font file from the |
1585 |
|
|
\f[I]Radiance\f[R] library (set by the \f[C]RAYPATH\f[R] environment |
1586 |
|
|
variable), and returns a pointer to the resulting \f[C]FONT\f[R] |
1587 |
|
|
structure. |
1588 |
|
|
If the file has been previously loaded, a pointer to the stored |
1589 |
|
|
structure is returned. |
1590 |
|
|
The \f[C]freefont(fname)\f[R] routine frees memory associated with the |
1591 |
|
|
named font file and deletes it from the table, or frees all font data if |
1592 |
|
|
\f[C]fname\f[R] is \f[C]NULL\f[R]. |
1593 |
|
|
.PP |
1594 |
|
|
Three different routines are available for text spacing. |
1595 |
|
|
The \f[C]uniftext(sp,tp,f\f[R]) function takes the nul-terminated string |
1596 |
|
|
\f[C]tp\f[R] and computes uniform per-character spacing for the font |
1597 |
|
|
\f[C]f\f[R], returned in the short integer array \f[C]sp\f[R]. |
1598 |
|
|
(This is a fairly simple process, and all spacing values will be 255 |
1599 |
|
|
unless a character has no corresponding glyph.) |
1600 |
|
|
The \f[C]squeeztext(sp,tp,f,cis)\f[R] performs a similar function, but |
1601 |
|
|
puts only \f[C]ci\f[R]s units between adjacent characters, based on the |
1602 |
|
|
actual width of each font glyph. |
1603 |
|
|
The most sophisticated spacing function is |
1604 |
|
|
\f[C]proptext(sp,tp,f,cis,nsi)\f[R], which produces a total line length |
1605 |
|
|
equal to what it would be with uniform spacing, while maintaining equal |
1606 |
|
|
inter-character spacing throughout (i.e., proportional spacing). |
1607 |
|
|
The \f[C]nsi\f[R] argument is the number of spaces (zero-vertex glyphs) |
1608 |
|
|
considered as an indent. |
1609 |
|
|
That is, if this many or more adjacent spaces occur in \f[C]tp\f[R], the |
1610 |
|
|
indented text following will appear at the same point as it would have |
1611 |
|
|
had the spacing been uniform. |
1612 |
|
|
This maintains columns in tabulated text despite the proportional |
1613 |
|
|
spacing. |
1614 |
|
|
Tabs are not understood or interpreted by any of these routines, and |
1615 |
|
|
must be expanded to the appropriate number of spaces via |
1616 |
|
|
\f[B]expand\f[R]. |
1617 |
|
|
.SH 3 |
1618 |
|
|
Octree Format (.oct suffix) |
1619 |
|
|
.pdfhref O 3 "Octree Format \(.oct suffix\)" |
1620 |
|
|
.pdfhref M "octree-format-.oct-suffix" |
1621 |
|
|
.LP |
1622 |
|
|
In \f[I]Radiance\f[R], octrees are used to accelerate ray intersection |
1623 |
|
|
calculations as described by Glassner [Glassner84]. |
1624 |
|
|
This data structure is computed by the \f[B]oconv\f[R] program, which |
1625 |
|
|
produces a binary file as its output. |
1626 |
|
|
An octree file contains a list of \f[I]Radiance\f[R] scene description |
1627 |
|
|
files (which may be empty), some information to guarantee portability |
1628 |
|
|
between systems and different versions of the code, followed by the |
1629 |
|
|
octree data itself. |
1630 |
|
|
If the octree file is \[lq]frozen,\[rq] then it will also contain the |
1631 |
|
|
scene data, compiled into a binary format for quick loading. |
1632 |
|
|
This is most convenient for octrees that are used in \f[I]instance\f[R] |
1633 |
|
|
primitives, which may be moved to a different (library) location from |
1634 |
|
|
the originating scene files. |
1635 |
|
|
.PP |
1636 |
|
|
An octree recursively subdivides 3-dimensional space into 8 subtrees, |
1637 |
|
|
hence its name. |
1638 |
|
|
Each \[lq]leaf\[rq] node contains between zero and \f[C]MAXSET\f[R] |
1639 |
|
|
surface primitives, indicating that section of space contains part or |
1640 |
|
|
all of those surfaces. |
1641 |
|
|
(Surface primitives may appear more than once in the octree.) |
1642 |
|
|
The goal of \f[B]oconv\f[R] is to build an octree that contains no more |
1643 |
|
|
than N surfaces in each leaf node, where N is set by the \f[B]-n\f[R] |
1644 |
|
|
option (5 by default). |
1645 |
|
|
It may allow more surfaces in places where the octree has reached its |
1646 |
|
|
maximum resolution (depth), set by the \f[B]-r\f[R] option (1024 \[em] |
1647 |
|
|
depth 10 by default). |
1648 |
|
|
Figure 3 shows a quadtree dividing 2-dimensional space, analogous to our |
1649 |
|
|
3-dimensional octree. |
1650 |
|
|
.PSPIC "figure3.eps" |
1651 |
|
|
.ce 1000 |
1652 |
|
|
A quadtree dividing two-dimensional space |
1653 |
|
|
.ce 0 |
1654 |
|
|
.PP |
1655 |
|
|
\f[B]Figure 3.\f[R] An example quadtree divided so that no leaf node |
1656 |
|
|
contains more than 2 objects. |
1657 |
|
|
A three-dimensional octree works the same way. |
1658 |
|
|
Each leaf node is either empty, or contains a list of intersecting |
1659 |
|
|
surfaces. |
1660 |
|
|
.SH 3 |
1661 |
|
|
Basic File Structure |
1662 |
|
|
.pdfhref O 3 "Basic File Structure" |
1663 |
|
|
.pdfhref M "basic-file-structure-1" |
1664 |
|
|
.LP |
1665 |
|
|
An octree file is divided into five sections: the information header, |
1666 |
|
|
the scene boundaries, the scene file names, the octree data structure, |
1667 |
|
|
and the compiled scene data. |
1668 |
|
|
If the octree is frozen, then the compiled scene data is included and |
1669 |
|
|
the scene file names are not. |
1670 |
|
|
Otherwise, the scene data is left off. |
1671 |
|
|
.SH 4 |
1672 |
|
|
Information Header |
1673 |
|
|
.pdfhref O 4 "Information Header" |
1674 |
|
|
.pdfhref M "information-header" |
1675 |
|
|
.LP |
1676 |
|
|
As with other binary \f[I]Radiance\f[R] formats, the beginning of an |
1677 |
|
|
octree file is the information header. |
1678 |
|
|
The first line is \[lq]#?RADIANCE\[rq] to aid in identification by the |
1679 |
|
|
UNIX \f[B]file\f[R] program. |
1680 |
|
|
Following this is the \f[B]oconv\f[R] command (or commands) used to |
1681 |
|
|
produce the octree, then a line indicating the format, |
1682 |
|
|
\f[C]FORMAT=Radiance_octree\f[R]. |
1683 |
|
|
The end of the information header is always an empty line. |
1684 |
|
|
Here is an example of an octree information header, as reported by |
1685 |
|
|
\f[B]getinfo\f[R]: |
1686 |
|
|
.IP |
1687 |
|
|
.nf |
1688 |
|
|
\f[C] |
1689 |
|
|
#?RADIANCE |
1690 |
|
|
oconv model.b90 desk misc |
1691 |
|
|
oconv -f -i modelb.oct window blinds lights lamp |
1692 |
|
|
FORMAT=Radiance_octree |
1693 |
|
|
\f[] |
1694 |
|
|
.fi |
1695 |
|
|
.LP |
1696 |
|
|
The actual content of this header is ignored when an octree is read |
1697 |
|
|
except for the \f[C]FORMAT\f[R] line, which if it appears must match the |
1698 |
|
|
one shown above. |
1699 |
|
|
.SH 4 |
1700 |
|
|
Scene Boundaries |
1701 |
|
|
.pdfhref O 4 "Scene Boundaries" |
1702 |
|
|
.pdfhref M "scene-boundaries" |
1703 |
|
|
.LP |
1704 |
|
|
After the information header, there is a magic number indicating the |
1705 |
|
|
format version and the size of object indices (in bytes per index). |
1706 |
|
|
This is a two-byte quantity, which must be one of the following in the |
1707 |
|
|
current release: |
1708 |
|
|
.PP |
1709 |
|
|
.na |
1710 |
|
|
.nr LLold \n[LL] |
1711 |
|
|
.TS |
1712 |
|
|
delim(@@) tab( ); |
1713 |
|
|
lw(35.0n) lw(35.0n). |
1714 |
|
|
T{ |
1715 |
|
|
.nr LL 35.0n |
1716 |
|
|
285 |
1717 |
|
|
T} T{ |
1718 |
|
|
.nr LL 35.0n |
1719 |
|
|
Two-byte object indices. |
1720 |
|
|
T} |
1721 |
|
|
T{ |
1722 |
|
|
.nr LL 35.0n |
1723 |
|
|
287 |
1724 |
|
|
T} T{ |
1725 |
|
|
.nr LL 35.0n |
1726 |
|
|
Four-byte object indices. |
1727 |
|
|
T} |
1728 |
|
|
T{ |
1729 |
|
|
.nr LL 35.0n |
1730 |
|
|
291 |
1731 |
|
|
T} T{ |
1732 |
|
|
.nr LL 35.0n |
1733 |
|
|
Eight-byte object indices. |
1734 |
|
|
(Only supported on architectures with 64-bit \f[B]longs\f[R].) |
1735 |
|
|
T} |
1736 |
|
|
.TE |
1737 |
|
|
.nr LL \n[LLold] |
1738 |
|
|
.ad |
1739 |
|
|
.LP |
1740 |
|
|
Technically, the code will also support odd-sized integers, but they are |
1741 |
|
|
not found on any existing machine architectures so we can forget about |
1742 |
|
|
them. |
1743 |
|
|
.PP |
1744 |
|
|
Following the octree magic number, we have the enclosing cube for the |
1745 |
|
|
scene, which defines the dimensions of the octree\[cq]s root node. |
1746 |
|
|
The cube is aligned along the world coordinate axes, so may be defined |
1747 |
|
|
by one corner (the 3-dimensional minimum) and the side length. |
1748 |
|
|
For historical reasons, these four values are stored as ASCII-encoded |
1749 |
|
|
real values in nul-terminated strings. |
1750 |
|
|
(The octree boundaries may also be read using \f[B]getinfo\f[R] with the |
1751 |
|
|
\f[B]-d\f[R] option.) |
1752 |
|
|
.SH 4 |
1753 |
|
|
Scene File Names |
1754 |
|
|
.pdfhref O 4 "Scene File Names" |
1755 |
|
|
.pdfhref M "scene-file-names" |
1756 |
|
|
.LP |
1757 |
|
|
Following the octree dimensions, the names of the scene description |
1758 |
|
|
files are given, each stored a nul-terminated string. |
1759 |
|
|
The end of this file list is indicated by an empty string. |
1760 |
|
|
If the octree is \[lq]frozen,\[rq] meaning it contains the compiled |
1761 |
|
|
scene information as well, then no file names will be present (i.e., the |
1762 |
|
|
first string will be empty). |
1763 |
|
|
.SH 4 |
1764 |
|
|
Octree Data Structure |
1765 |
|
|
.pdfhref O 4 "Octree Data Structure" |
1766 |
|
|
.pdfhref M "octree-data-structure" |
1767 |
|
|
.LP |
1768 |
|
|
After the scene description files, an N-byte integer indicates the total |
1769 |
|
|
number of primitives given to \f[B]oconv\f[R], where N is the size |
1770 |
|
|
derived from the magic number as we described. |
1771 |
|
|
This object count will be used to verify that the files have not changed |
1772 |
|
|
significantly since the octree was written\**. |
1773 |
|
|
.FS |
1774 |
|
|
Small changes that do not affect geometry will not cause problems, but |
1775 |
|
|
if the primitive count changes, so does the indexing of surfaces, and |
1776 |
|
|
with that the octree data structure becomes invalid. |
1777 |
|
|
A second check is made to insure that no non-surface primitives appear |
1778 |
|
|
in any leaf nodes, and this at least guarantees that the renderer will |
1779 |
|
|
not dump core from an outdated octree, even if the results are wrong. |
1780 |
|
|
.FE |
1781 |
|
|
.PP |
1782 |
|
|
After the primitive count, the actual octree is stored, using the |
1783 |
|
|
following recursive procedure: |
1784 |
|
|
.IP |
1785 |
|
|
.nf |
1786 |
|
|
\f[C] |
1787 |
|
|
puttree(ot) begin |
1788 |
|
|
if ot is a tree then |
1789 |
|
|
write the character \[aq]\[rs]002\[aq] |
1790 |
|
|
call puttree on each child node (0-7) else if ot is empty then |
1791 |
|
|
write the character \[aq]\[rs]000\[aq] |
1792 |
|
|
else |
1793 |
|
|
write the character \[aq]\[rs]001\[aq] |
1794 |
|
|
write out the number of surfaces |
1795 |
|
|
write out each surface\[aq]s index |
1796 |
|
|
end |
1797 |
|
|
end puttree |
1798 |
|
|
\f[] |
1799 |
|
|
.fi |
1800 |
|
|
.LP |
1801 |
|
|
The number of surfaces and the surface indices are each N-byte integers, |
1802 |
|
|
and the tree node types are single bytes. |
1803 |
|
|
Reading the octree is accomplished with a complementary procedure. |
1804 |
|
|
.SH 4 |
1805 |
|
|
Compiled Scene Data |
1806 |
|
|
.pdfhref O 4 "Compiled Scene Data" |
1807 |
|
|
.pdfhref M "compiled-scene-data" |
1808 |
|
|
.LP |
1809 |
|
|
If the octree is frozen, then this data structure is followed by a |
1810 |
|
|
compiled version of the scene. |
1811 |
|
|
This avoids the problems of changes to scene files, and allows an octree |
1812 |
|
|
to be moved conveniently from one location and one system to another |
1813 |
|
|
without worrying about the associated scene files. |
1814 |
|
|
.PP |
1815 |
|
|
The scene data begins with a listing of the defined primitive types. |
1816 |
|
|
This list consists of the name of each type as a nul-terminated string, |
1817 |
|
|
followed by an empty string once the list has been exhausted. |
1818 |
|
|
This permits the indexing of primitive types with a single byte later |
1819 |
|
|
on, without concern about changes to \f[I]Radiance\f[R] involving |
1820 |
|
|
\f[C]src/common/otypes.h\f[R]. |
1821 |
|
|
.PP |
1822 |
|
|
The scene primitives are written one at a time. |
1823 |
|
|
First is a single byte with the primitive type index, as determined from |
1824 |
|
|
the list given above. |
1825 |
|
|
Second is the N-byte modifier index, followed by the primitive\[cq]s |
1826 |
|
|
identifier as a nul-terminated string. |
1827 |
|
|
String arguments start with a 2-byte integer indicating the argument |
1828 |
|
|
count, followed by the strings themselves, which are nul-terminated. |
1829 |
|
|
Real arguments next have a 2-byte count followed by the real values, |
1830 |
|
|
each stored as a 4-byte mantissa followed by a 1-byte (signed) exponent. |
1831 |
|
|
(The mantissa is the numerator of a fraction of @2 sup 31 \[u2212] 1@.) |
1832 |
|
|
The end of data is indicated with a -1 value for the object type |
1833 |
|
|
(byte=255). |
1834 |
|
|
.SH 3 |
1835 |
|
|
\f[BI]Radiance\f[B] Programs |
1836 |
|
|
.pdfhref O 3 "Radiance Programs" |
1837 |
|
|
.pdfhref M "radiance-programs-4" |
1838 |
|
|
.LP |
1839 |
|
|
Table 5 shows \f[I]Radiance\f[R] programs that read and write octree |
1840 |
|
|
files. |
1841 |
|
|
.PP |
1842 |
|
|
.na |
1843 |
|
|
.TS |
1844 |
|
|
delim(@@) tab( ); |
1845 |
|
|
l l l l. |
1846 |
|
|
T{ |
1847 |
|
|
Program |
1848 |
|
|
T} T{ |
1849 |
|
|
Read |
1850 |
|
|
T} T{ |
1851 |
|
|
Write |
1852 |
|
|
T} T{ |
1853 |
|
|
Function |
1854 |
|
|
T} |
1855 |
|
|
_ |
1856 |
|
|
T{ |
1857 |
|
|
\f[B]getinfo\f[R] |
1858 |
|
|
T} T{ |
1859 |
|
|
X |
1860 |
|
|
T} T{ |
1861 |
|
|
T} T{ |
1862 |
|
|
Print information header from binary file |
1863 |
|
|
T} |
1864 |
|
|
T{ |
1865 |
|
|
\f[B]oconv\f[R] |
1866 |
|
|
T} T{ |
1867 |
|
|
X |
1868 |
|
|
T} T{ |
1869 |
|
|
X |
1870 |
|
|
T} T{ |
1871 |
|
|
Compile \f[I]Radiance\f[R] scene description |
1872 |
|
|
T} |
1873 |
|
|
T{ |
1874 |
|
|
\f[B]rad\f[R] |
1875 |
|
|
T} T{ |
1876 |
|
|
X |
1877 |
|
|
T} T{ |
1878 |
|
|
X |
1879 |
|
|
T} T{ |
1880 |
|
|
Render \f[I]Radiance\f[R] scene |
1881 |
|
|
T} |
1882 |
|
|
T{ |
1883 |
|
|
\f[B]rpict\f[R] |
1884 |
|
|
T} T{ |
1885 |
|
|
X |
1886 |
|
|
T} T{ |
1887 |
|
|
T} T{ |
1888 |
|
|
Batch rendering program |
1889 |
|
|
T} |
1890 |
|
|
T{ |
1891 |
|
|
\f[B]rpiece\f[R] |
1892 |
|
|
T} T{ |
1893 |
|
|
X |
1894 |
|
|
T} T{ |
1895 |
|
|
T} T{ |
1896 |
|
|
Parallel batch rendering program |
1897 |
|
|
T} |
1898 |
|
|
T{ |
1899 |
|
|
\f[B]rtrace\f[R] |
1900 |
|
|
T} T{ |
1901 |
|
|
X |
1902 |
|
|
T} T{ |
1903 |
|
|
T} T{ |
1904 |
|
|
Customizable ray-tracer |
1905 |
|
|
T} |
1906 |
|
|
T{ |
1907 |
|
|
\f[B]rview\f[R] |
1908 |
|
|
T} T{ |
1909 |
|
|
X |
1910 |
|
|
T} T{ |
1911 |
|
|
T} T{ |
1912 |
|
|
Interactive renderer |
1913 |
|
|
T} |
1914 |
|
|
.TE |
1915 |
|
|
.ad |
1916 |
|
|
.LP |
1917 |
|
|
\f[B]Table 5.\f[R] Programs in the \f[I]Radiance\f[R] distribution that |
1918 |
|
|
read and write octree files. |
1919 |
|
|
.SH 3 |
1920 |
|
|
\f[BI]Radiance\f[B] C Library |
1921 |
|
|
.pdfhref O 3 "Radiance C Library" |
1922 |
|
|
.pdfhref M "radiance-c-library-4" |
1923 |
|
|
.LP |
1924 |
|
|
Since reading an octree file also may involve reading a |
1925 |
|
|
\f[I]Radiance\f[R] scene description, some of the same library routines |
1926 |
|
|
are called indirectly. |
1927 |
|
|
The header file \f[C]src/common/octree.h\f[R] is needed in addition to |
1928 |
greg |
1.2 |
the \f[C]src/common/object.h\f[R] file. |
1929 |
greg |
1.1 |
The module \f[C]src/ot/writeoct.c\f[R] contains the main routines for |
1930 |
|
|
writing an octree to stdout, while \f[C]src/common/readoct.c\f[R] |
1931 |
|
|
contains the corresponding routines for reading an octree from a file. |
1932 |
|
|
Both modules access routines in \f[C]src/common/portio.c\f[R] for |
1933 |
|
|
reading and writing portable binary data. |
1934 |
|
|
.PP |
1935 |
|
|
Here is the main call for writing out an octree: |
1936 |
|
|
.IP "\f[B]\f[CB]writeoct(int store, CUBE *scene, char *ofn[]);\f[B]\f[R]" 3 |
1937 |
|
|
Write the octree stored in scene to stdout, assuming the header has |
1938 |
|
|
already been written. |
1939 |
|
|
The flags in store determine what will be included. |
1940 |
|
|
Normally, this variable is one of \f[C]IO_ALL\f[R] or |
1941 |
|
|
\f[C](IO_ALL & \[ti]IO_FILES)\f[R] correspondingto writing a normal or a |
1942 |
|
|
frozen octree, respectively. |
1943 |
|
|
.RS 3 |
1944 |
|
|
.RE |
1945 |
|
|
.LP |
1946 |
|
|
Here is the main call for reading in an octree: |
1947 |
|
|
.IP "\f[B]\f[CB]readoct(char *fname, int load, CUBE *scene, char *ofn[]);\f[B]\f[R]" 3 |
1948 |
|
|
Read the octree file fname into scene, saving scene file names in the |
1949 |
|
|
ofn array. |
1950 |
|
|
What is loaded depends on the flags in load,which may be one or more of |
1951 |
|
|
\f[C]IO_CHECK\f[R], \f[C]IO_INFO\f[R], \f[C]IO_SCENE\f[R], |
1952 |
|
|
\f[C]IO_TREE\f[R], \f[C]IO_FILES\f[R] and \f[C]IO_BOUNDS\f[R]. |
1953 |
|
|
These correspond to checking file type and consistency, transferring the |
1954 |
|
|
information header to stdout, loading the scene data, loading the octree |
1955 |
|
|
structure, assigning the scene file names to ofn, and assigning the |
1956 |
|
|
octree cube boundaries. |
1957 |
|
|
The macro \f[C]IO_ALL\f[R] includes all of these flags, for convenience. |
1958 |
|
|
.RS 3 |
1959 |
|
|
.RE |
1960 |
|
|
.SH 2 |
1961 |
|
|
Picture File Format (.hdr suffix) |
1962 |
|
|
.pdfhref O 2 "Picture File Format \(.hdr suffix\)" |
1963 |
|
|
.pdfhref M "picture-file-format-.hdr-suffix" |
1964 |
|
|
.LP |
1965 |
|
|
\f[I]Radiance\f[R] pictures\** |
1966 |
|
|
.FS |
1967 |
|
|
The picture filename extension used to be .pic, but that conflicted with |
1968 |
|
|
too many other programs. |
1969 |
|
|
It was replaced with .hdr, an abbreviation of \[lq]high dynamic |
1970 |
|
|
range.\[rq] |
1971 |
|
|
.FE |
1972 |
|
|
differ from standard computer graphics images inasmuch as they contain |
1973 |
|
|
real physical data, namely radiance values at each pixel. |
1974 |
|
|
To do this, it is necessary to maintain floating point information, and |
1975 |
|
|
we use a 4-byte/pixel encoding described in Chapter II.5 of Graphics |
1976 |
|
|
Gems II [Arvo91,p.80]. |
1977 |
|
|
The basic idea is to store a 1-byte mantissa for each of three |
1978 |
|
|
primaries, and a common 1-byte exponent. |
1979 |
|
|
The accuracy of these values will be on the order of 1% (±1 in 200) over |
1980 |
|
|
a dynamic range from 10\*{-38\*} to 10\*{38\*}. |
1981 |
|
|
.PP |
1982 |
|
|
Although \f[I]Radiance\f[R] pictures \f[I]may\f[R] contain physical |
1983 |
|
|
data, they do not \f[I]necessarily\f[R] contain physical data. |
1984 |
|
|
If the rendering did not use properly modeled light sources, or the |
1985 |
|
|
picture was converted from some other format, or custom filtering was |
1986 |
|
|
applied, then the physical data will be invalid. |
1987 |
|
|
Table 6 lists programs that read and write \f[I]Radiance\f[R] pictures, |
1988 |
|
|
with pluses next to the X-marks indicating where physical data is |
1989 |
|
|
preserved (or at least understood). |
1990 |
|
|
Specifically, if the picture file read or written by a program has an |
1991 |
|
|
\[lq]X+\[rq], then it has maintained the physical validity of the pixels |
1992 |
|
|
by keeping track of any exposure or color corrections in the appropriate |
1993 |
|
|
header variables, described below. |
1994 |
|
|
.SH 3 |
1995 |
|
|
Basic File Structure |
1996 |
|
|
.pdfhref O 3 "Basic File Structure" |
1997 |
|
|
.pdfhref M "basic-file-structure-2" |
1998 |
|
|
.LP |
1999 |
|
|
\f[I]Radiance\f[R] picture files are divided into three sections: the |
2000 |
|
|
information header, the resolution string, and the scanline records. |
2001 |
|
|
All of these must be present or the file is incomplete. |
2002 |
|
|
.SH 4 |
2003 |
|
|
Information Header |
2004 |
|
|
.pdfhref O 4 "Information Header" |
2005 |
|
|
.pdfhref M "information-header-1" |
2006 |
|
|
.LP |
2007 |
|
|
The information header begins with the usual \f[C]#?RADIANCE\f[R] |
2008 |
|
|
identifier, followed by one or more lines containing the programs used |
2009 |
|
|
to produce the picture. |
2010 |
|
|
These commands may be interspersed with variables describing relevant |
2011 |
|
|
information such as the view, exposure, color correction, and so on. |
2012 |
|
|
Variable assignments begin on a new line, and the variable name (usually |
2013 |
|
|
all upper case) is followed by an equals sign (`='), which is followed |
2014 |
|
|
by the assigned value up until the end of line. |
2015 |
|
|
Some variable assignments override previous assignments in the same |
2016 |
|
|
header, where other assignments are cumulative. |
2017 |
|
|
Here are the most important variables for \f[I]Radiance\f[R] pictures: |
2018 |
|
|
.IP "\f[B]\f[CB]FORMAT\f[B]\f[R]" 3 |
2019 |
|
|
A line indicating the file\[cq]s format. |
2020 |
|
|
At most one \f[C]FORMAT\f[R] line is allowed, and it must be assigned a |
2021 |
|
|
value of either \f[C]32- bit_rle_rgbe\f[R] or \f[C]32-bit_rle_xyze\f[R] |
2022 |
|
|
to be a valid \f[I]Radiance\f[R] picture. |
2023 |
|
|
.RS 3 |
2024 |
|
|
.RE |
2025 |
|
|
.IP "\f[B]\f[CB]EXPOSURE\f[B]\f[R]" 3 |
2026 |
|
|
A single floating point number indicating a multiplier that has been |
2027 |
|
|
applied to all the pixels in the file. |
2028 |
|
|
\f[C]EXPOSURE\f[R] values are cumulative, so the original pixel values |
2029 |
|
|
(i.e., radiances in w/sr/m\*{2\*}) must be derived by taking the values |
2030 |
|
|
in the file and dividing by all the \f[C]EXPOSURE\f[R] settings |
2031 |
|
|
multiplied together. |
2032 |
|
|
No \f[C]EXPOSURE\f[R] setting implies that no exposure changes have |
2033 |
|
|
taken place. |
2034 |
|
|
.RS 3 |
2035 |
|
|
.RE |
2036 |
|
|
.IP "\f[B]\f[CB]COLORCORR\f[B]\f[R]" 3 |
2037 |
|
|
A color correction multiplier that has been applied to this picture. |
2038 |
|
|
Similar to the \f[C]EXPOSURE\f[R] variable except given in three parts |
2039 |
|
|
for the three primaries. |
2040 |
|
|
In general, the value should have a brightness of unity, so that it does |
2041 |
|
|
not affect the actual brightness of pixels, which should be tracked by |
2042 |
|
|
\f[C]EXPOSURE\f[R] changes instead. |
2043 |
|
|
(This variable is also cumulative.) |
2044 |
|
|
.RS 3 |
2045 |
|
|
.RE |
2046 |
|
|
.IP "\f[B]\f[CB]SOFTWARE\f[B]\f[R]" 3 |
2047 |
|
|
The software version used to create the picture, usually something like |
2048 |
|
|
\f[C]RADIANCE 3.04 official release July 16, 1996\f[R]. |
2049 |
|
|
.RS 3 |
2050 |
|
|
.RE |
2051 |
|
|
.IP "\f[B]\f[CB]PIXASPECT\f[B]\f[R]" 3 |
2052 |
|
|
The pixel aspect ratio, expressed as a decimal fraction of the height of |
2053 |
|
|
each pixel to its width. |
2054 |
|
|
This is not to be confused with the image aspect ratio, which is the |
2055 |
|
|
total height over width. |
2056 |
|
|
(The image aspect ratio is actually equal to the height in pixels over |
2057 |
|
|
the width in pixels, \f[I]multiplied\f[R] by the pixel aspect ratio.) |
2058 |
|
|
These assignments are cumulative, so the actual pixel aspect ratio is |
2059 |
|
|
all ratios multiplied together. |
2060 |
|
|
If no \f[C]PIXASPECT\f[R] assignment appears, the ratio is assumed to be |
2061 |
|
|
1. |
2062 |
|
|
.RS 3 |
2063 |
|
|
.RE |
2064 |
|
|
.IP "\f[B]\f[CB]VIEW\f[B]\f[R]" 3 |
2065 |
|
|
The \f[I]Radiance\f[R] view parameters used to create this picture. |
2066 |
|
|
Multiple assignments are cumulative inasmuch as new view options add to |
2067 |
|
|
or override old ones. |
2068 |
|
|
.RS 3 |
2069 |
|
|
.RE |
2070 |
|
|
.LP |
2071 |
|
|
\f[C]PRIMARIES\f[R] The CIE (x,y) chromaticity coordinates of the three |
2072 |
|
|
(RGB) primaries and the white point used to standardize the |
2073 |
|
|
picture\[cq]s color system. |
2074 |
|
|
This is used mainly by the \f[B]ra_xyze\f[R] program to convert between |
2075 |
|
|
color systems. |
2076 |
|
|
If no \f[C]PRIMARIES\f[R] line appears, we assume the standard primaries |
2077 |
|
|
defined in \f[C]src/common/color.h\f[R], namely |
2078 |
|
|
\f[C]0.640 0.330 0.290 0.600 0.150 0.060 0.333 0.333\f[R] for red, |
2079 |
|
|
green, blue and white, respectively. |
2080 |
|
|
.PP |
2081 |
|
|
As always, the end of the header is indicated by an empty line. |
2082 |
|
|
.SH 4 |
2083 |
|
|
Resolution String |
2084 |
|
|
.pdfhref O 4 "Resolution String" |
2085 |
|
|
.pdfhref M "resolution-string" |
2086 |
|
|
.LP |
2087 |
|
|
All \f[I]Radiance\f[R] pictures have a standard coordinate system, which |
2088 |
|
|
is shown in Figure 4. |
2089 |
|
|
The origin is always at the lower left corner, with the X coordinate |
2090 |
|
|
increasing to the right, and the Y coordinate increasing in the upward |
2091 |
|
|
direction. |
2092 |
|
|
The actual ordering of pixels in the picture file, however, is addressed |
2093 |
|
|
by the resolution string. |
2094 |
|
|
.PSPIC "figure4.eps" |
2095 |
|
|
.ce 1000 |
2096 |
|
|
Radiance picture coordinate system |
2097 |
|
|
.ce 0 |
2098 |
|
|
.PP |
2099 |
|
|
\f[B]Figure 4.\f[R] The standard coordinate system for an MxN picture. |
2100 |
|
|
.PP |
2101 |
|
|
The resolution string is given as one of the following: |
2102 |
|
|
.IP "\f[B]\f[CB]-Y N +X M\f[B]\f[R]" 3 |
2103 |
|
|
The standard orientation produced by the renderers, indicating that Y is |
2104 |
|
|
decreasing in the file, and X is increasing. |
2105 |
|
|
X positions are increasing in each scanline, starting with the upper |
2106 |
|
|
left position in the picture and moving to the upper right initially, |
2107 |
|
|
then on down the picture. |
2108 |
|
|
Some programs will only handle pictures with this ordering. |
2109 |
|
|
.RS 3 |
2110 |
|
|
.RE |
2111 |
|
|
.IP "\f[B]\f[CB]-Y N -X M\f[B]\f[R]" 3 |
2112 |
|
|
The X ordering has been reversed, effectively flipping the image left to |
2113 |
|
|
right from the standard ordering. |
2114 |
|
|
.RS 3 |
2115 |
|
|
.RE |
2116 |
|
|
.IP "\f[B]\f[CB]+Y N -X M\f[B]\f[R]" 3 |
2117 |
|
|
The image has been flipped left to right and also top to bottom, which |
2118 |
|
|
is the same as rotating it by 180 degrees. |
2119 |
|
|
.RS 3 |
2120 |
|
|
.RE |
2121 |
|
|
.IP "\f[B]\f[CB]+Y N +X M\f[B]\f[R]" 3 |
2122 |
|
|
The image has been flipped top to bottom from the standard ordering. |
2123 |
|
|
.RS 3 |
2124 |
|
|
.RE |
2125 |
|
|
.IP "\f[B]\f[CB]+X M +Y N\f[B]\f[R]" 3 |
2126 |
|
|
The image has been rotated 90 degrees clockwise. |
2127 |
|
|
.RS 3 |
2128 |
|
|
.RE |
2129 |
|
|
.IP "\f[B]\f[CB]-X M +Y N\f[B]\f[R]" 3 |
2130 |
|
|
The image has been rotated 90 degrees clockwise, then flipped top to |
2131 |
|
|
bottom. |
2132 |
|
|
.RS 3 |
2133 |
|
|
.RE |
2134 |
|
|
.IP "\f[B]\f[CB]-X M -Y N\f[B]\f[R]" 3 |
2135 |
|
|
The image has been rotated 90 degrees counter-clockwise. |
2136 |
|
|
.RS 3 |
2137 |
|
|
.RE |
2138 |
|
|
.IP "\f[B]\f[CB]+X M -Y N\f[B]\f[R]" 3 |
2139 |
|
|
The image has been rotate 90 degrees counter-clockwise, then flipped top |
2140 |
|
|
to bottom. |
2141 |
|
|
.RS 3 |
2142 |
|
|
.RE |
2143 |
|
|
.LP |
2144 |
|
|
The reason for tracking all these changes in picture orientation is so |
2145 |
|
|
programs that compute ray origin and direction from the \f[C]VIEW\f[R] |
2146 |
|
|
variable in the information header will work despite such changes. |
2147 |
|
|
Also, it can reduce memory requirements on converting from other image |
2148 |
|
|
formats that have a different scanline ordering, such as Targa. |
2149 |
|
|
.SH 4 |
2150 |
|
|
Scanline Records |
2151 |
|
|
.pdfhref O 4 "Scanline Records" |
2152 |
|
|
.pdfhref M "scanline-records" |
2153 |
|
|
.LP |
2154 |
|
|
\f[I]Radiance\f[R] scanlines come in one of three flavors, described |
2155 |
|
|
below: |
2156 |
|
|
.IP "\f[B]Uncompressed\f[R]" 3 |
2157 |
|
|
Each scanline is represented by M pixels with 4 bytes per pixel, for a |
2158 |
|
|
total length of 4xM bytes. |
2159 |
|
|
This is the simplest format to read and write, since it has a one-to-one |
2160 |
|
|
correspondence to an array of \f[C]COLR\f[R] values. |
2161 |
|
|
.RS 3 |
2162 |
|
|
.RE |
2163 |
|
|
.IP "\f[B]Old run-length encoded\f[R]" 3 |
2164 |
|
|
Repeated pixel values are indicated by an illegal (i.e., unnormalized) |
2165 |
|
|
pixel that has 1\[cq]s for all three mantissas, and an exponent that |
2166 |
|
|
corresponds to the number of times the previous pixel is repeated. |
2167 |
|
|
Consecutive repeat indicators contain higher-order bytes of the count. |
2168 |
|
|
.RS 3 |
2169 |
|
|
.RE |
2170 |
|
|
.IP "\f[B]New run-length encoded\f[R]" 3 |
2171 |
|
|
In this format, the four scanline components (three primaries and |
2172 |
|
|
exponent) are separated for better compression using adaptive run-length |
2173 |
|
|
encoding (described by Glassner in Chapter II.8 of Graphics Gems II |
2174 |
|
|
[Arvo91,p.89]). |
2175 |
|
|
The record begins with an unnormalized pixel having two bytes equal to |
2176 |
|
|
2, followed by the upper byte and the lower byte of the scanline length |
2177 |
|
|
(which must be less than 32768). |
2178 |
|
|
A run is indicated by a byte with its high-order bit set, corresponding |
2179 |
|
|
to a count with excess 128. |
2180 |
|
|
A non-run is indicated with a byte less than 128. |
2181 |
|
|
The maximum compression ratio using this scheme is better than 100:1, |
2182 |
|
|
but typical performance for \f[I]Radiance\f[R] pictures is more like |
2183 |
|
|
2:1. |
2184 |
|
|
.RS 3 |
2185 |
|
|
.RE |
2186 |
|
|
.LP |
2187 |
|
|
The physical values these scanlines correspond to depend on the format |
2188 |
|
|
and other information contained in the information header. |
2189 |
|
|
If the \f[C]FORMAT\f[R] string indicates RGB data, then the units for |
2190 |
|
|
each primary are spectral radiances over the corresponding waveband, |
2191 |
|
|
such that a pixel value of @left ( 1 , 1 , 1 right )@ corresponds to a |
2192 |
|
|
total energy of 1 w/sr/m\*{2\*} over the visible spectrum. |
2193 |
|
|
The actual luminance value (in lm/sr/m\*{2\*}) can be computed from the |
2194 |
|
|
following formula for the standard \f[I]Radiance\f[R] RGB primaries: |
2195 |
|
|
.PP |
2196 |
|
|
.EQ |
2197 |
|
|
L sub v = 179 left ( 0.265 r + 0.670 g + 0.065 b right ) |
2198 |
|
|
.EN |
2199 |
|
|
.PP |
2200 |
|
|
The value of 179 lm/w is the standard \f[I]luminous efficacy\f[R] of |
2201 |
|
|
equal-energy white light that is defined and used by \f[I]Radiance\f[R] |
2202 |
|
|
specifically for this conversion. |
2203 |
|
|
This and the other values above are defined in |
2204 |
|
|
\f[C]src/common/color.h\f[R], and the above formula is given as a macro, |
2205 |
|
|
\f[C]luminance(col)\f[R]. |
2206 |
|
|
.PP |
2207 |
|
|
If the \f[C]FORMAT\f[R] string indicates XYZ data, then the units of the |
2208 |
|
|
Y primary are already lm/st/m\*{2\*}, so the above conversion is |
2209 |
|
|
unnecessary. |
2210 |
|
|
.SH 3 |
2211 |
|
|
\f[BI]Radiance\f[B] programs |
2212 |
|
|
.pdfhref O 3 "Radiance programs" |
2213 |
|
|
.pdfhref M "radiance-programs-5" |
2214 |
|
|
.LP |
2215 |
|
|
Table 6 shows the many programs that read and write \f[I]Radiance\f[R] |
2216 |
|
|
pictures. |
2217 |
|
|
.PP |
2218 |
|
|
.na |
2219 |
|
|
.TS |
2220 |
|
|
delim(@@) tab( ); |
2221 |
|
|
l l l l. |
2222 |
|
|
T{ |
2223 |
|
|
Program |
2224 |
|
|
T} T{ |
2225 |
|
|
Read |
2226 |
|
|
T} T{ |
2227 |
|
|
Write |
2228 |
|
|
T} T{ |
2229 |
|
|
Function |
2230 |
|
|
T} |
2231 |
|
|
_ |
2232 |
|
|
T{ |
2233 |
|
|
\f[B]falsecolor\f[R] |
2234 |
|
|
T} T{ |
2235 |
|
|
X+ |
2236 |
|
|
T} T{ |
2237 |
|
|
X |
2238 |
|
|
T} T{ |
2239 |
|
|
Create false color image |
2240 |
|
|
T} |
2241 |
|
|
T{ |
2242 |
|
|
\f[B]findglare\f[R] |
2243 |
|
|
T} T{ |
2244 |
|
|
X+ |
2245 |
|
|
T} T{ |
2246 |
|
|
T} T{ |
2247 |
|
|
Find sources of discomfort glare |
2248 |
|
|
T} |
2249 |
|
|
T{ |
2250 |
|
|
\f[B]getinfo\f[R] |
2251 |
|
|
T} T{ |
2252 |
|
|
X |
2253 |
|
|
T} T{ |
2254 |
|
|
T} T{ |
2255 |
|
|
Print information header from binary file |
2256 |
|
|
T} |
2257 |
|
|
T{ |
2258 |
|
|
\f[B]macbethcal\f[R] |
2259 |
|
|
T} T{ |
2260 |
|
|
X |
2261 |
|
|
T} T{ |
2262 |
|
|
X |
2263 |
|
|
T} T{ |
2264 |
|
|
Compute image color & contrast correction |
2265 |
|
|
T} |
2266 |
|
|
T{ |
2267 |
|
|
\f[B]normpat\f[R] |
2268 |
|
|
T} T{ |
2269 |
|
|
X |
2270 |
|
|
T} T{ |
2271 |
|
|
X |
2272 |
|
|
T} T{ |
2273 |
|
|
Normalize picture for use as pattern tile |
2274 |
|
|
T} |
2275 |
|
|
T{ |
2276 |
|
|
\f[B]objpict\f[R] |
2277 |
|
|
T} T{ |
2278 |
|
|
T} T{ |
2279 |
|
|
X |
2280 |
|
|
T} T{ |
2281 |
|
|
Generate composite picture of object |
2282 |
|
|
T} |
2283 |
|
|
T{ |
2284 |
|
|
\f[B]pcomb\f[R] |
2285 |
|
|
T} T{ |
2286 |
|
|
X+ |
2287 |
|
|
T} T{ |
2288 |
|
|
X |
2289 |
|
|
T} T{ |
2290 |
|
|
Perform arbitrary math on picture(s) |
2291 |
|
|
T} |
2292 |
|
|
T{ |
2293 |
|
|
\f[B]pcond\f[R] |
2294 |
|
|
T} T{ |
2295 |
|
|
X+ |
2296 |
|
|
T} T{ |
2297 |
|
|
X |
2298 |
|
|
T} T{ |
2299 |
|
|
Condition a picture for display |
2300 |
|
|
T} |
2301 |
|
|
T{ |
2302 |
|
|
\f[B]pcompos\f[R] |
2303 |
|
|
T} T{ |
2304 |
|
|
X |
2305 |
|
|
T} T{ |
2306 |
|
|
X |
2307 |
|
|
T} T{ |
2308 |
|
|
Composite pictures |
2309 |
|
|
T} |
2310 |
|
|
T{ |
2311 |
|
|
\f[B]pextrem\f[R] |
2312 |
|
|
T} T{ |
2313 |
|
|
X+ |
2314 |
|
|
T} T{ |
2315 |
|
|
T} T{ |
2316 |
|
|
Find minimum and maximum pixels |
2317 |
|
|
T} |
2318 |
|
|
T{ |
2319 |
|
|
\f[B]pfilt\f[R] |
2320 |
|
|
T} T{ |
2321 |
|
|
X+ |
2322 |
|
|
T} T{ |
2323 |
|
|
X+ |
2324 |
|
|
T} T{ |
2325 |
|
|
Filter and anti-alias picture |
2326 |
|
|
T} |
2327 |
|
|
T{ |
2328 |
|
|
\f[B]pflip\f[R] |
2329 |
|
|
T} T{ |
2330 |
|
|
X+ |
2331 |
|
|
T} T{ |
2332 |
|
|
X+ |
2333 |
|
|
T} T{ |
2334 |
|
|
Flip picture left-right and/or top-bottom |
2335 |
|
|
T} |
2336 |
|
|
T{ |
2337 |
|
|
\f[B]pinterp\f[R] |
2338 |
|
|
T} T{ |
2339 |
|
|
X+ |
2340 |
|
|
T} T{ |
2341 |
|
|
X+ |
2342 |
|
|
T} T{ |
2343 |
|
|
Interpolate/extrapolate picture views |
2344 |
|
|
T} |
2345 |
|
|
T{ |
2346 |
|
|
\f[B]protate\f[R] |
2347 |
|
|
T} T{ |
2348 |
|
|
X+ |
2349 |
|
|
T} T{ |
2350 |
|
|
X+ |
2351 |
|
|
T} T{ |
2352 |
|
|
Rotate picture 90 degrees clockwise |
2353 |
|
|
T} |
2354 |
|
|
T{ |
2355 |
|
|
\f[B]psign\f[R] |
2356 |
|
|
T} T{ |
2357 |
|
|
T} T{ |
2358 |
|
|
X |
2359 |
|
|
T} T{ |
2360 |
|
|
Create text picture |
2361 |
|
|
T} |
2362 |
|
|
T{ |
2363 |
|
|
\f[B]pvalue\f[R] |
2364 |
|
|
T} T{ |
2365 |
|
|
X+ |
2366 |
|
|
T} T{ |
2367 |
|
|
X+ |
2368 |
|
|
T} T{ |
2369 |
|
|
Convert picture to/from simpler formats |
2370 |
|
|
T} |
2371 |
|
|
T{ |
2372 |
|
|
\f[B]ra_avs\f[R] |
2373 |
|
|
T} T{ |
2374 |
|
|
X |
2375 |
|
|
T} T{ |
2376 |
|
|
X |
2377 |
|
|
T} T{ |
2378 |
|
|
Convert to/from AVS image format |
2379 |
|
|
T} |
2380 |
|
|
T{ |
2381 |
|
|
\f[B]ra_pict\f[R] |
2382 |
|
|
T} T{ |
2383 |
|
|
X |
2384 |
|
|
T} T{ |
2385 |
|
|
X |
2386 |
|
|
T} T{ |
2387 |
|
|
Convert to/from Macintosh PICT2 format |
2388 |
|
|
T} |
2389 |
|
|
T{ |
2390 |
|
|
\f[B]ra_ppm\f[R] |
2391 |
|
|
T} T{ |
2392 |
|
|
X |
2393 |
|
|
T} T{ |
2394 |
|
|
X |
2395 |
|
|
T} T{ |
2396 |
|
|
Convert to/from Poskanzer Port. |
2397 |
|
|
Pixmap |
2398 |
|
|
T} |
2399 |
|
|
T{ |
2400 |
|
|
\f[B]ra_pr\f[R] |
2401 |
|
|
T} T{ |
2402 |
|
|
X |
2403 |
|
|
T} T{ |
2404 |
|
|
X |
2405 |
|
|
T} T{ |
2406 |
|
|
Convert to/from Sun 8-bit rasterfile |
2407 |
|
|
T} |
2408 |
|
|
T{ |
2409 |
|
|
\f[B]ra_pr24\f[R] |
2410 |
|
|
T} T{ |
2411 |
|
|
X |
2412 |
|
|
T} T{ |
2413 |
|
|
X |
2414 |
|
|
T} T{ |
2415 |
|
|
Convert to/from Sun 24-bit rasterfile |
2416 |
|
|
T} |
2417 |
|
|
T{ |
2418 |
|
|
\f[B]ra_ps\f[R] |
2419 |
|
|
T} T{ |
2420 |
|
|
X |
2421 |
|
|
T} T{ |
2422 |
|
|
T} T{ |
2423 |
|
|
Convert to B&W or color PostScript |
2424 |
|
|
T} |
2425 |
|
|
T{ |
2426 |
|
|
\f[B]ra_rgbe\f[R] |
2427 |
|
|
T} T{ |
2428 |
|
|
X |
2429 |
|
|
T} T{ |
2430 |
|
|
X |
2431 |
|
|
T} T{ |
2432 |
|
|
Convert to/from uncompressed picture |
2433 |
|
|
T} |
2434 |
|
|
T{ |
2435 |
|
|
\f[B]ra_t8\f[R] |
2436 |
|
|
T} T{ |
2437 |
|
|
X |
2438 |
|
|
T} T{ |
2439 |
|
|
X |
2440 |
|
|
T} T{ |
2441 |
|
|
Convert to/from Targa 8-bit format |
2442 |
|
|
T} |
2443 |
|
|
T{ |
2444 |
|
|
\f[B]ra_t16\f[R] |
2445 |
|
|
T} T{ |
2446 |
|
|
X |
2447 |
|
|
T} T{ |
2448 |
|
|
X |
2449 |
|
|
T} T{ |
2450 |
|
|
Convert to/from Targa 16-bit and 24-bit |
2451 |
|
|
T} |
2452 |
|
|
T{ |
2453 |
|
|
\f[B]ra_tiff\f[R] |
2454 |
|
|
T} T{ |
2455 |
|
|
X |
2456 |
|
|
T} T{ |
2457 |
|
|
X |
2458 |
|
|
T} T{ |
2459 |
|
|
Convert to/from TIFF 8-bit and 24-bit |
2460 |
|
|
T} |
2461 |
|
|
T{ |
2462 |
|
|
\f[B]ra_xyze\f[R] |
2463 |
|
|
T} T{ |
2464 |
|
|
X |
2465 |
|
|
T} T{ |
2466 |
|
|
X |
2467 |
|
|
T} T{ |
2468 |
|
|
Convert to/from CIE primary picture |
2469 |
|
|
T} |
2470 |
|
|
T{ |
2471 |
|
|
\f[B]rad\f[R] |
2472 |
|
|
T} T{ |
2473 |
|
|
T} T{ |
2474 |
|
|
X+ |
2475 |
|
|
T} T{ |
2476 |
|
|
Render Radiance scene |
2477 |
|
|
T} |
2478 |
|
|
T{ |
2479 |
|
|
\f[B]ranimate\f[R] |
2480 |
|
|
T} T{ |
2481 |
|
|
T} T{ |
2482 |
|
|
X+ |
2483 |
|
|
T} T{ |
2484 |
|
|
Animate Radiance scene |
2485 |
|
|
T} |
2486 |
|
|
T{ |
2487 |
|
|
\f[B]rpict\f[R] |
2488 |
|
|
T} T{ |
2489 |
|
|
X |
2490 |
|
|
T} T{ |
2491 |
|
|
X+ |
2492 |
|
|
T} T{ |
2493 |
|
|
Batch rendering program |
2494 |
|
|
T} |
2495 |
|
|
T{ |
2496 |
|
|
\f[B]rpiece\f[R] |
2497 |
|
|
T} T{ |
2498 |
|
|
X |
2499 |
|
|
T} T{ |
2500 |
|
|
X+ |
2501 |
|
|
T} T{ |
2502 |
|
|
Parallel batch rendering program |
2503 |
|
|
T} |
2504 |
|
|
T{ |
2505 |
|
|
\f[B]rtrace\f[R] |
2506 |
|
|
T} T{ |
2507 |
|
|
X |
2508 |
|
|
T} T{ |
2509 |
|
|
X+ |
2510 |
|
|
T} T{ |
2511 |
|
|
Customizable ray-tracer |
2512 |
|
|
T} |
2513 |
|
|
T{ |
2514 |
|
|
\f[B]rview\f[R] |
2515 |
|
|
T} T{ |
2516 |
|
|
X |
2517 |
|
|
T} T{ |
2518 |
|
|
X+ |
2519 |
|
|
T} T{ |
2520 |
|
|
Interactive renderer |
2521 |
|
|
T} |
2522 |
|
|
T{ |
2523 |
|
|
\f[B]vwright\f[R] |
2524 |
|
|
T} T{ |
2525 |
|
|
X |
2526 |
|
|
T} T{ |
2527 |
|
|
T} T{ |
2528 |
|
|
Get view parameters and shift them |
2529 |
|
|
T} |
2530 |
|
|
T{ |
2531 |
|
|
\f[B]xglaresrc\f[R] |
2532 |
|
|
T} T{ |
2533 |
|
|
X |
2534 |
|
|
T} T{ |
2535 |
|
|
T} T{ |
2536 |
|
|
Display glare sources from \f[B]findglare\f[R] |
2537 |
|
|
T} |
2538 |
|
|
T{ |
2539 |
|
|
\f[B]ximage\f[R] |
2540 |
|
|
T} T{ |
2541 |
|
|
X+ |
2542 |
|
|
T} T{ |
2543 |
|
|
T} T{ |
2544 |
|
|
Display \f[I]Radiance\f[R] picture under \f[I]X11\f[R] |
2545 |
|
|
T} |
2546 |
|
|
T{ |
2547 |
|
|
\f[B]xshowtrace\f[R] |
2548 |
|
|
T} T{ |
2549 |
|
|
X |
2550 |
|
|
T} T{ |
2551 |
|
|
T} T{ |
2552 |
|
|
Show ray traces on \f[I]X11\f[R] display |
2553 |
|
|
T} |
2554 |
|
|
.TE |
2555 |
|
|
.ad |
2556 |
|
|
.LP |
2557 |
|
|
\f[B]Table 6.\f[R] \f[I]Radiance\f[R] programs that read and write |
2558 |
|
|
picture files. |
2559 |
|
|
Pluses indicate when a program makes use of or preserves physical pixel |
2560 |
|
|
values. |
2561 |
|
|
.SH 3 |
2562 |
|
|
\f[BI]Radiance\f[B] C Library |
2563 |
|
|
.pdfhref O 3 "Radiance C Library" |
2564 |
|
|
.pdfhref M "radiance-c-library-5" |
2565 |
|
|
.LP |
2566 |
|
|
There are a fair number of routines for reading, writing and |
2567 |
|
|
manipulating \f[I]Radiance\f[R] pictures. |
2568 |
|
|
If you want to write a converter to or from a 24-bit image format, you |
2569 |
|
|
can follow the skeletal example in \f[C]src/px/ra_skel.c\f[R]. |
2570 |
|
|
This has all of the basic functionality of the other \f[B]ra_*\f[R] |
2571 |
|
|
image conversion programs, with the actual code for the destination type |
2572 |
|
|
removed (or simplified). |
2573 |
|
|
The method in \f[C]ra_skel\f[R] uses the routines in |
2574 |
|
|
\f[C]src/common/colrops.c\f[R] to avoid conversion to machine floating |
2575 |
|
|
point, which can slow things down and is not necessary in this case. |
2576 |
|
|
.PP |
2577 |
|
|
Below we describe routines for reading and writing pictures, which rely |
2578 |
|
|
heavily on definitions in \f[C]src/common/color.h\f[R]. |
2579 |
|
|
We start with the calls for manipulating information headers, followed |
2580 |
|
|
by the calls for resolution strings, then the calls for scanline |
2581 |
|
|
records. |
2582 |
|
|
.PP |
2583 |
|
|
Information headers are manipulated with the routines in |
2584 |
|
|
\f[C]src/common/header.c\f[R] and the macros in \f[C]color.h\f[R]. |
2585 |
|
|
Features for handing views are defined in \f[C]src/common/view.h\f[R] |
2586 |
|
|
with routines in \f[C]src/common/image.c\f[R]. |
2587 |
|
|
Here are the relevant calls for reading and copying information headers: |
2588 |
|
|
.IP "\f[B]\f[CB]int checkheader(FILE *fin, char *fmt, FILE *fout);\f[B]\f[R]" 3 |
2589 |
|
|
Read the header information from \f[C]fin\f[R], copying to |
2590 |
|
|
\f[C]fou\f[R]t (unless fout is \f[C]NULL\f[R]), checking any |
2591 |
|
|
\f[C]FORMAT\f[R] line against the string \f[C]fmt\f[R]. |
2592 |
|
|
The \f[C]FORMAT\f[R] line (if it exists) will not be copied to |
2593 |
|
|
\f[C]fout\f[R]. |
2594 |
|
|
The function returns 1 if the header was OK and the format matched, 0 if |
2595 |
|
|
the header was OK but there was no format line, and -1 if the format |
2596 |
|
|
line did not match or there was some problem reading the header. |
2597 |
|
|
Wildcard characters (`*' and `?') may appear in \f[C]fmt\f[R], in which |
2598 |
|
|
case a globbing match is applied, and the matching format value will be |
2599 |
|
|
copied to fmt upon success. |
2600 |
|
|
The normal \f[C]fmt\f[R] values for pictures are \f[C]COLRFMT\f[R] for |
2601 |
|
|
\f[I]Radiance\f[R] RGB, \f[C]CIEFMT\f[R] for 4-byte XYZ pixels, or a |
2602 |
|
|
copy of \f[C]PICFMT\f[R] for glob matches to either. |
2603 |
|
|
(Do not pass \f[C]PICFMT\f[R] directly, as this will cause an illegal |
2604 |
|
|
memory access on systems that store static strings in read-only memory.) |
2605 |
|
|
.RS 3 |
2606 |
|
|
.RE |
2607 |
|
|
.IP "\f[B]\f[CB]int getheader(FILE *fp, int (*f)(), char *p);\f[B]\f[R]" 3 |
2608 |
|
|
For those who need more control, \f[C]getheader\f[R] reads the header |
2609 |
|
|
from \f[C]fp\f[R], calling the function \f[C]f\f[R] (if |
2610 |
|
|
not\f[C]NULL\f[R]) with each input line and the client data pointer |
2611 |
|
|
\f[C]p\f[R]. |
2612 |
|
|
A simple call to skip the header is \f[C]getheader(fp,NULL,NULL)\f[R]. |
2613 |
|
|
To copy the header unconditionally to \f[C]stdout\f[R], call |
2614 |
|
|
\f[C]getheader(fp,fputs,stdout)\f[R]. |
2615 |
|
|
More often, \f[C]getheader\f[R] is called with a client function, which |
2616 |
|
|
checks each line for specific variable settings. |
2617 |
|
|
.RS 3 |
2618 |
|
|
.RE |
2619 |
|
|
.IP "\f[B]\f[CB]int isformat(char *s);\f[B]\f[R]" 3 |
2620 |
|
|
Returns non-zero if the line \f[C]s\f[R] is a \f[C]FORMAT\f[R] |
2621 |
|
|
assignment. |
2622 |
|
|
.RS 3 |
2623 |
|
|
.RE |
2624 |
|
|
.IP "\f[B]\f[CB]int formatval(char *r, char *s);\f[B]\f[R]" 3 |
2625 |
|
|
Returns the \f[C]FORMAT\f[R] value from line \f[C]s\f[R] in the string |
2626 |
|
|
\f[C]r\f[R]. |
2627 |
|
|
Returns non-zero if \f[C]s\f[R] is a valid format line. |
2628 |
|
|
.RS 3 |
2629 |
|
|
.RE |
2630 |
|
|
.IP "\f[B]\f[CB]fputformat(char *s, FILE *fp);\f[B]\f[R]" 3 |
2631 |
|
|
Put format assignment \f[C]s\f[R] to the stream \f[C]fp\f[R]. |
2632 |
|
|
.RS 3 |
2633 |
|
|
.RE |
2634 |
|
|
.IP "\f[B]\f[CB]isexpos(s)\f[B]\f[R]" 3 |
2635 |
|
|
Macro returns non-zero if the line \f[C]s\f[R] is an \f[C]EXPOSURE\f[R] |
2636 |
|
|
setting. |
2637 |
|
|
.RS 3 |
2638 |
|
|
.RE |
2639 |
|
|
.IP "\f[B]exposval(s)\f[R]" 3 |
2640 |
|
|
Macro returns \f[B]double\f[R] exposure value from line \f[C]s\f[R]. |
2641 |
|
|
.RS 3 |
2642 |
|
|
.RE |
2643 |
|
|
.IP "\f[B]\f[CB]fputexpos(ex,fp)\f[B]\f[R]" 3 |
2644 |
|
|
Macro** | puts real exposure value \f[C]ex\f[R] to stream \f[C]fp\f[R]. |
2645 |
|
|
.RS 3 |
2646 |
|
|
.RE |
2647 |
greg |
1.2 |
.IP "\f[B]\f[CB]iscolcor(s)\f[B]\f[R]" 3 |
2648 |
|
|
Macro returns non-zero if the line \f[C]s\f[R] is a \f[C]COLORCORR\f[R] |
2649 |
|
|
setting. |
2650 |
|
|
.RS 3 |
2651 |
|
|
.RE |
2652 |
greg |
1.1 |
.IP "\f[B]\f[CB]colcorval(cc,s)\f[B]\f[R]" 3 |
2653 |
|
|
Macro assign color correction value from line \f[C]s\f[R] in the |
2654 |
|
|
\f[C]COLOR\f[R] variable \f[C]cc\f[R]. |
2655 |
|
|
.RS 3 |
2656 |
|
|
.RE |
2657 |
|
|
.IP "\f[B]\f[CB]fputcolcor(cc,fp)\f[B]\f[R]" 3 |
2658 |
|
|
Macro puts correction \f[C]COLOR\f[R] \f[C]cc\f[R] to stream |
2659 |
|
|
\f[C]fp\f[R]. |
2660 |
|
|
.RS 3 |
2661 |
|
|
.RE |
2662 |
|
|
.IP "\f[B]\f[CB]isaspect(s)\f[B]\f[R]" 3 |
2663 |
|
|
Macro returns non-zero if the line \f[C]s\f[R] is a \f[C]PIXASPECT\f[R] |
2664 |
|
|
setting. |
2665 |
|
|
.RS 3 |
2666 |
|
|
.RE |
2667 |
|
|
.IP "\f[B]\f[CB]aspectval(s)\f[B]\f[R]" 3 |
2668 |
|
|
Macro returns double pixel aspect value from line \f[C]s\f[R]. |
2669 |
|
|
.RS 3 |
2670 |
|
|
.RE |
2671 |
|
|
.IP "\f[B]\f[CB]fputaspect(pa,fp)\f[B]\f[R]" 3 |
2672 |
|
|
Macro puts real pixel aspect value \f[C]pa\f[R] to stream \f[C]fp\f[R]. |
2673 |
|
|
.RS 3 |
2674 |
|
|
.RE |
2675 |
|
|
.IP "\f[B]\f[CB]int isview(char *s);\f[B]\f[R]" 3 |
2676 |
|
|
Returns non-zero if header line \f[C]s\f[R] contains view parameters. |
2677 |
|
|
Note that \[ga]\f[C]s\f[R] could be either a \f[C]VIEW\f[R] assignment |
2678 |
|
|
or a rendering command. |
2679 |
|
|
.RS 3 |
2680 |
|
|
.RE |
2681 |
|
|
.IP "\f[B]\f[CB]int sscanview(VIEW *vp, char *s);\f[B]\f[R]" 3 |
2682 |
|
|
Scan view options from the string \f[C]s\f[R] into the \f[C]VIEW\f[R] |
2683 |
|
|
structure pointed to by \f[C]vp\f[R]. |
2684 |
|
|
.RS 3 |
2685 |
|
|
.RE |
2686 |
|
|
.IP "\f[B]\f[CB]fprintview(VIEW *vp, FILE *fp);\f[B]\f[R]" 3 |
2687 |
|
|
Print view options in \f[C]vp\f[R] to the stream \f[C]fp\f[R]. |
2688 |
|
|
Note that this does not print out \[lq]VIEW=\[rq] first, or end the |
2689 |
|
|
line. |
2690 |
|
|
Therefore, one usually calls \f[C]fputs(VIEWSTR,fp)\f[R] followed by |
2691 |
|
|
\f[C]fprintview(vp,fp)\f[R], then \f[C]putc(\[aq]\[rs]n\[aq],fp)\f[R]. |
2692 |
|
|
.RS 3 |
2693 |
|
|
.RE |
2694 |
|
|
.IP "\f[B]\f[CB]isprims(s)\f[B]\f[R]" 3 |
2695 |
|
|
Macro returns non-zero if the line \f[C]s\f[R] is a \f[C]PRIMARIES\f[R] |
2696 |
|
|
setting. |
2697 |
|
|
.RS 3 |
2698 |
|
|
.RE |
2699 |
|
|
.IP "\f[B]\f[CB]primsval(p,s)\f[B]\f[R]" 3 |
2700 |
|
|
Macro assign color primitives from line \f[C]s\f[R] in the |
2701 |
|
|
\f[C]RGBPRIMS\f[R] variable \f[C]p\f[R]. |
2702 |
|
|
.RS 3 |
2703 |
|
|
.RE |
2704 |
|
|
.IP "\f[B]\f[CB]fputprims(p,fp)\f[B]\f[R]" 3 |
2705 |
|
|
Macro puts color primitives \f[C]p\f[R] to stream \f[C]fp\f[R]. |
2706 |
|
|
.RS 3 |
2707 |
|
|
.RE |
2708 |
|
|
.LP |
2709 |
|
|
The header file \f[C]src/common/resolu.h\f[R] has macros for resolution |
2710 |
|
|
strings, which are handled by routines in \f[C]src/common/resolu.c\f[R]. |
2711 |
|
|
Here are the relevant calls: |
2712 |
|
|
.IP "\f[B]\f[CB]fgetsresolu(rs,fp)\f[B]\f[R]" 3 |
2713 |
|
|
Macro to get a resolution string from the stream \f[C]fp\f[R] and put it |
2714 |
|
|
in the \f[C]RESOLU\f[R] structure pointed to by \f[C]rs\f[R]. |
2715 |
|
|
The return value is non-zero if the resolution was successfully loaded. |
2716 |
|
|
.RS 3 |
2717 |
|
|
.RE |
2718 |
|
|
.IP "\f[B]\f[CB]fputsresolu(rs,fp)\f[B]\f[R]" 3 |
2719 |
|
|
Macro to write the \f[C]RESOLU\f[R] structure pointed to by rs to the |
2720 |
|
|
stream fp. |
2721 |
|
|
.RS 3 |
2722 |
|
|
.RE |
2723 |
|
|
.IP "\f[B]\f[CB]scanlen(rs)\f[B]\f[R]" 3 |
2724 |
|
|
Macro to get the scanline length from the \f[C]RESOL\f[R]U structure |
2725 |
|
|
pointed to by \f[C]rs\f[R]. |
2726 |
|
|
.RS 3 |
2727 |
|
|
.RE |
2728 |
|
|
.IP "\f[B]\f[CB]numscans(rs)\f[B]\f[R]" 3 |
2729 |
|
|
Macro to get the number of scanlines from the \f[C]RESOLU\f[R] structure |
2730 |
|
|
pointed to by \f[C]rs\f[R]. |
2731 |
|
|
.RS 3 |
2732 |
|
|
.RE |
2733 |
|
|
.IP "\f[B]\f[CB]fscnresolu(slp,nsp,fp)\f[B]\f[R]" 3 |
2734 |
|
|
Macro to read in a resolution string from \f[C]f\f[R]p and assign the |
2735 |
|
|
scanline length and number of scanlines to the integers pointed to by |
2736 |
|
|
\f[C]slp\f[R] and \f[C]nsp\f[R], respectively. |
2737 |
|
|
This call expects standard English-text ordered scanlines, and returns |
2738 |
|
|
non-zero only if the resolution string agrees. |
2739 |
|
|
.RS 3 |
2740 |
|
|
.RE |
2741 |
|
|
.IP "\f[B]\f[CB]fprtresolu(sl,ns,fp)\f[B]\f[R]" 3 |
2742 |
|
|
Macro to print out a resolution string for \f[C]ns\f[R] scanlines of |
2743 |
|
|
length \f[C]sl\f[R] in standard English-text ordering to \f[C]fp\f[R]. |
2744 |
|
|
.RS 3 |
2745 |
|
|
.RE |
2746 |
|
|
.LP |
2747 |
|
|
The file \f[C]src/common/color.c\f[R] contains the essential routines |
2748 |
|
|
for reading and writing scanline records. |
2749 |
|
|
Here are the relevant calls and macros: |
2750 |
|
|
.IP "\f[B]\f[CB]int freadcolrs(COLR *scn, int sl, FILE *fp);\f[B]\f[R]" 3 |
2751 |
|
|
Read a scanline record of length \f[C]sl\f[R] from stream \f[C]fp\f[R] |
2752 |
|
|
into the \f[C]COLR\f[R] array \f[C]scn\f[R]. |
2753 |
|
|
Interprets uncompressed, old, and new run-length encoded records. |
2754 |
|
|
Returns 0 on success, -1 on failure. |
2755 |
|
|
.RS 3 |
2756 |
|
|
.RE |
2757 |
|
|
.IP "\f[B]\f[CB]int fwritecolrs(COLR *scn, int sl, FILE *fp);\f[B]\f[R]" 3 |
2758 |
|
|
Write the scanline record stored in the \f[C]COLR\f[R] array |
2759 |
|
|
\f[C]scn\f[R], length \f[C]sl\f[R], to the stream \f[C]fp\f[R]. |
2760 |
|
|
Uses the new run-length encoding unless \f[C]sl\f[R] is less than 8 or |
2761 |
|
|
greater than 32767, when an uncompressed record is written. |
2762 |
|
|
Returns 0 on success, -1 if there was an error. |
2763 |
|
|
.RS 3 |
2764 |
|
|
.RE |
2765 |
|
|
.IP "\f[B]\f[CB]int freadscan(COLOR *fscn, int sl, FILE *fp);\f[B]\f[R]" 3 |
2766 |
|
|
Reads a scanline of length \f[C]sl\f[R] from the stream \f[C]fp\f[R] and |
2767 |
|
|
converts to machine floating-point format in the array \f[C]fscn\f[R]. |
2768 |
|
|
Recognizes all scanline record encodings. |
2769 |
|
|
Returns 0 on success, or -1 on failure. |
2770 |
|
|
.RS 3 |
2771 |
|
|
.RE |
2772 |
|
|
.IP "\f[B]\f[CB]int fwritescan(COLOR *fscn, int sl, FILE *fp);\f[B]\f[R]" 3 |
2773 |
|
|
Write the floating-point scanline of length \f[C]sl\f[R] stored in the |
2774 |
|
|
array fscn to the stream \f[C]fp\f[R]. |
2775 |
|
|
Converts to 4-byte/pixel scanline format and calls \f[C]fwritecolrs\f[R] |
2776 |
|
|
to do the actual write. |
2777 |
|
|
Returns 0 on success, or -1 if there was an error. |
2778 |
|
|
.RS 3 |
2779 |
|
|
.RE |
2780 |
|
|
.IP "\f[B]\f[CB]colval(col,p)\f[B]\f[R]" 3 |
2781 |
|
|
Macro to get primary p from the floating-point \f[C]COLOR col\f[R]. |
2782 |
|
|
The primary index may be one of \f[C]RED\f[R], \f[C]GRN\f[R] or |
2783 |
|
|
\f[C]BLU\f[R] for RGB colors, or CIEX, CIEY or CIEZ for XYZ colors. |
2784 |
|
|
This macro is a valid lvalue, so can be used on the left of assignment |
2785 |
|
|
statements as well. |
2786 |
|
|
.RS 3 |
2787 |
|
|
.RE |
2788 |
|
|
.IP "\f[B]\f[CB]colrval(clr,p)\f[B]\f[R]" 3 |
2789 |
|
|
Macro to get primary \f[C]p\f[R] from the 4-byte \f[C]COLR\f[R] pixel |
2790 |
|
|
\f[C]clr\f[R]. |
2791 |
|
|
The primary index may be one of RED, GRN or BLU for RGB colors, or CIEX, |
2792 |
|
|
CIEY or CIEZ for XYZ colors. |
2793 |
|
|
Unless just one primary is needed, it is more efficient to call |
2794 |
|
|
\f[C]colr_color\f[R] and use the \f[C]colval\f[R] macro on the result. |
2795 |
|
|
.RS 3 |
2796 |
|
|
.RE |
2797 |
|
|
.IP "\f[B]\f[CB]colr_color(COLOR col, COLR clr);\f[B]\f[R]" 3 |
2798 |
|
|
Convert the 4-byte pixel \f[C]clr\f[R] to a machine floating-point |
2799 |
|
|
representation and store the result in \f[C]col\f[R]. |
2800 |
|
|
.RS 3 |
2801 |
|
|
.RE |
2802 |
|
|
.IP "\f[B]\f[CB]setcolr(COLR clr, double p1, p2, p3);\f[B]\f[R]" 3 |
2803 |
|
|
Assign the 4-byte pixel \f[C]clr\f[R] according to the three primary |
2804 |
|
|
values \f[C]p1\f[R], \f[C]p2\f[R] and \f[C]p3\f[R]. |
2805 |
|
|
These can be either \f[I]Radiance\f[R] RGB values or CIE XYZ values. |
2806 |
|
|
.RS 3 |
2807 |
|
|
.RE |
2808 |
|
|
.SH 2 |
2809 |
|
|
Z-buffer Format (.zbf suffix) |
2810 |
|
|
.pdfhref O 2 "Z-buffer Format \(.zbf suffix\)" |
2811 |
|
|
.pdfhref M "z-buffer-format-.zbf-suffix" |
2812 |
|
|
.LP |
2813 |
|
|
The Z-buffer format used in \f[I]Radiance\f[R] hardly qualifies as a |
2814 |
|
|
format at all. |
2815 |
|
|
It is in fact a straight copy on the 4-byte machine floating point |
2816 |
|
|
values of each pixel in standard scanline order. |
2817 |
|
|
There is no information header or resolution string that would make the |
2818 |
|
|
file independently useful. |
2819 |
|
|
This is usually OK, because Z-buffer files are almost always created and |
2820 |
|
|
used in conjunction with a picture file, which has this identifying |
2821 |
|
|
information. |
2822 |
|
|
.PP |
2823 |
|
|
The major shortcoming of this format is that the machine representation |
2824 |
|
|
and byte ordering is not always the same from one system to another, |
2825 |
|
|
which limits the portability of Z-buffer files. |
2826 |
|
|
Since they are primarily used for interpolating animation frames, and |
2827 |
|
|
this usually occurs on networks with similar architectures, there is |
2828 |
|
|
usually no problem. |
2829 |
|
|
Also, since the adoption of IEEE standard floating-point calculations, |
2830 |
|
|
different machine representations are becoming quite rare. |
2831 |
|
|
[TBD: is this necessary at this point?] |
2832 |
|
|
.SH 3 |
2833 |
|
|
\f[BI]Radiance\f[B] programs |
2834 |
|
|
.pdfhref O 3 "Radiance programs" |
2835 |
|
|
.pdfhref M "radiance-programs-6" |
2836 |
|
|
.LP |
2837 |
|
|
Table 7 shows the programs that read and write \f[I]Radiance\f[R] |
2838 |
|
|
Z-buffer files. |
2839 |
|
|
The pvalue program may be used to convert Z-buffer files to |
2840 |
|
|
\f[I]Radiance\f[R] pictures for the purpose of visualizing the values |
2841 |
|
|
using falsecolor. |
2842 |
|
|
For example, the following command converts the Z-buffer file |
2843 |
|
|
\f[C]frame110.zbf\f[R] associated with the picture |
2844 |
|
|
\f[C]frame110.hdr\f[R] to a viewable image: |
2845 |
|
|
.IP |
2846 |
|
|
.nf |
2847 |
|
|
\f[C] |
2848 |
|
|
% pvalue -h \[ga]getinfo -d < frame110.hdr\[ga] -r -b -df |
2849 |
|
|
frame110.zbf | falsecolor -m 1 -s 40 -l Meters > |
2850 |
|
|
frame110z.hdr |
2851 |
|
|
\f[] |
2852 |
|
|
.fi |
2853 |
|
|
.LP |
2854 |
|
|
The \f[B]getinfo\f[R] program appearing in back-quotes was used to get |
2855 |
|
|
the dimensions associated with the Z-buffer from its corresponding |
2856 |
|
|
picture file. |
2857 |
|
|
.PP |
2858 |
|
|
.na |
2859 |
|
|
.TS |
2860 |
|
|
delim(@@) tab( ); |
2861 |
|
|
l l l l. |
2862 |
|
|
T{ |
2863 |
|
|
Program |
2864 |
|
|
T} T{ |
2865 |
|
|
Read |
2866 |
|
|
T} T{ |
2867 |
|
|
Write |
2868 |
|
|
T} T{ |
2869 |
|
|
Function |
2870 |
|
|
T} |
2871 |
|
|
_ |
2872 |
|
|
T{ |
2873 |
|
|
\f[B]pinterp\f[R] |
2874 |
|
|
T} T{ |
2875 |
|
|
X |
2876 |
|
|
T} T{ |
2877 |
|
|
X |
2878 |
|
|
T} T{ |
2879 |
|
|
Interpolate/extrapolate picture views |
2880 |
|
|
T} |
2881 |
|
|
T{ |
2882 |
|
|
\f[B]pvalue\f[R] |
2883 |
|
|
T} T{ |
2884 |
|
|
X |
2885 |
|
|
T} T{ |
2886 |
|
|
X |
2887 |
|
|
T} T{ |
2888 |
|
|
Convert picture to/from simpler formats |
2889 |
|
|
T} |
2890 |
|
|
T{ |
2891 |
|
|
\f[B]rad\f[R] |
2892 |
|
|
T} T{ |
2893 |
|
|
T} T{ |
2894 |
|
|
X |
2895 |
|
|
T} T{ |
2896 |
|
|
Render Radiance scene |
2897 |
|
|
T} |
2898 |
|
|
T{ |
2899 |
|
|
\f[B]ranimate\f[R] |
2900 |
|
|
T} T{ |
2901 |
|
|
X |
2902 |
|
|
T} T{ |
2903 |
|
|
X |
2904 |
|
|
T} T{ |
2905 |
|
|
Animate Radiance scene |
2906 |
|
|
T} |
2907 |
|
|
T{ |
2908 |
|
|
\f[B]rpict\f[R] |
2909 |
|
|
T} T{ |
2910 |
|
|
T} T{ |
2911 |
|
|
X |
2912 |
|
|
T} T{ |
2913 |
|
|
Batch rendering program |
2914 |
|
|
T} |
2915 |
|
|
T{ |
2916 |
|
|
\f[B]rtrace\f[R] |
2917 |
|
|
T} T{ |
2918 |
|
|
T} T{ |
2919 |
|
|
X |
2920 |
|
|
T} T{ |
2921 |
|
|
Customizable ray-tracer |
2922 |
|
|
T} |
2923 |
|
|
.TE |
2924 |
|
|
.ad |
2925 |
|
|
.LP |
2926 |
|
|
\f[B]Table 7.\f[R] \f[I]Radiance\f[R] programs that read and write |
2927 |
|
|
Z-buffer files. |
2928 |
|
|
.SH 3 |
2929 |
|
|
\f[BI]Radiance\f[B] C Library |
2930 |
|
|
.pdfhref O 3 "Radiance C Library" |
2931 |
|
|
.pdfhref M "radiance-c-library-6" |
2932 |
|
|
.LP |
2933 |
|
|
There are no library functions devoted to reading and writing Z-buffer |
2934 |
|
|
files in particular. |
2935 |
|
|
The normal method is to read and write Z-buffer scanlines with the |
2936 |
|
|
standard \f[C]fread\f[R] and \f[C]fwrite\f[R] library functions using an |
2937 |
|
|
appropriate float array. |
2938 |
|
|
.SH 2 |
2939 |
|
|
Ambient File Format (.amb suffix) |
2940 |
|
|
.pdfhref O 2 "Ambient File Format \(.amb suffix\)" |
2941 |
|
|
.pdfhref M "ambient-file-format-.amb-suffix" |
2942 |
|
|
.LP |
2943 |
|
|
\f[I]Radiance\f[R] can store its diffuse interreflection cache in an |
2944 |
|
|
\f[I]ambient file\f[R] for reuse by other processes. |
2945 |
|
|
This file is in a system-independent binary format, similar to an octree |
2946 |
|
|
or picture file, with an information header that can be read using |
2947 |
|
|
\f[B]getinfo\f[R]. |
2948 |
|
|
Following the header, there is a magic number specific to this file |
2949 |
|
|
type, then the ambient value records themselves in encoded form. |
2950 |
|
|
.SH 4 |
2951 |
|
|
Information Header |
2952 |
|
|
.pdfhref O 4 "Information Header" |
2953 |
|
|
.pdfhref M "information-header-2" |
2954 |
|
|
.LP |
2955 |
|
|
The information header begins with the usual \[lq]#?RADIANCE\[rq] |
2956 |
|
|
identifier, followed by the originating program and the ambient |
2957 |
|
|
calculation parameters (and octree name). |
2958 |
|
|
After this is the line: |
2959 |
|
|
.IP |
2960 |
|
|
.nf |
2961 |
|
|
\f[C] |
2962 |
|
|
FORMAT=Radiance_ambval |
2963 |
|
|
\f[] |
2964 |
|
|
.fi |
2965 |
|
|
.LP |
2966 |
|
|
This identifies the general file type, followed by an empty line ending |
2967 |
|
|
the header. |
2968 |
|
|
As with most information headers, this exact sequence need not be |
2969 |
|
|
followed, so long as there is no inconsistent \f[C]FORMAT\f[R] setting. |
2970 |
|
|
.SH 4 |
2971 |
|
|
Magic Number |
2972 |
|
|
.pdfhref O 4 "Magic Number" |
2973 |
|
|
.pdfhref M "magic-number" |
2974 |
|
|
.LP |
2975 |
|
|
Following the information header is the two-byte magic number, which for |
2976 |
|
|
the current ambient file format is 557. |
2977 |
|
|
This number may change later should the file format be altered in |
2978 |
|
|
incompatible ways. |
2979 |
|
|
.SH 4 |
2980 |
|
|
Ambient Value Records |
2981 |
|
|
.pdfhref O 4 "Ambient Value Records" |
2982 |
|
|
.pdfhref M "ambient-value-records" |
2983 |
|
|
.LP |
2984 |
|
|
Ambient values are written to the file in no particular order. |
2985 |
|
|
Each diffuse interreflection value in \f[I]Radiance\f[R] has the |
2986 |
|
|
following members: |
2987 |
|
|
.IP "\f[B]Level\f[R]" 3 |
2988 |
|
|
The number of reflections between the primary (eye) ray and this |
2989 |
|
|
surface. |
2990 |
|
|
A value with fewer reflections may be used in place of one with more, |
2991 |
|
|
but not the other way around. |
2992 |
|
|
.RS 3 |
2993 |
|
|
.RE |
2994 |
|
|
.IP "\f[B]Weight\f[R]" 3 |
2995 |
|
|
The weighting value associated with this ray or ambient value. |
2996 |
|
|
Similar to the level to avoid using inappropriate values from the cache. |
2997 |
|
|
.RS 3 |
2998 |
|
|
.RE |
2999 |
|
|
.IP "\f[B]Position\f[R]" 3 |
3000 |
|
|
The origin point of this interreflection calculation. |
3001 |
|
|
.RS 3 |
3002 |
|
|
.RE |
3003 |
|
|
.IP "\f[B]Direction\f[R]" 3 |
3004 |
|
|
The surface normal indicating the zenith of the sample hemisphere for |
3005 |
|
|
this value. |
3006 |
|
|
.RS 3 |
3007 |
|
|
.RE |
3008 |
|
|
.IP "\f[B]Value\f[R]" 3 |
3009 |
|
|
The calculated indirect irradiance at this point, in w/m\*{2\*} (RGB |
3010 |
|
|
color). |
3011 |
|
|
.RS 3 |
3012 |
|
|
.RE |
3013 |
|
|
.IP "\f[B]Radius\f[R]" 3 |
3014 |
|
|
The cosine-weighted, harmonic mean distance to other surfaces visible |
3015 |
|
|
from this point, used to decide point spacing. |
3016 |
|
|
.RS 3 |
3017 |
|
|
.RE |
3018 |
|
|
.IP "\f[B]Posgradient\f[R]" 3 |
3019 |
|
|
The position-based gradient vector, indicating how brightness changes as |
3020 |
|
|
a function of position in the sample plane. |
3021 |
|
|
.RS 3 |
3022 |
|
|
.RE |
3023 |
|
|
.IP "\f[B]Dirgradient\f[R]" 3 |
3024 |
|
|
The direction-based gradient vector, indicating how brightness changes |
3025 |
|
|
as a function of surface orientation. |
3026 |
|
|
.RS 3 |
3027 |
|
|
.RE |
3028 |
|
|
.LP |
3029 |
|
|
The members are stored one after the other in the above order using |
3030 |
|
|
system-independent binary representations. |
3031 |
|
|
The Level member takes 1 byte, Weight takes 5, Position takes 15, |
3032 |
|
|
Direction another 15, Value is 4 bytes (using the same color format as |
3033 |
|
|
\f[I]Radiance\f[R] pictures), Radius takes 5 bytes, and Posgradient and |
3034 |
|
|
Dirgradient each take 15 bytes, for a total size of 75 bytes per record. |
3035 |
|
|
.SH 3 |
3036 |
|
|
\f[BI]Radiance\f[B] Programs |
3037 |
|
|
.pdfhref O 3 "Radiance Programs" |
3038 |
|
|
.pdfhref M "radiance-programs-7" |
3039 |
|
|
.LP |
3040 |
|
|
Table 8 shows \f[I]Radiance\f[R] programs that read and write ambient |
3041 |
|
|
files. |
3042 |
|
|
The program \f[B]lookamb\f[R] is especially useful for examining the |
3043 |
|
|
contents of ambient files and debugging problems in the calculation. |
3044 |
|
|
.PP |
3045 |
|
|
.na |
3046 |
|
|
.TS |
3047 |
|
|
delim(@@) tab( ); |
3048 |
|
|
l l l l. |
3049 |
|
|
T{ |
3050 |
|
|
Program |
3051 |
|
|
T} T{ |
3052 |
|
|
Read |
3053 |
|
|
T} T{ |
3054 |
|
|
Write |
3055 |
|
|
T} T{ |
3056 |
|
|
Function |
3057 |
|
|
T} |
3058 |
|
|
_ |
3059 |
|
|
T{ |
3060 |
|
|
\f[B]getinfo\f[R] |
3061 |
|
|
T} T{ |
3062 |
|
|
X |
3063 |
|
|
T} T{ |
3064 |
|
|
T} T{ |
3065 |
|
|
Print information header from binary file |
3066 |
|
|
T} |
3067 |
|
|
T{ |
3068 |
|
|
\f[B]lookamb\f[R] |
3069 |
|
|
T} T{ |
3070 |
|
|
X |
3071 |
|
|
T} T{ |
3072 |
|
|
X |
3073 |
|
|
T} T{ |
3074 |
|
|
Convert \f[I]Radiance\f[R] ambient file |
3075 |
|
|
T} |
3076 |
|
|
T{ |
3077 |
|
|
\f[B]rad\f[R] |
3078 |
|
|
T} T{ |
3079 |
|
|
X |
3080 |
|
|
T} T{ |
3081 |
|
|
X |
3082 |
|
|
T} T{ |
3083 |
|
|
Render \f[I]Radiance\f[R] scene |
3084 |
|
|
T} |
3085 |
|
|
T{ |
3086 |
|
|
\f[B]rpict\f[R] |
3087 |
|
|
T} T{ |
3088 |
|
|
X |
3089 |
|
|
T} T{ |
3090 |
|
|
X |
3091 |
|
|
T} T{ |
3092 |
|
|
Batch rendering program |
3093 |
|
|
T} |
3094 |
|
|
T{ |
3095 |
|
|
\f[B]rpiece\f[R] |
3096 |
|
|
T} T{ |
3097 |
|
|
X |
3098 |
|
|
T} T{ |
3099 |
|
|
X |
3100 |
|
|
T} T{ |
3101 |
|
|
Parallel batch rendering program |
3102 |
|
|
T} |
3103 |
|
|
T{ |
3104 |
|
|
\f[B]rtrace\f[R] |
3105 |
|
|
T} T{ |
3106 |
|
|
X |
3107 |
|
|
T} T{ |
3108 |
|
|
X |
3109 |
|
|
T} T{ |
3110 |
|
|
Customizable ray-tracer |
3111 |
|
|
T} |
3112 |
|
|
T{ |
3113 |
|
|
\f[B]rview\f[R] |
3114 |
|
|
T} T{ |
3115 |
|
|
X |
3116 |
|
|
T} T{ |
3117 |
|
|
X |
3118 |
|
|
T} T{ |
3119 |
|
|
Interactive renderer |
3120 |
|
|
T} |
3121 |
|
|
.TE |
3122 |
|
|
.ad |
3123 |
|
|
.LP |
3124 |
|
|
\f[B]Table 8.\f[R] Programs in the \f[I]Radiance\f[R] distribution that |
3125 |
|
|
read and write ambient files. |
3126 |
|
|
.SH 3 |
3127 |
|
|
\f[BI]Radiance\f[B] C Library |
3128 |
|
|
.pdfhref O 3 "Radiance C Library" |
3129 |
|
|
.pdfhref M "radiance-c-library-7" |
3130 |
|
|
.LP |
3131 |
|
|
The \f[C]src/rt/ambient.h\f[R] file contains definitions of the |
3132 |
|
|
\f[C]AMBVAL\f[R] structure and certain details of the ambient file |
3133 |
|
|
format. |
3134 |
|
|
The \f[C]src/rt/ambio.c\f[R] module contains the specialized routines |
3135 |
|
|
for reading and writing ambient files, and these functions in turn |
3136 |
|
|
access routines in \f[C]src/common/portio.c\f[R] for reading and writing |
3137 |
|
|
portable binary data. |
3138 |
|
|
The information header is handled by the routines in |
3139 |
|
|
s\f[C]rc/common/header.c\f[R], similar to the method described for |
3140 |
|
|
\f[I]Radiance\f[R] picture files. |
3141 |
|
|
Here are the main calls from \f[C]src/rt/ambio.c\f[R]: |
3142 |
|
|
.IP "\f[B]\f[CB]putambmagic(FILE *fp);\f[B]\f[R]" 3 |
3143 |
|
|
Put out the appropriate two-byte magic number for a \f[I]Radiance\f[R] |
3144 |
|
|
ambient file to the stream \f[C]fp\f[R]. |
3145 |
|
|
.RS 3 |
3146 |
|
|
.RE |
3147 |
|
|
.IP "\f[B]\f[CB]int hasambmagic(FILE *fp);\f[B]\f[R]" 3 |
3148 |
|
|
Read the next two bytes from the stream \f[C]fp\f[R] and return non-zero |
3149 |
|
|
if they match an ambient file\[cq]s magic number. |
3150 |
|
|
.RS 3 |
3151 |
|
|
.RE |
3152 |
|
|
.IP "\f[B]\f[CB]int writeambval(AMBVAL *av, FILE *fp);\f[B]\f[R]" 3 |
3153 |
|
|
Write out the ambient value structure \f[C]av\f[R] to the stream |
3154 |
|
|
\f[C]fp\f[R], returning -1 if a file error occurred, or 0 normally. |
3155 |
|
|
.RS 3 |
3156 |
|
|
.RE |
3157 |
|
|
.IP "\f[B]\f[CB]int readambval(AMBVAL *av, FILE *fp);\f[B]\f[R]" 3 |
3158 |
|
|
Read in the next ambient value structure from the stream \f[C]fp\f[R] |
3159 |
|
|
and put the result in \f[C]av\f[R]. |
3160 |
|
|
Return 1 if the read was successful, 0 if the end of file was reached or |
3161 |
|
|
there was an error. |
3162 |
|
|
The \f[C]ambvalOK\f[R] function is used to check the consistency of the |
3163 |
|
|
value read. |
3164 |
|
|
.RS 3 |
3165 |
|
|
.RE |
3166 |
|
|
.IP "\f[B]\f[CB]int ambvalOK(AMBVAL *av);\f[B]\f[R]" 3 |
3167 |
|
|
Return non-zero if the member values of the \f[C]av\f[R] structure are |
3168 |
|
|
not too outlandish. |
3169 |
|
|
This is handy as insurance against a corrupted ambient file. |
3170 |
|
|
.RS 3 |
3171 |
|
|
.RE |
3172 |
|
|
.SH 2 |
3173 |
|
|
Conclusion |
3174 |
|
|
.pdfhref O 2 "Conclusion" |
3175 |
|
|
.pdfhref M "conclusion" |
3176 |
|
|
.LP |
3177 |
|
|
We have described the main file formats native to \f[I]Radiance\f[R] and |
3178 |
|
|
shown how even the binary formats can be reliably shared in |
3179 |
|
|
heterogeneous computing environments. |
3180 |
|
|
This corresponds to one of the basic philosophies of UNIX software, |
3181 |
|
|
which is system independence. |
3182 |
|
|
A more detailed understanding of the formats may still require some use |
3183 |
|
|
of binary dump programs and delving into the \f[I]Radiance\f[R] source |
3184 |
|
|
code. |