1 |
.\" SCCSid "$SunId$ LBL" |
2 |
.nr PS 11 |
3 |
.ps 11 |
4 |
.nr VS 12 |
5 |
.vs 12 |
6 |
.nr PD .5v |
7 |
.ds LF MGF |
8 |
.ds RF Version 1.0 |
9 |
.DA May 1995 |
10 |
.TL |
11 |
The Materials and Geometry Format |
12 |
.AU |
13 |
Greg Ward |
14 |
.br |
15 |
Lawrence Berkeley Laboratory |
16 |
.NH |
17 |
Introduction |
18 |
.LP |
19 |
The Materials and Geometry Format (referred to henceforth as MGF) |
20 |
is a description language for 3-dimensional environments expressly |
21 |
suited to visible light simulation and rendering. |
22 |
The materials are physically-based and rely on standard and |
23 |
well-accepted definitions of color, reflectance and transmittance |
24 |
for good accuracy and reproducibility. |
25 |
The geometry is based on boundary representation using simple |
26 |
geometric primitives such as polygons, spheres and cones. |
27 |
The file format itself is terse but human-readable ASCII text. |
28 |
.NH 2 |
29 |
What makes MGF special? |
30 |
.LP |
31 |
There are three principal reasons to use MGF as an input language for |
32 |
lighting simulation and physically-based rendering: |
33 |
.RS |
34 |
.IP 1. |
35 |
It's the only existing format that describes materials physically. |
36 |
.IP 2. |
37 |
It is endorsed by the Illuminating Engineering Society of North |
38 |
America (IESNA) as part of their LM-63-1995 standard for luminaire data. |
39 |
.IP 3. |
40 |
It's easy and fun to support since it comes with a standard parser |
41 |
and sample scenes and objects at the web site, |
42 |
"http://radsite.lbl.gov/mgf/HOME.html". |
43 |
.RE |
44 |
.LP |
45 |
The standard parser provides both immediate and a long-term |
46 |
benefits, since it presents a programming interface that is more |
47 |
stable even than the language itself. |
48 |
Unlike AutoCAD DXF and other de facto standards, a change to the |
49 |
language will not break existing programs. |
50 |
This is because the parser gives the calling software only those |
51 |
entities it can handle. |
52 |
If the translator understands only polygons, it will be given only |
53 |
polygons. |
54 |
If a new geometric primitive is included in a later version of the |
55 |
standard, the new parser that comes with it will still be able to |
56 |
express this entity as polygons. |
57 |
Thus, the urgency of modifying code to support a changing standard |
58 |
is removed, and long-term stability is assured. |
59 |
.LP |
60 |
This notion of |
61 |
.I extensibility |
62 |
is a cornerstone of the format, and it goes well beyond the |
63 |
extensibility of other languages because is guarantees that new |
64 |
versions of the standard will not break existing programs, and the |
65 |
new information will be used as much as possible. |
66 |
Other languages either require that all translators stay up to date |
67 |
with the latest standard, or allow forward compatibility by simply |
68 |
.I ignoring |
69 |
new entities. |
70 |
In MGF, if NURBS are added at some point and the translator or |
71 |
loader does not handle them directly, the new version of the parser |
72 |
will automatically convert them to smoothed polygons without |
73 |
changing a single line of the calling program. |
74 |
It is merely necessary to link to the new library, and all the new |
75 |
entities are supported\(dg. |
76 |
.FS |
77 |
\(dgIf an old version of the parser encounters new entities it does |
78 |
not recognize, the default action is to ignore them, printing a warning |
79 |
message. |
80 |
This may be overridden to support custom entities, but such |
81 |
practice is discouraged because it weakens the standard. |
82 |
.FE |
83 |
.NH 2 |
84 |
What does MGF look like? |
85 |
.LP |
86 |
MGF has a simple entity-per-line structure, with a similar |
87 |
appearance to Wavefront's .OBJ format. |
88 |
Each entity is specified by a short keyword, and |
89 |
arguments are separated by white space (tabs and/or spaces). |
90 |
A newline may be escaped with a backslash ('\\'), in which case it |
91 |
counts as a space. |
92 |
Lines and continued lines may have up to 4096 characters, including |
93 |
newlines, tabs and spaces. |
94 |
A comment is an ignored entity whose keyword is the pound sign ('#'). |
95 |
.LP |
96 |
Here is an MGF file that describes a simple two-drawer file cabinet: |
97 |
.DS |
98 |
# Conversion from inches to meters |
99 |
xf -s .0254 |
100 |
# Surface material |
101 |
m burgundy_formica = |
102 |
c |
103 |
cxy .362 .283 |
104 |
rd .0402 |
105 |
c |
106 |
rs .0284 .05 |
107 |
sides 1 |
108 |
# Cabinet vertices |
109 |
v fc.xy = |
110 |
p .05 0 0 |
111 |
v fc.xY = |
112 |
p .05 18 0 |
113 |
v fc.XY = |
114 |
p 35.95 18 0 |
115 |
v fc.Xy = |
116 |
p 35.95 0 0 |
117 |
# Cabinet |
118 |
prism fc.xy fc.xY fc.XY fc.Xy 24 |
119 |
# Drawer vertices |
120 |
v fcd.Xz = |
121 |
p 34 0 0 |
122 |
v fcd.XZ = |
123 |
p 34 0 10 |
124 |
v fcd.xZ = |
125 |
p 0 0 10 |
126 |
v fcd.xz = |
127 |
p 0 0 0 |
128 |
# Two drawers |
129 |
o drawer |
130 |
xf -t 1 18.1 2 -a 2 -t 0 0 11 |
131 |
prism fcd.xz fcd.Xz fcd.XZ fcd.xZ .9 |
132 |
xf |
133 |
o |
134 |
# End of units conversion |
135 |
xf |
136 |
.DE |
137 |
.NH 2 |
138 |
MGF's place in the world of standards |
139 |
.LP |
140 |
MGF was developed initially to support detailed geometric |
141 |
description of light fixtures for the IESNA luminaire data standard, |
142 |
publication LM-63\(dg. |
143 |
.FS |
144 |
\(dgTo obtain the latest version of this standard, write to: |
145 |
Illuminating Engineering Society of North America, |
146 |
345 East 47th St., |
147 |
New York, NY 10017. |
148 |
.FE |
149 |
Existing standards for geometric description were either too |
150 |
cumbersome (e.g. |
151 |
.I Radiance) |
152 |
or did not include physical materials (e.g. IGES). |
153 |
It was noted early on that a standard able to fully describe |
154 |
luminaires would necessarily be |
155 |
capable of describing other objects as well; indeed whole |
156 |
environments could be defined this way. |
157 |
Since the descriptions would be physical, they could serve as input |
158 |
to both lighting simulation and rendering software. |
159 |
A standard language for describing the appearance of physical |
160 |
objects has been lacking for some time, and current efforts in this |
161 |
direction (i.e. STEP) seem several years away from fruition. |
162 |
(There are other languages for describing realistic scenes |
163 |
that deserve mention here, such as VRML and the Manchester Scene |
164 |
Description Language, but none give specific attention to physical |
165 |
material properties and are thus unsuitable for lighting |
166 |
simulation.)\0 |
167 |
.LP |
168 |
In short, we saw this as an opportunity to offer the lighting and |
169 |
rendering community a simple and easy-to-support standard for |
170 |
describing environments in a physically valid way. |
171 |
Our hope is that this will promote sharing color, material and object |
172 |
libraries as well as complete scene descriptions. |
173 |
Sharing libraries is of obvious benefit to users and software |
174 |
developers alike. |
175 |
Sharing scenes should also permit |
176 |
comparisons between rendering systems and |
177 |
intervalidation of lighting calculations. |
178 |
As anyone who works in this field knows, modeling is the most |
179 |
difficult step in creating any simulation or rendering, and there is |
180 |
no excuse for this data being held prisoner by a proprietary data |
181 |
format. |
182 |
.NH |
183 |
MGF Basics |
184 |
.LP |
185 |
The default coordinate system in MGF is right-handed with |
186 |
distances given in meters, though this can be effectively changed |
187 |
by specifying a global transformation. |
188 |
The transformation context is affected by the |
189 |
.UL xf |
190 |
entity, and the whole of MGF can be understood in terms of entities |
191 |
and contexts. |
192 |
.NH 2 |
193 |
Entities and Contexts |
194 |
.LP |
195 |
An |
196 |
.I entity |
197 |
in MGF is any non-blank line, which must be one of a finite set of |
198 |
command keywords followed by zero or more arguments. |
199 |
(As mentioned previously, an entity may continue over multiple lines |
200 |
by escaping the newline with a backslash.)\0 |
201 |
Table 1 gives a list of entities and their expected arguments. |
202 |
Section 3 gives more detailed information on each entity. |
203 |
.KF |
204 |
.TS |
205 |
expand, box; |
206 |
l l l. |
207 |
Keyword Arguments Interpretation |
208 |
= = = |
209 |
# [anything ...] a comment |
210 |
o [name] begin/end object context |
211 |
xf [xform] begin/end transformation context |
212 |
i pathname [xform] include file (with transformation) |
213 |
ies pathname [-m f][xform] include IES luminaire (with transformation) |
214 |
_ _ _ |
215 |
c [id [= [template]]] get/set color context |
216 |
cxy x y set CIE (x,y) chromaticity for current color |
217 |
cspec l_min l_max v1 v2 ... set relative spectrum for current color |
218 |
cct temperature set spectrum based on black body temperature |
219 |
cmix w1 c1 w2 c2 ... mix named colors to make current color |
220 |
_ _ _ |
221 |
m [id [= [template]]] get/set material context |
222 |
sides {1|2} set number of sides for current material |
223 |
rd rho_d set diffuse reflectance for current material |
224 |
td tau_d set diffuse transmittance for current material |
225 |
ed epsilon_d set diffuse emittance for current material |
226 |
rs rho_s alpha_r set specular reflectance for current material |
227 |
ts tau_s alpha_t set specular transmittance for current material |
228 |
ir n_real n_imag set index of refraction for current material |
229 |
_ _ _ |
230 |
v [id [= [template]]] get/set vertex context |
231 |
p x y z set point position for current vertex |
232 |
n dx dy dz set surface normal for current vertex |
233 |
_ _ _ |
234 |
f v1 v2 v3 ... polygon using current material, spec. vertices |
235 |
sph vc radius sphere |
236 |
cyl v1 radius v2 truncated right cylinder (open-ended) |
237 |
cone v1 rad1 v2 rad2 truncated right cone (open-ended) |
238 |
prism v1 v2 v3 ... length truncated right prism (closed solid) |
239 |
ring vc rmin rmax circular ring with inner and outer radii |
240 |
torus vc rmin rmax circular torus with inner and outer radii |
241 |
.TE |
242 |
.QP |
243 |
.B "Table 1". |
244 |
MGF entities and their arguments. |
245 |
Arguments in brackets are optional. |
246 |
Arguments in curly braces mean one of the given choices must |
247 |
appear. |
248 |
Ellipsis (...) mean that any number of arguments may be given. |
249 |
.sp |
250 |
.KE |
251 |
.LP |
252 |
A |
253 |
.I context |
254 |
describes the current state of the interpreter, and affects or is |
255 |
affected by certain entities as they are read in. |
256 |
MGF contexts can be divided into two types, |
257 |
.I "hierarchical contexts" |
258 |
and |
259 |
.I "named contexts". |
260 |
.LP |
261 |
Hierarchical contexts are manipulated by a single entity and |
262 |
have an associated "stack" onto which new |
263 |
contexts are "pushed" using the entity. |
264 |
The last context may be "popped" by giving the entity again with no |
265 |
arguments. |
266 |
The two hierarchical contexts in MGF are the current transformation, |
267 |
manipulated with the |
268 |
.UL xf |
269 |
entity, and the current object, manipulated with the |
270 |
.UL o |
271 |
entity. |
272 |
.KF |
273 |
.TS |
274 |
expand, allbox; |
275 |
l c l l l. |
276 |
Context Cntl. Entity Default Value Field Entities Affects |
277 |
= = = = = |
278 |
Object o - - - |
279 |
Transform xf - - T{ |
280 |
f, sph, cyl, cone, |
281 |
ring, torus, prism |
282 |
T} |
283 |
Material m 2-sided black T{ |
284 |
sides, rd, td, |
285 |
ed, rs, ts |
286 |
T} T{ |
287 |
f, sph, cyl, cone, |
288 |
ring, torus, prism |
289 |
T} |
290 |
Color c neutral grey T{ |
291 |
cxy, cspec, cct, cmix |
292 |
T} T{ |
293 |
rd, td, ed, rs, ts |
294 |
T} |
295 |
Vertex v T{ |
296 |
(0,0,0), |
297 |
no normal |
298 |
T} p, n T{ |
299 |
f, sph, cyl, cone, |
300 |
ring, torus, prism |
301 |
T} |
302 |
.TE |
303 |
.QP |
304 |
.B "Table 2". |
305 |
MGF contexts and their related entities and default values. |
306 |
.sp |
307 |
.KE |
308 |
.LP |
309 |
Named contexts in contrast hold sets of values that are swapped |
310 |
in and out one at a time. |
311 |
There are three named contexts in MGF, the current material, the |
312 |
current color and the current vertex. |
313 |
Each one may be associated with an identifier (any non-white |
314 |
sequence of printing ASCII characters beginning with a letter), |
315 |
and one of each is in effect at any given time. |
316 |
Initially, these contexts are unnamed, and invoking an unnamed |
317 |
context always returns to the original (default) values. |
318 |
(See Table 2 for a list of contexts, their related |
319 |
entities and defaults.)\0 |
320 |
.LP |
321 |
It is easiest to think of a context as a "scratch space" where |
322 |
values are written by some entities and read by others. |
323 |
Naming a context allows us to reestablish the same scratch space |
324 |
later, usually for reference but it can be altered as well. |
325 |
Let us say we wanted to create a smooth blue plastic material with a |
326 |
diffuse reflectance of 20% and a specular reflectance of 4%: |
327 |
.DS |
328 |
# Establish a new material context called "blue_plastic" |
329 |
m blue_plastic = |
330 |
# Reestablish a previous color context called "blue" |
331 |
c blue |
332 |
# Set the diffuse reflectance, which uses the above color |
333 |
rd .20 |
334 |
# Get the unnamed color context (always starts out grey) |
335 |
c |
336 |
# Set the specular reflectance, which is uncolored |
337 |
rs .04 0 |
338 |
# We're done, the current material context is now "blue_plastic" |
339 |
.DE |
340 |
Note that the above assumes that we have previously defined a color |
341 |
context named "blue". |
342 |
If we forgot to do that, the above description would generate an |
343 |
"undefined" error. |
344 |
The color context affects the material context indirectly because it |
345 |
is read by the specular and diffuse reflectance entities, which are |
346 |
in turn written to the current material. |
347 |
It is not necessary to indent the entities that affect the material |
348 |
definition, but it improves readability. |
349 |
Note also that there is no explicit end to the material definition. |
350 |
As long as a context remains in effect, its contents may be altered |
351 |
by its field entities. |
352 |
This will not affect previous uses of the context, however. |
353 |
For example, a surface entity following the above definition will |
354 |
have the specified color and reflectance, and later changes to the |
355 |
material "blue_plastic" will have no effect on it. |
356 |
.LP |
357 |
Each of the three named contexts has an associated entity that |
358 |
controls it. |
359 |
The material context is controlled by the |
360 |
.UL m |
361 |
entity, the color context is controlled by the |
362 |
.UL c |
363 |
entity, and the vertex context is controlled by the |
364 |
.UL v |
365 |
entity. |
366 |
There are exactly four forms for each entity. |
367 |
The first form is the keyword by itself, which establishes |
368 |
an unnamed context with predetermined default values. |
369 |
This is a useful way to set values without worrying about saving |
370 |
them for recall later. |
371 |
The second form is to give the keyword with a previously defined |
372 |
name. |
373 |
This reestablishes a prior context for reuse. |
374 |
The third form is to give the keyword with a name followed by an |
375 |
equals sign. |
376 |
(There must be a space between the name and the equals sign, since |
377 |
it is a separate argument.)\0 |
378 |
This establishes a new context and assigns it the same default |
379 |
values as the unnamed context. |
380 |
The fourth and final form gives the keyword followed by a name then |
381 |
an equals then the name of a previous context definition. |
382 |
This establishes a new context for the first name, assigning the |
383 |
values from the second named context rather than the usual defaults. |
384 |
This is a convenient way create an alias or |
385 |
to modify a context under a new name (i.e. "save as"). |
386 |
.NH 2 |
387 |
Hierarchical Contexts and Transformations |
388 |
.LP |
389 |
As mentioned in the last subsection, there are two hierarchical |
390 |
contexts in MGF, the current object and the current transformation. |
391 |
We will start by discussing the current object, since it is |
392 |
the simpler of the two. |
393 |
.NH 3 |
394 |
Objects |
395 |
.LP |
396 |
There is no particular need in lighting simulation or rendering to |
397 |
name objects, but it may help the user |
398 |
to know what object a particular surface is associated with. |
399 |
The |
400 |
.UL o |
401 |
entity provides a convenient mechanism for associating names with |
402 |
surfaces. |
403 |
The basic use of this entity is as follows: |
404 |
.DS |
405 |
o object_name |
406 |
[object entities...] |
407 |
o subobject_name |
408 |
[subobject entities...] |
409 |
o |
410 |
[more object entities and subobjects...] |
411 |
o |
412 |
.DE |
413 |
The |
414 |
.UL o |
415 |
keyword by itself marks the end of an object context. |
416 |
Any number of hierarchical context levels are supported, and there are no |
417 |
rules governing the choice of object names except that they begin |
418 |
with a letter and be made up of printing, non-white ASCII characters. |
419 |
Indentation is not necessary of course, but it does improve |
420 |
readability. |
421 |
.NH 3 |
422 |
Transformations |
423 |
.LP |
424 |
MGF supports only rigid-body (i.e. non-distorting) transformations |
425 |
with uniform scaling. |
426 |
Unlike the other contexts, transformations have no associated |
427 |
name, only arguments. |
428 |
Thus, there is no way to reestablish a previous transformation other |
429 |
than to give the same arguments over again. |
430 |
Since the arguments are concise and self-explanatory, this was thought |
431 |
sufficient. |
432 |
The following transformation flags and |
433 |
parameters are defined: |
434 |
.TS |
435 |
center; |
436 |
l l. |
437 |
-t dx dy dz translate objects along the given vector |
438 |
-rx degrees rotate objects about the X-axis |
439 |
-ry degrees rotate objects about the Y-axis |
440 |
-rz degrees rotate objects about the Z-axis |
441 |
-s scalefactor scale objects by the given factor |
442 |
-mx mirror objects about the Y-Z plane |
443 |
-my mirror objects about the X-Z plane |
444 |
-mz mirror objects about the X-Y plane |
445 |
-i N repeat the following arguments N times |
446 |
-a N make an array of N geometric instances |
447 |
.TE |
448 |
Transform arguments have a cumulative effect. |
449 |
That is, a rotation |
450 |
about X of 20 degrees followed by a rotation about X of -50 degrees |
451 |
results in a total rotation of -30 degrees. |
452 |
However, if the two |
453 |
rotations are separated by some translation vector, the cumulative |
454 |
effect is quite different. |
455 |
It is best to think of each argument as |
456 |
acting on the included geometric objects, and each subsequent transformation |
457 |
argument affects the objects relative to their new position/orientation. |
458 |
.LP |
459 |
For example, rotating an object about its center is most easily done |
460 |
by translating |
461 |
the object back to the origin, applying the desired rotation, and translating |
462 |
it again back to its original position, like so: |
463 |
.DS |
464 |
# rotate an included object 20 degrees clockwise looking down |
465 |
# an axis parallel to Y and passing through the point (15,0,-35) |
466 |
xf -t -15 0 35 -ry -20 -t 15 0 -35 |
467 |
i object.mgf |
468 |
xf |
469 |
.DE |
470 |
Note that the include entity, |
471 |
.UL i, |
472 |
permits a transformation to be given with it, so the above could |
473 |
have been written more compactly as: |
474 |
.DS |
475 |
i object.mgf -t -15 0 35 -ry -20 -t 15 0 -35 |
476 |
.DE |
477 |
.LP |
478 |
Rotations are given in degrees counter-clockwise about a principal axis. |
479 |
That is, with the thumb of the right hand pointing in the direction |
480 |
of the axis, rotation follows the curl of the fingers. |
481 |
.LP |
482 |
The transform entity itself is cumulative, but in the reverse |
483 |
order to its arguments. |
484 |
That is, later transformations (i.e. enclosed transformations) |
485 |
are prepended to existing (i.e. enclosing) ones. |
486 |
A transform command |
487 |
with no arguments is used to return to the previous condition. |
488 |
It is |
489 |
necessary that transforms and their end statements ("xf" by itself) be |
490 |
balanced in a file, so that later or enclosing files are not affected. |
491 |
.LP |
492 |
Transformations apply only to geometric types, e.g. polygons, spheres, etc. |
493 |
Vertices and the components that go into geometry are not directly affected. |
494 |
This is to avoid confusion and the inadvertent multiple application of a |
495 |
given transformation. |
496 |
For example: |
497 |
.DS |
498 |
xf -t 5 0 0 |
499 |
v v1 = |
500 |
p 0 10 0 |
501 |
n 0 0 1 |
502 |
xf -rx 180 |
503 |
# Transform now in effect is "-rx 180 -t 5 0 0" |
504 |
ring v1 0 2 |
505 |
xf |
506 |
xf |
507 |
.DE |
508 |
The final ring center is (5,-10,0) -- note that the vertex itself is |
509 |
not affected by the transformation, only the geometry that calls on |
510 |
it. |
511 |
The normal orientation is (0,0,-1) due to the rotation about X, |
512 |
which also reversed the sign of the central Y coordinate. |
513 |
.NH 3 |
514 |
Arrays |
515 |
.LP |
516 |
The -a N transform specification causes the following transform |
517 |
arguments to be repeated along with the contents of the included |
518 |
objects N times. |
519 |
The first instance of the geometry will be in its |
520 |
initial location; the second instance will be repositioned according |
521 |
to the named transformation; the third instance will be repositioned by |
522 |
applying this transformation twice, and so on up to N-1 applications. |
523 |
.LP |
524 |
Multi-dimensional arrays may be specified with a single include |
525 |
entity by giving multiple array commands separated by their |
526 |
corresponding transforms. |
527 |
A final transformation may be given |
528 |
by preceding it with a -i 1 specification. |
529 |
In other words, the |
530 |
scope of an array command continues until the next -i or -a option. |
531 |
.LP |
532 |
The following MGF description places 60 spheres at a one unit spacing |
533 |
in a 3x4x5 array, then moves the whole thing to an origin of |
534 |
(15,30,45): |
535 |
.DS |
536 |
v v0 = |
537 |
p 0 0 0 |
538 |
xf -a 3 -t 1 0 0 -a 4 -t 0 1 0 -a 5 -t 0 0 1 -i 1 -t 15 30 45 |
539 |
sph v0 0.1 |
540 |
xf |
541 |
.DE |
542 |
Note the "-i 1" in the specification, which marks the end of the |
543 |
third array arguments before the final translation. |
544 |
.NH 2 |
545 |
Detailed MGF Example |
546 |
.LP |
547 |
The following example of a simple room with a single door |
548 |
and six file cabinets shows MGF in action, with copious comments to |
549 |
help explain what's going on. |
550 |
.LP |
551 |
.DS |
552 |
# "ceiling_tile" is a diffuse white surface with 75% reflectance: |
553 |
# Create new named material context and clear it |
554 |
m ceiling_tile = |
555 |
# Specify one-sided material so we can see through from above |
556 |
sides 1 |
557 |
# Set neutral color |
558 |
c |
559 |
# Set diffuse reflectance |
560 |
rd .75 |
561 |
# "stainless_steel" is a mostly specular surface with 70% reflectance: |
562 |
m stainless_steel = |
563 |
sides 1 |
564 |
c |
565 |
# Set specular reflectance to 50%, .08 roughness |
566 |
rs .5 .08 |
567 |
# Other 20% reflectance is diffuse |
568 |
rd .2 |
569 |
|
570 |
# The following materials were measured with a spectrophotometer: |
571 |
m beige_paint = |
572 |
sides 1 |
573 |
# Set diffuse spectral reflectance |
574 |
c |
575 |
# Spectrum measured in 10 nm increments from 400 to 700 nm |
576 |
cspec 400 700 35.29 44.87 47.25 47.03 46.87 47.00 47.09 \\\\ |
577 |
47.15 46.80 46.17 46.26 48.74 51.08 51.31 51.10 \\\\ |
578 |
51.11 50.52 50.36 51.72 53.61 53.95 52.08 49.49 \\\\ |
579 |
48.30 48.75 49.99 51.35 52.75 54.44 56.34 58.00 |
580 |
rd 0.5078 |
581 |
# Neutral (grey) specular component |
582 |
c |
583 |
rs 0.0099 0.08000 |
584 |
m mottled_carpet = |
585 |
sides 1 |
586 |
c |
587 |
cspec 400 700 11.23 11.28 11.39 11.49 11.61 11.73 11.88 \\\\ |
588 |
12.02 12.12 12.19 12.30 12.37 12.37 12.36 12.34 \\\\ |
589 |
12.28 12.22 12.29 12.45 12.59 12.70 12.77 12.82 \\\\ |
590 |
12.88 12.98 13.24 13.67 14.31 15.55 17.46 19.75 |
591 |
rd 0.1245 |
592 |
m reddish_cloth = |
593 |
# 2-sided so we can observe it from behind |
594 |
sides 2 |
595 |
c |
596 |
cspec 400 700 28.62 27.96 27.86 28.28 29.28 30.49 31.61 \\\\ |
597 |
32.27 32.26 31.83 31.13 30.07 29.14 29.03 29.69 \\\\ |
598 |
30.79 32.30 33.90 34.56 34.32 33.85 33.51 33.30 \\\\ |
599 |
33.43 34.06 35.26 37.04 39.41 42.55 46.46 51.00 |
600 |
rd 0.3210 |
601 |
m burgundy_formica = |
602 |
sides 1 |
603 |
c |
604 |
cspec 400 700 3.86 3.74 3.63 3.51 3.34 3.21 3.14 \\\\ |
605 |
3.09 3.08 3.14 3.13 2.91 2.72 2.74 2.72 \\\\ |
606 |
2.60 2.68 3.40 4.76 6.05 6.65 6.75 6.68 \\\\ |
607 |
6.63 6.56 6.51 6.46 6.41 6.36 6.34 6.34 |
608 |
rd 0.0402 |
609 |
c |
610 |
rs 0.0284 0.05000 |
611 |
m speckled_grey_formica = |
612 |
sides 1 |
613 |
c |
614 |
cspec 400 700 30.95 44.77 51.15 52.60 53.00 53.37 53.68 \\\\ |
615 |
54.07 54.33 54.57 54.85 55.20 55.42 55.51 55.54 \\\\ |
616 |
55.46 55.33 55.30 55.52 55.81 55.91 55.92 56.00 \\\\ |
617 |
56.22 56.45 56.66 56.72 56.58 56.44 56.39 56.39 |
618 |
rd 0.5550 |
619 |
c |
620 |
rs 0.0149 0.15000 |
621 |
|
622 |
# 40' x 22' x 9' office space with no windows and one door |
623 |
|
624 |
# All measurements are in inches, so enclose with a metric conversion: |
625 |
xf -s .0254 |
626 |
|
627 |
# The room corner vertices: |
628 |
v rc.xyz = |
629 |
p 0 0 0 |
630 |
v rc.Xyz = |
631 |
p 480 0 0 |
632 |
v rc.xYz = |
633 |
p 0 264 0 |
634 |
v rc.xyZ = |
635 |
p 0 0 108 |
636 |
v rc.XYz = |
637 |
p 480 264 0 |
638 |
v rc.xYZ = |
639 |
p 0 264 108 |
640 |
v rc.XyZ = |
641 |
p 480 0 108 |
642 |
v rc.XYZ = |
643 |
p 480 264 108 |
644 |
|
645 |
# The floor: |
646 |
# Push object name |
647 |
o floor |
648 |
# Get previously defined carpet material |
649 |
m mottled_carpet |
650 |
# Polygonal face using defined vertices |
651 |
f rc.xyz rc.Xyz rc.XYz rc.xYz |
652 |
# Pop object name |
653 |
o |
654 |
|
655 |
# The ceiling: |
656 |
o ceiling |
657 |
m ceiling_tile |
658 |
f rc.xyZ rc.xYZ rc.XYZ rc.XyZ |
659 |
o |
660 |
|
661 |
# The door outline vertices: |
662 |
v do.xz = |
663 |
p 216 0 0 |
664 |
v do.Xz = |
665 |
p 264 0 0 |
666 |
v do.xZ = |
667 |
p 216 0 84 |
668 |
v do.XZ = |
669 |
p 264 0 84 |
670 |
|
671 |
# The walls: |
672 |
o wall |
673 |
m beige_paint |
674 |
o x |
675 |
f rc.xyz rc.xYz rc.xYZ rc.xyZ |
676 |
o |
677 |
o X |
678 |
f rc.Xyz rc.XyZ rc.XYZ rc.XYz |
679 |
o |
680 |
o y |
681 |
f rc.xyz rc.xyZ rc.XyZ rc.Xyz do.Xz do.XZ do.xZ do.xz |
682 |
o |
683 |
o Y |
684 |
f rc.xYz rc.XYz rc.XYZ rc.xYZ |
685 |
o |
686 |
o |
687 |
|
688 |
# The door and jam vertices: |
689 |
v djo.xz = |
690 |
p 216 .5 0 |
691 |
v djo.xZ = |
692 |
p 216 .5 84 |
693 |
v djo.XZ = |
694 |
p 264 .5 84 |
695 |
v djo.Xz = |
696 |
p 264 .5 0 |
697 |
v dji.Xz = |
698 |
p 262 .5 0 |
699 |
v dji.XZ = |
700 |
p 262 .5 82 |
701 |
v dji.xZ = |
702 |
p 218 .5 82 |
703 |
v dji.xz = |
704 |
p 218 .5 0 |
705 |
v door.xz = |
706 |
p 218 0 0 |
707 |
v door.xZ = |
708 |
p 218 0 82 |
709 |
v door.XZ = |
710 |
p 262 0 82 |
711 |
v door.Xz = |
712 |
p 262 0 0 |
713 |
|
714 |
# The door, jam and knob |
715 |
o door |
716 |
m burgundy_formica |
717 |
f door.xz door.xZ door.XZ door.Xz |
718 |
o jam |
719 |
m beige_paint |
720 |
f djo.xz djo.xZ djo.XZ djo.Xz dji.Xz dji.XZ dji.xZ dji.xz |
721 |
f djo.xz do.xz do.xZ djo.xZ |
722 |
f djo.xZ do.xZ do.XZ djo.XZ |
723 |
f djo.Xz djo.XZ do.XZ do.Xz |
724 |
f dji.xz dji.xZ door.xZ door.xz |
725 |
f dji.xZ dji.XZ door.XZ door.xZ |
726 |
f dji.Xz door.Xz door.XZ dji.XZ |
727 |
o |
728 |
o knob |
729 |
m stainless_steel |
730 |
# Define vertices needed for curved geometry |
731 |
v kb1 = |
732 |
p 257 0 36 |
733 |
v kb2 = |
734 |
p 257 .25 36 |
735 |
n 0 1 0 |
736 |
v kb3 = |
737 |
p 257 2 36 |
738 |
# 1" diameter cylindrical base from kb1 to kb2 |
739 |
cyl kb1 1 kb2 |
740 |
# Ring at base of knob stem |
741 |
ring kb2 .4 1 |
742 |
# Knob stem |
743 |
cyl kb2 .4 kb3 |
744 |
# Spherical knob |
745 |
sph kb3 .85 |
746 |
o |
747 |
o |
748 |
|
749 |
# Six file cabinets (36" wide each) |
750 |
# ("filecab.inc" was given as an earlier example in Section 1.2) |
751 |
o filecab.x |
752 |
# include a file as an array of three 36" apart |
753 |
i filecab.inc -t -36 0 0 -rz -90 -t 1 54 0 -a 3 -t 0 36 0 |
754 |
o |
755 |
o filecab.X |
756 |
# the other three cabinets |
757 |
i filecab.inc -rz 90 -t 479 54 0 -a 3 -t 0 36 0 |
758 |
o |
759 |
|
760 |
# End of transform from inches to meters: |
761 |
xf |
762 |
|
763 |
# The 10 recessed fluorescent ceiling fixtures |
764 |
ies hlrs2gna.ies -t 1.2192 2.1336 2.74 -a 5 -t 2.4384 0 0 -a 2 -t 0 2.4384 0 |
765 |
.DE |
766 |
.bp |
767 |
.NH |
768 |
MGF Entity Reference |
769 |
.LP |
770 |
There are currently 28 entities in the MGF specification. |
771 |
For ease of reference we have broken these into five categories: |
772 |
.IP 1. |
773 |
General |
774 |
.TS |
775 |
lw(.75i) lw(1.75i) lw(3i). |
776 |
# [anything ...] a comment |
777 |
o [name] begin/end object context |
778 |
xf [xform] begin/end transformation context |
779 |
i pathname [xform] include file (with transformation) |
780 |
ies pathname [-m f][xform] include IES luminaire (with transformation) |
781 |
.TE |
782 |
.IP 2. |
783 |
Color |
784 |
.TS |
785 |
lw(.75i) lw(1.75i) lw(3i). |
786 |
c [id [= [template]]] get/set color context |
787 |
cxy x y set CIE (x,y) chromaticity for current color |
788 |
cspec l_min l_max v1 v2 ... set relative spectrum for current color |
789 |
cct temperature set spectrum based on black body temperature |
790 |
cmix w1 c1 w2 c2 ... mix named colors to make current color |
791 |
.TE |
792 |
.IP 3. |
793 |
Material |
794 |
.TS |
795 |
lw(.75i) lw(1.75i) lw(3i). |
796 |
m [id [= [template]]] get/set material context |
797 |
sides {1|2} set number of sides for current material |
798 |
rd rho_d set diffuse reflectance for current material |
799 |
td tau_d set diffuse transmittance for current material |
800 |
ed epsilon_d set diffuse emittance for current material |
801 |
rs rho_s alpha_r set specular reflectance for current material |
802 |
ts tau_s alpha_t set specular transmittance for current material |
803 |
ir n_real n_imag set index of refraction for current material |
804 |
.TE |
805 |
.IP 4. |
806 |
Vertex |
807 |
.TS |
808 |
lw(.75i) lw(1.75i) lw(3i). |
809 |
v [id [= [template]]] get/set vertex context |
810 |
p x y z set point position for current vertex |
811 |
n dx dy dz set surface normal for current vertex |
812 |
.TE |
813 |
.IP 5. |
814 |
Geometry |
815 |
.TS |
816 |
lw(.75i) lw(1.75i) lw(3i). |
817 |
f v1 v2 v3 ... polygon using current material, spec. vertices |
818 |
sph vc radius sphere |
819 |
cyl v1 radius v2 truncated right cylinder (open-ended) |
820 |
cone v1 rad1 v2 rad2 truncated right cone (open-ended) |
821 |
prism v1 v2 v3 ... length truncated right prism (closed solid) |
822 |
ring vc rmin rmax circular ring with inner and outer radii |
823 |
torus vc rmin rmax circular torus with inner and outer radii |
824 |
.TE |
825 |
.ds LH General Entities |
826 |
.ds RH # |
827 |
.bp |
828 |
.SH |
829 |
NAME |
830 |
.LP |
831 |
# - a comment |
832 |
.SH |
833 |
SYNOPSIS |
834 |
.LP |
835 |
.B # |
836 |
[ |
837 |
.I anything |
838 |
] |
839 |
.SH |
840 |
DESCRIPTION |
841 |
.LP |
842 |
A comment is a bit of text explanation. |
843 |
Since it is an entity like any other (except that it has no effect), |
844 |
there must be at least one space between the keyword (which is a |
845 |
pound sign) and the "arguments," and the end of line may be escaped |
846 |
as usual with the backslash character ('\\'). |
847 |
.LP |
848 |
A comment may actually be used to hold auxiliary information such as |
849 |
view parameters, which may be interpreted by some destination program. |
850 |
Care should be taken under such circumstances that the user does not |
851 |
inadvertently mung or mimic this information in other comments, and |
852 |
it is therefore advisable to use an additional set of identifying |
853 |
characters to distinguish such data. |
854 |
.SH |
855 |
EXAMPLE |
856 |
.DS |
857 |
# The following include file is in inches, so convert to meters |
858 |
i cubgeom.inc -s .0254 |
859 |
# Stuff we don't want to see at the moment: |
860 |
# i person.mgf -t 3 2 0 |
861 |
# ies hlrs3gna.ies -rz 90 -t 1.524 1.8288 2.74 \\\\ |
862 |
-a 6 -t 1.8288 0 0 -a 2 -t 0 3.048 0 |
863 |
.DE |
864 |
.ds RH O |
865 |
.bp |
866 |
.SH |
867 |
NAME |
868 |
.LP |
869 |
o - begin or end object context |
870 |
.SH |
871 |
SYNOPSIS |
872 |
.LP |
873 |
.B o |
874 |
[ |
875 |
.I name |
876 |
] |
877 |
.SH |
878 |
DESCRIPTION |
879 |
.LP |
880 |
If |
881 |
.I name |
882 |
is given, we push a new object context onto the stack, which is to |
883 |
say that we begin a new subobject by this name\(dg. |
884 |
.FS |
885 |
\(dgA name is any sequence of printing, non-white ASCII characters |
886 |
beginning with a letter. |
887 |
.FE |
888 |
If the |
889 |
.UL o |
890 |
keyword is given by itself, then we pop the last object context off |
891 |
the stack, which means that we leave the current subobject. |
892 |
.LP |
893 |
All geometry between the start of an object context and its matching |
894 |
end statement is associated with the given name. |
895 |
This may be used in modeling software to help identify objects and |
896 |
subobjects, or it may be ignored altogether. |
897 |
.LP |
898 |
Object begin and end statements should be balanced in a file, and |
899 |
care should be taken not to overlap transform |
900 |
.UL (xf) |
901 |
contexts with object contexts, especially when arrays are involved. |
902 |
This is because the standard parser will assign object contexts to |
903 |
instanced geometry, which can get confused with other object |
904 |
contexts if a clear enclosure is not maintained. |
905 |
.SH |
906 |
EXAMPLE |
907 |
.DS |
908 |
o body |
909 |
o torso |
910 |
i torso.mgf |
911 |
o |
912 |
o arm |
913 |
o left |
914 |
i leftarm.mgf |
915 |
o |
916 |
o right |
917 |
i leftarm.mgf -mx |
918 |
o |
919 |
o |
920 |
o |
921 |
.DE |
922 |
.SH |
923 |
SEE ALSO |
924 |
.LP |
925 |
.UL xf |
926 |
.ds RH XF |
927 |
.bp |
928 |
.SH |
929 |
NAME |
930 |
.LP |
931 |
xf - begin or end transformation context |
932 |
.SH |
933 |
SYNOPSIS |
934 |
.LP |
935 |
.B xf |
936 |
[ |
937 |
.I transform |
938 |
] |
939 |
.SH |
940 |
DESCRIPTION |
941 |
.LP |
942 |
If a set of |
943 |
.I transform |
944 |
arguments are given, we push a new transformation context onto the |
945 |
stack. |
946 |
If the |
947 |
.UL xf |
948 |
keyword is given by itself, then we pop the last transformation |
949 |
context off the stack. |
950 |
The total transformation in effect at any given time is |
951 |
computed by prepending each set subcontext arguments onto those of |
952 |
its enclosing context. |
953 |
This and other details about transformation specifications |
954 |
are explained in some detail in section 2.2.2. |
955 |
.LP |
956 |
The following transformation flags and |
957 |
parameters are defined: |
958 |
.TS |
959 |
center; |
960 |
l l. |
961 |
-t dx dy dz translate objects along the given vector |
962 |
-rx degrees rotate objects about the X-axis |
963 |
-ry degrees rotate objects about the Y-axis |
964 |
-rz degrees rotate objects about the Z-axis |
965 |
-s scalefactor scale objects by the given factor |
966 |
-mx mirror objects about the Y-Z plane |
967 |
-my mirror objects about the X-Z plane |
968 |
-mz mirror objects about the X-Y plane |
969 |
-i N repeat the following arguments N times |
970 |
-a N make an array of N geometric instances |
971 |
.TE |
972 |
.SH |
973 |
EXAMPLE |
974 |
.DS |
975 |
# Create 3x5 array of evenly-spaced spheres (grid size = 3) |
976 |
v vc = |
977 |
p 0 0 0 |
978 |
xf -t 1 1 10 -a 3 -t 3 0 0 -a 5 -t 0 3 0 |
979 |
sph vc .5 |
980 |
xf |
981 |
.DE |
982 |
.SH |
983 |
SEE ALSO |
984 |
.LP |
985 |
.UL i, |
986 |
.UL ies, |
987 |
.UL o |
988 |
.ds RH I |
989 |
.bp |
990 |
.SH |
991 |
NAME |
992 |
.LP |
993 |
i - include MGF data file |
994 |
.SH |
995 |
SYNOPSIS |
996 |
.LP |
997 |
.B i |
998 |
.I pathname |
999 |
[ |
1000 |
.I transform |
1001 |
] |
1002 |
.SH |
1003 |
DESCRIPTION |
1004 |
.LP |
1005 |
Include the information contained in the file |
1006 |
.I pathname. |
1007 |
If a |
1008 |
.I transform |
1009 |
specification is given, then it will be applied as though the |
1010 |
include statement were enclosed by beginning and ending |
1011 |
.UL xf |
1012 |
entities with this transformation. |
1013 |
.LP |
1014 |
The |
1015 |
.I pathname |
1016 |
will be interpreted relative to the enclosing MGF file. |
1017 |
That is, if the file containing the include statement is in some |
1018 |
parent or subdirectory, then the given pathname is appended to this |
1019 |
directory. |
1020 |
It is illegal to specify a |
1021 |
.I pathname |
1022 |
relative to the root directory, and the MGF standard requires that |
1023 |
all filenames adhere to the ISO-9660 8.3 name format for maximum |
1024 |
portability between systems. |
1025 |
The directory separator is defined to be slash ('/'), and drive |
1026 |
specifications (such as "c:") are not allowed. |
1027 |
All pathnames should be given in lower case, and will be converted to |
1028 |
upper case on systems that require it. |
1029 |
(That way, there are no accidental name collisions.)\0 |
1030 |
.LP |
1031 |
The suggested suffix for MGF-adherent files is ".mgf". |
1032 |
Files that are not in metric units but are in MGF may be given any |
1033 |
suffix, but we suggest using ".inc" as a convention. |
1034 |
.SH |
1035 |
EXAMPLE |
1036 |
.DS |
1037 |
# Define vertices for 62x30" partition |
1038 |
i pv62x30.inc |
1039 |
# Insert 2 62x30" partitions |
1040 |
o cpart1 |
1041 |
i partn.inc -t 75 130.5 0 |
1042 |
o |
1043 |
o cpart3 |
1044 |
i partn.inc -t 186 130.5 0 |
1045 |
o |
1046 |
# Define vertices for 62x36" partition |
1047 |
i pv62x36.inc |
1048 |
# Insert 62x36" partition |
1049 |
o cpart2 |
1050 |
i partn.inc -t 105 130.5 0 |
1051 |
o |
1052 |
.DE |
1053 |
.SH |
1054 |
SEE ALSO |
1055 |
.LP |
1056 |
.UL ies, |
1057 |
.UL o, |
1058 |
.UL xf |
1059 |
.ds RH IES |
1060 |
.bp |
1061 |
.SH |
1062 |
NAME |
1063 |
.LP |
1064 |
ies - include IESNA luminaire file |
1065 |
.SH |
1066 |
SYNOPSIS |
1067 |
.LP |
1068 |
.B ies |
1069 |
.I pathname |
1070 |
[ |
1071 |
.B \-m |
1072 |
.I multiplier |
1073 |
] |
1074 |
[ |
1075 |
.I transform |
1076 |
] |
1077 |
.SH |
1078 |
DESCRIPTION |
1079 |
.LP |
1080 |
Load the IES standard luminaire information contained in the file |
1081 |
.I pathname. |
1082 |
If a |
1083 |
.I multiplier |
1084 |
is given, all candela values will be multiplied by this factor. |
1085 |
(This option must appear first if present.)\0 |
1086 |
If a |
1087 |
.I transform |
1088 |
specification is given, then it will be applied as though the |
1089 |
statement were enclosed by beginning and ending |
1090 |
.UL xf |
1091 |
entities with this transformation. |
1092 |
.LP |
1093 |
The |
1094 |
.I pathname |
1095 |
will be interpreted relative to the enclosing MGF file, and all |
1096 |
restrictions discussed under the |
1097 |
.UL i |
1098 |
entity also apply to the IES file name. |
1099 |
The suggested suffix is ".ies", but this has not been followed |
1100 |
consistently by lighting manufacturers. |
1101 |
.SH |
1102 |
EXAMPLE |
1103 |
.DS |
1104 |
# Insert 10 2x4' fluorescent troffers in two groups |
1105 |
ies cf9pr240.ies -t 3.6576 2.1336 2.74 -a 3 -t 2.4384 0 0 -a 2 -t 0 2.4384 0 |
1106 |
ies cf9pr240.ies -rz 90 -t 1.2192 1.8288 2.74 \\\\ |
1107 |
-a 2 -t 9.7536 0 0 -a 2 -t 0 3.048 0 |
1108 |
.DE |
1109 |
.SH |
1110 |
SEE ALSO |
1111 |
.LP |
1112 |
.UL i, |
1113 |
.UL o, |
1114 |
.UL xf |
1115 |
.ds LH Color Entities |
1116 |
.ds RH C |
1117 |
.bp |
1118 |
.SH |
1119 |
NAME |
1120 |
.LP |
1121 |
c - get or set the current color context |
1122 |
.SH |
1123 |
SYNOPSIS |
1124 |
.LP |
1125 |
.B c |
1126 |
[ |
1127 |
.I id |
1128 |
[ |
1129 |
.B = |
1130 |
[ |
1131 |
.I template |
1132 |
] |
1133 |
] |
1134 |
] |
1135 |
.SH |
1136 |
DESCRIPTION |
1137 |
.LP |
1138 |
If the |
1139 |
.UL c |
1140 |
keyword is given by itself, then it establishes the unnamed color |
1141 |
context, which is neutral (i.e. equal-energy) grey. |
1142 |
This context may be modified, but the changes will not be saved. |
1143 |
.LP |
1144 |
If the keyword is followed by an identifier |
1145 |
.I id, |
1146 |
then it reestablishes a previous context. |
1147 |
If the specified context was never defined, an error will result. |
1148 |
.LP |
1149 |
If the entity is given with an identifier |
1150 |
followed by an equals sign ('='), then a new context is established, |
1151 |
and cleared to the default neutral grey. |
1152 |
(Note that the equals sign must be separated from other |
1153 |
arguments by white space to be properly recognized.)\0 |
1154 |
If the equals sign is followed by a second identifier |
1155 |
.I template, |
1156 |
then this previously defined color will be used as a source of |
1157 |
default values rather than grey. |
1158 |
This is most useful for establishing a color alias. |
1159 |
.SH |
1160 |
EXAMPLE |
1161 |
.DS |
1162 |
# Define the color "red32" |
1163 |
c red32 = |
1164 |
cxy .42 .15 |
1165 |
# Make "cabinet_color" an alias for "red32" |
1166 |
c cabinet_color = red32 |
1167 |
|
1168 |
# Later in another part of the description... |
1169 |
|
1170 |
# Get our cabinet color |
1171 |
c cabinet_color |
1172 |
# Get the geometry |
1173 |
i cabgeom.mgf |
1174 |
.DE |
1175 |
.SH |
1176 |
SEE ALSO |
1177 |
.LP |
1178 |
.UL cct, |
1179 |
.UL cmix, |
1180 |
.UL cspec, |
1181 |
.UL cxy, |
1182 |
.UL m |
1183 |
.ds RH CXY |
1184 |
.bp |
1185 |
.SH |
1186 |
NAME |
1187 |
.LP |
1188 |
cxy - set the CIE (x,y) chromaticity for the current color |
1189 |
.SH |
1190 |
SYNOPSIS |
1191 |
.LP |
1192 |
.B cxy |
1193 |
.I "x y" |
1194 |
.SH |
1195 |
DESCRIPTION |
1196 |
.LP |
1197 |
This entity sets the current color using (x,y) chromaticity |
1198 |
coordinates for the 1931 CIE standard 2 degree observer. |
1199 |
Legal values for |
1200 |
.I x |
1201 |
and |
1202 |
.I y |
1203 |
are greater than zero and sum to less than one, and more |
1204 |
specifically they must fit within the curve of the visible spectrum. |
1205 |
The |
1206 |
.I x |
1207 |
coordinate roughly corresponds to the red part of the spectrum and |
1208 |
the |
1209 |
.I y |
1210 |
coordinate corresponds to the green. |
1211 |
The CIE z coordinate is implicit, since it is equal to (1-x-y). |
1212 |
.LP |
1213 |
All colors in MGF are absolute, thus colorimeter measurements should |
1214 |
be conducted the same for surfaces as for light sources. |
1215 |
Applying a standard illuminant calculation is redundant and |
1216 |
introduces inaccuracies, and should therefore be avoided if |
1217 |
possible. |
1218 |
.LP |
1219 |
Conversion between CIE colors and those more commonly used in |
1220 |
computer graphics are described in the application notes section |
1221 |
6.1.1. |
1222 |
.SH |
1223 |
EXAMPLE |
1224 |
.DS |
1225 |
# Set unnamed color context |
1226 |
c |
1227 |
# Set CIE chromaticity to a bluish hue |
1228 |
cxy .15 .2 |
1229 |
# Apply color to diffuse reflectance of 15% |
1230 |
rd .15 |
1231 |
.DE |
1232 |
.SH |
1233 |
SEE ALSO |
1234 |
.LP |
1235 |
.UL c, |
1236 |
.UL cct, |
1237 |
.UL cmix, |
1238 |
.UL cspec |
1239 |
.ds RH CSPEC |
1240 |
.bp |
1241 |
.SH |
1242 |
NAME |
1243 |
.LP |
1244 |
cspec - set the relative spectrum for the current color |
1245 |
.SH |
1246 |
SYNOPSIS |
1247 |
.LP |
1248 |
.B cspec |
1249 |
.I "l_min l_max o1 o2 ... oN" |
1250 |
.SH |
1251 |
DESCRIPTION |
1252 |
.LP |
1253 |
Assign a relative spectrum measured between |
1254 |
.I l_min |
1255 |
and |
1256 |
.I l_max |
1257 |
nanometers at evenly spaced intervals. |
1258 |
The first value, |
1259 |
.I o1 |
1260 |
corresponds to the measurement at |
1261 |
.I l_min, |
1262 |
and the last value, |
1263 |
.I oN |
1264 |
corresponds to the measurement at |
1265 |
.I l_max. |
1266 |
Values in between are separated by |
1267 |
.I "(l_max-l_min)/(N-1)" |
1268 |
nanometers. |
1269 |
All values must be non-negative, and the spectrum outside of the |
1270 |
specified range is assumed to be zero. |
1271 |
(The visible range is 380 to 780 nm.)\0 |
1272 |
The actual units and scale of the measurements do not matter, |
1273 |
since the total will be |
1274 |
normalized according to whatever the color is modifying |
1275 |
(e.g. photometric reflectance or emittance). |
1276 |
.SH |
1277 |
EXAMPLE |
1278 |
.DS |
1279 |
# Color measured at 10 nm increments from 400 to 700 |
1280 |
m reddish_cloth = |
1281 |
c |
1282 |
cspec 400 700 28.62 27.96 27.86 28.28 29.28 30.49 31.61 \\\\ |
1283 |
32.27 32.26 31.83 31.13 30.07 29.14 29.03 29.69 \\\\ |
1284 |
30.79 32.30 33.90 34.56 34.32 33.85 33.51 33.30 \\\\ |
1285 |
33.43 34.06 35.26 37.04 39.41 42.55 46.46 51.00 |
1286 |
rd 0.3210 |
1287 |
.DE |
1288 |
.SH |
1289 |
SEE ALSO |
1290 |
.LP |
1291 |
.UL c, |
1292 |
.UL cct, |
1293 |
.UL cmix, |
1294 |
.UL cxy |
1295 |
.ds RH CCT |
1296 |
.bp |
1297 |
.SH |
1298 |
NAME |
1299 |
.LP |
1300 |
cct - set the current color to a black body spectrum |
1301 |
.SH |
1302 |
SYNOPSIS |
1303 |
.LP |
1304 |
.B cct |
1305 |
.I temperature |
1306 |
.SH |
1307 |
DESCRIPTION |
1308 |
.LP |
1309 |
The |
1310 |
.UL cct |
1311 |
entity sets the current color to the spectrum of an ideal |
1312 |
black body radiating at |
1313 |
.I temperature |
1314 |
degrees Kelvin. |
1315 |
This is often the most convenient way to set the color of an |
1316 |
incandescent light source, but it is not recommended for |
1317 |
fluorescent lamps or other materials that do not fit a |
1318 |
black body spectrum. |
1319 |
.SH |
1320 |
EXAMPLE |
1321 |
.DS |
1322 |
# Define an incandescent source material at 3000 degrees K |
1323 |
m incand3000k = |
1324 |
c |
1325 |
cct 3000 |
1326 |
ed 1500 |
1327 |
.DE |
1328 |
.SH |
1329 |
SEE ALSO |
1330 |
.LP |
1331 |
.UL c, |
1332 |
.UL cmix, |
1333 |
.UL cspec, |
1334 |
.UL cxy |
1335 |
.ds RH CMIX |
1336 |
.bp |
1337 |
.SH |
1338 |
NAME |
1339 |
.LP |
1340 |
cmix - mix two or more named colors to make the current color |
1341 |
.SH |
1342 |
SYNOPSIS |
1343 |
.LP |
1344 |
.B cmix |
1345 |
.I "w1 c1 w2 c2 ..." |
1346 |
.SH |
1347 |
DESCRIPTION |
1348 |
.LP |
1349 |
The |
1350 |
.UL cmix |
1351 |
entity sums together two or more named colors using specified |
1352 |
weighting coefficients, which correspond to the relative |
1353 |
photometric brightness of each. |
1354 |
As in all color specifications, the result is normalized so the |
1355 |
absolute scale of the weights does not matter, only their relative |
1356 |
values. |
1357 |
.LP |
1358 |
If any of the colors is a spectral quantity (i.e. from a |
1359 |
.UL cspec |
1360 |
or |
1361 |
.UL cct |
1362 |
entity), then all the colors are first converted to spectral |
1363 |
quantities. |
1364 |
This is done with an approximation for CIE (x,y) chromaticities, |
1365 |
which may be problematic depending on their values. |
1366 |
In general, it is safest to add together colors that are either |
1367 |
all spectral quantities or all CIE quantities. |
1368 |
.SH |
1369 |
EXAMPLE |
1370 |
.DS |
1371 |
# Define RGB primaries for a standard color monitor |
1372 |
c R = |
1373 |
cxy 0.640 0.330 |
1374 |
c G = |
1375 |
cxy 0.290 0.600 |
1376 |
c B = |
1377 |
cxy 0.150 0.060 |
1378 |
# Mix them together in appropriate amounts for white |
1379 |
c white = |
1380 |
cmix 0.265 R 0.670 G 0.065 B |
1381 |
.DE |
1382 |
.SH |
1383 |
SEE ALSO |
1384 |
.LP |
1385 |
.UL c, |
1386 |
.UL cct, |
1387 |
.UL cspec, |
1388 |
.UL cxy |
1389 |
.ds LH Material Entities |
1390 |
.ds RH M |
1391 |
.bp |
1392 |
.SH |
1393 |
NAME |
1394 |
.LP |
1395 |
m - get or set the current material context |
1396 |
.SH |
1397 |
SYNOPSIS |
1398 |
.LP |
1399 |
.B m |
1400 |
[ |
1401 |
.I id |
1402 |
[ |
1403 |
.B = |
1404 |
[ |
1405 |
.I template |
1406 |
] |
1407 |
] |
1408 |
] |
1409 |
.SH |
1410 |
DESCRIPTION |
1411 |
.LP |
1412 |
If the |
1413 |
.UL m |
1414 |
keyword is given by itself, then it establishes |
1415 |
the unnamed material context, which is a perfect two-sided black absorber. |
1416 |
This context may be modified, but the changes will not be saved. |
1417 |
.LP |
1418 |
If the keyword is followed by an identifier |
1419 |
.I id, |
1420 |
then it reestablishes a previous context. |
1421 |
If the specified context was never defined, an error will result. |
1422 |
.LP |
1423 |
If the entity is given with an identifier |
1424 |
followed by an equals sign ('='), then a new context is established, |
1425 |
and cleared to the default material. |
1426 |
(Note that the equals sign must be separated from other |
1427 |
arguments by white space to be properly recognized.)\0 |
1428 |
If the equals sign is followed by a second identifier |
1429 |
.I template, |
1430 |
then this previously defined material will be used as a source of |
1431 |
default values instead. |
1432 |
This may be used to establish a material alias, or to modify an |
1433 |
existing material and give it a new name. |
1434 |
.LP |
1435 |
The sum of the diffuse and specular reflectances and transmittances |
1436 |
must not be greater than one (with no negative values, obviously). |
1437 |
These values are assumed to be measured at normal incidence. |
1438 |
If an index of refraction is given, this may modify the balance between |
1439 |
diffuse and specular reflectance at other incident angles. |
1440 |
If the |
1441 |
material is one-sided (see |
1442 |
.UL sides |
1443 |
entity), then it may be a dielectric interface. |
1444 |
In this case, the specular transmittance given is that which would be |
1445 |
measured at normal incidence for a pane of the material 5 mm thick. |
1446 |
This is important for figuring the actual transmittance for non-planar |
1447 |
geometries assuming a uniformly absorbing medium. |
1448 |
(Diffuse transmittance will not be affected by thickness.)\0 |
1449 |
If the index of |
1450 |
refraction has an imaginary part, then the surface is a metal and this |
1451 |
implies other properties as well. |
1452 |
The default index of refraction is that of a vacuum, i.e. (1,0). |
1453 |
.SH |
1454 |
EXAMPLE |
1455 |
.DS |
1456 |
# Define a blue enamel paint |
1457 |
m blue_enamel = |
1458 |
c |
1459 |
cxy 0.2771 0.2975 |
1460 |
rd 0.5011 |
1461 |
c |
1462 |
rs 0.0100 0.0350 |
1463 |
# Assign blue_enamel to be the color of the south wall |
1464 |
m swall_mat = blue_enamel |
1465 |
# ... |
1466 |
# South wall face |
1467 |
m swall_mat |
1468 |
f sv1 sv2 sv3 sv4 |
1469 |
.DE |
1470 |
.SH |
1471 |
SEE ALSO |
1472 |
.LP |
1473 |
.UL ed, |
1474 |
.UL ir, |
1475 |
.UL rd, |
1476 |
.UL rs, |
1477 |
.UL sides, |
1478 |
.UL td, |
1479 |
.UL ts |
1480 |
.ds RH SIDES |
1481 |
.bp |
1482 |
.SH |
1483 |
NAME |
1484 |
.LP |
1485 |
sides - set the number of sides for the current material |
1486 |
.SH |
1487 |
SYNOPSIS |
1488 |
.LP |
1489 |
.B sides |
1490 |
{ |
1491 |
.B 1 |
1492 |
| |
1493 |
.B 2 |
1494 |
} |
1495 |
.SH |
1496 |
DESCRIPTION |
1497 |
.LP |
1498 |
The |
1499 |
.UL sides |
1500 |
entity is used to set the number of sides for the current material. |
1501 |
If a surface is two-sided, then it will appear |
1502 |
identical when viewed from either the front or the back. |
1503 |
If a surface is one-sided, |
1504 |
then it appears invisible when viewed from the back side. |
1505 |
This means |
1506 |
that a transmitting object will affect the light coming in through the |
1507 |
front surface and ignore the characteristics of the back surface, |
1508 |
unless the index of refraction is set. |
1509 |
If the index of refraction is set, then the object will act as a |
1510 |
solid piece of dielectric material. |
1511 |
In either case, the transmission properties of the exiting surface |
1512 |
should be the same as the incident surface for the model to be |
1513 |
physically valid. |
1514 |
.LP |
1515 |
The default number of sides is two. |
1516 |
.SH |
1517 |
EXAMPLE |
1518 |
.DS |
1519 |
# Describe a blue crystal ball |
1520 |
m blue_crystal = |
1521 |
ir 1.650000 0 |
1522 |
# Solid dielectrics must use one-sided materials |
1523 |
sides 1 |
1524 |
c |
1525 |
rs 0.0602 0 |
1526 |
c |
1527 |
cxy 0.3127 0.2881 |
1528 |
ts 0.6425 0 |
1529 |
v sc = |
1530 |
p 10 15 1.5 |
1531 |
sph sc .02 |
1532 |
.DE |
1533 |
.SH |
1534 |
SEE ALSO |
1535 |
.LP |
1536 |
.UL ed, |
1537 |
.UL ir, |
1538 |
.UL m, |
1539 |
.UL rd, |
1540 |
.UL rs, |
1541 |
.UL td, |
1542 |
.UL ts |
1543 |
.ds RH RD |
1544 |
.bp |
1545 |
.SH |
1546 |
NAME |
1547 |
.LP |
1548 |
rd - set the diffuse reflectance for the current material |
1549 |
.SH |
1550 |
SYNOPSIS |
1551 |
.LP |
1552 |
.B rd |
1553 |
.I rho_d |
1554 |
.SH |
1555 |
DESCRIPTION |
1556 |
.LP |
1557 |
Set the diffuse reflectance for the current material to |
1558 |
.I rho_d |
1559 |
using the current color to determine the spectral characteristics. |
1560 |
This is the fraction of visible light that is reflected from a |
1561 |
surface equally in all directions according to Lambert's law, and is |
1562 |
often called the "Lambertian component." |
1563 |
Photometric reflectance is measured according to v(lambda) |
1564 |
response function of the 1931 CIE standard 2 |
1565 |
degree observer, and assumes an equal-energy white light source. |
1566 |
The value must be between zero and one, and may be further |
1567 |
restricted by the luminosity of the selected color. |
1568 |
(I.e. it is impossible to have a violet material with a photometric |
1569 |
reflectance close to one since the eye is less sensitive in this part |
1570 |
of the spectrum.)\0 |
1571 |
.LP |
1572 |
The default diffuse reflectance is zero. |
1573 |
.SH |
1574 |
EXAMPLE |
1575 |
.DS |
1576 |
# An off-white paint with 70% reflectance |
1577 |
m flat_white70 = |
1578 |
c |
1579 |
cxy .3632 .3420 |
1580 |
rd .70 |
1581 |
.DE |
1582 |
.SH |
1583 |
SEE ALSO |
1584 |
.LP |
1585 |
.UL c, |
1586 |
.UL ed, |
1587 |
.UL ir, |
1588 |
.UL m, |
1589 |
.UL rs, |
1590 |
.UL sides, |
1591 |
.UL td, |
1592 |
.UL ts |
1593 |
.ds RH TD |
1594 |
.bp |
1595 |
.SH |
1596 |
NAME |
1597 |
.LP |
1598 |
td - set the diffuse transmittance for the current material |
1599 |
.SH |
1600 |
SYNOPSIS |
1601 |
.LP |
1602 |
.B td |
1603 |
.I tau_d |
1604 |
.SH |
1605 |
DESCRIPTION |
1606 |
.LP |
1607 |
Set the diffuse transmittance for the current material to |
1608 |
.I tau_d |
1609 |
using the current color to determine the spectral characteristics. |
1610 |
This is the fraction of visible light that is transmitted through a |
1611 |
surface equally in all (transmitted) directions. |
1612 |
Like reflectance, transmittance is measured according to the |
1613 |
standard v(lambda) curve, and assumes an equal-energy white light source. |
1614 |
It is probably not possible to create a material with a diffuse |
1615 |
transmittance above 50%, since well-diffused light will be reflected |
1616 |
as well. |
1617 |
.LP |
1618 |
The default diffuse transmittance is zero. |
1619 |
.SH |
1620 |
EXAMPLE |
1621 |
.DS |
1622 |
# Model a perfect spherical diffuser, i.e. light hitting \ |
1623 |
either side will be scattered equally in all directions |
1624 |
m wonderland_diffuser = |
1625 |
c |
1626 |
td .5 |
1627 |
rd .5 |
1628 |
.DE |
1629 |
.SH |
1630 |
SEE ALSO |
1631 |
.LP |
1632 |
.UL c, |
1633 |
.UL ed, |
1634 |
.UL ir, |
1635 |
.UL m, |
1636 |
.UL rd, |
1637 |
.UL rs, |
1638 |
.UL sides, |
1639 |
.UL ts |
1640 |
.ds RH ED |
1641 |
.bp |
1642 |
.SH |
1643 |
NAME |
1644 |
.LP |
1645 |
ed - set the diffuse emittance for the current material |
1646 |
.SH |
1647 |
SYNOPSIS |
1648 |
.LP |
1649 |
.B ed |
1650 |
.I epsilon_d |
1651 |
.SH |
1652 |
DESCRIPTION |
1653 |
.LP |
1654 |
Set the diffuse emittance for the current material to |
1655 |
.I epsilon_d |
1656 |
lumens per square meter using the current color to determine the |
1657 |
spectral characteristics. |
1658 |
Note that this is emittance rather than exitance, and therefore |
1659 |
does not include reflected or transmitted light, which is a function |
1660 |
of the other material settings and the illuminated environment. |
1661 |
.LP |
1662 |
The total lumen output of a convex emitting object |
1663 |
is the radiating area of that object multiplied by its emittance. |
1664 |
Therefore, one can compute the appropriate |
1665 |
.I epsilon_d |
1666 |
value for an emitter by dividing the total lumen output by the |
1667 |
radiating area (in square meters). |
1668 |
.LP |
1669 |
The default emittance is zero. |
1670 |
.SH |
1671 |
EXAMPLE |
1672 |
.DS |
1673 |
# A 100-watt incandescent bulb (1600 lumens) modeled as a sphere |
1674 |
m |
1675 |
c |
1676 |
cct 3000 |
1677 |
ed 87712 |
1678 |
v cent = |
1679 |
p 0 0 0 |
1680 |
sph cent .0381 |
1681 |
.DE |
1682 |
.SH |
1683 |
SEE ALSO |
1684 |
.LP |
1685 |
.UL c, |
1686 |
.UL ir, |
1687 |
.UL m, |
1688 |
.UL rd, |
1689 |
.UL rs, |
1690 |
.UL sides, |
1691 |
.UL td, |
1692 |
.UL ts |
1693 |
.ds RH RS |
1694 |
.bp |
1695 |
.SH |
1696 |
NAME |
1697 |
.LP |
1698 |
rs - set the specular reflectance for the current material |
1699 |
.SH |
1700 |
SYNOPSIS |
1701 |
.LP |
1702 |
.B rs |
1703 |
.I "rho_s alpha_r" |
1704 |
.SH |
1705 |
DESCRIPTION |
1706 |
.LP |
1707 |
Set the specular reflectance for the current material to |
1708 |
.I rho_s |
1709 |
using the current color to determine the spectral characteristics. |
1710 |
The surface roughness parameter is set to |
1711 |
.I alpha_r, |
1712 |
which is the RMS height of surface variations over the |
1713 |
autocorrelation distance (equivalent to RMS facet slope). |
1714 |
A roughness value of zero means a perfectly smooth surface, and |
1715 |
values greater than 0.2 are unusual. |
1716 |
(See application notes section 6.1.2 for a comparison between the |
1717 |
roughness parameter and Phong specular power.)\0 |
1718 |
.LP |
1719 |
The default specular reflectance is zero. |
1720 |
.SH |
1721 |
EXAMPLE |
1722 |
.DS |
1723 |
# Define a slightly rough brass metallic surface |
1724 |
m rough_brass = |
1725 |
c |
1726 |
cxy .3820 .4035 |
1727 |
# 30% specular, 9% diffuse |
1728 |
rs .30 .08 |
1729 |
rd .09 |
1730 |
.DE |
1731 |
.SH |
1732 |
SEE ALSO |
1733 |
.LP |
1734 |
.UL c, |
1735 |
.UL ed, |
1736 |
.UL ir, |
1737 |
.UL m, |
1738 |
.UL rd, |
1739 |
.UL sides, |
1740 |
.UL td, |
1741 |
.UL ts |
1742 |
.ds RH TS |
1743 |
.bp |
1744 |
.SH |
1745 |
NAME |
1746 |
.LP |
1747 |
ts - set the specular transmittance for the current material |
1748 |
.SH |
1749 |
SYNOPSIS |
1750 |
.LP |
1751 |
.B ts |
1752 |
.I "tau_s alpha_t" |
1753 |
.SH |
1754 |
DESCRIPTION |
1755 |
.LP |
1756 |
Set the specular transmittance for the current material to |
1757 |
.I tau_s |
1758 |
using the current color to determine the spectral characteristics. |
1759 |
The effective surface roughness is set to |
1760 |
.I alpha_t. |
1761 |
Rays will be transmitted with the same distribution as they would |
1762 |
have been reflected with if this roughness value were given to the |
1763 |
.UL rs |
1764 |
entity. |
1765 |
.LP |
1766 |
The default specular transmittance is zero. |
1767 |
.SH |
1768 |
EXAMPLE |
1769 |
.DS |
1770 |
# Define a green glass material (58% transmittance) |
1771 |
m glass = |
1772 |
sides 2 |
1773 |
ir 1.52 0 |
1774 |
c |
1775 |
rs 0.0725 0 |
1776 |
c |
1777 |
cxy .23 .38 |
1778 |
ts 0.5815 0 |
1779 |
# Define an uncolored translucent plastic (40% transmittance) |
1780 |
m translucent = |
1781 |
sides 2 |
1782 |
ir 1.4 0 |
1783 |
c |
1784 |
rs .045 0 |
1785 |
ts .40 .05 |
1786 |
.DE |
1787 |
.SH |
1788 |
SEE ALSO |
1789 |
.LP |
1790 |
.UL c, |
1791 |
.UL ed, |
1792 |
.UL ir, |
1793 |
.UL m, |
1794 |
.UL rd, |
1795 |
.UL rs, |
1796 |
.UL sides, |
1797 |
.UL td |
1798 |
.ds RH IR |
1799 |
.bp |
1800 |
.SH |
1801 |
NAME |
1802 |
.LP |
1803 |
ir - set the complex index of refraction for the current material |
1804 |
.SH |
1805 |
SYNOPSIS |
1806 |
.LP |
1807 |
.B ir |
1808 |
.I "n_real n_imag" |
1809 |
.SH |
1810 |
DESCRIPTION |
1811 |
.LP |
1812 |
Set the index of refraction for the current material to |
1813 |
.I (n_real,n_imag). |
1814 |
If the material is a dielectric (as opposed to metallic), then |
1815 |
.I n_imag |
1816 |
should be zero. |
1817 |
For solid dielectric objects, the material should be made one-sided. |
1818 |
If it is being used for thin objects, then a two-sided |
1819 |
material is appropriate. |
1820 |
(See the |
1821 |
.UL sides |
1822 |
entity.)\0 |
1823 |
.LP |
1824 |
The default index of refraction is that of a vacuum, (1,0). |
1825 |
.SH |
1826 |
EXAMPLE |
1827 |
.DS |
1828 |
# Define polished aluminum material |
1829 |
m polished_aluminum = |
1830 |
# Complex index of refraction (from physics table) |
1831 |
ir .770058 6.08351 |
1832 |
c |
1833 |
rs .75 0 |
1834 |
.DE |
1835 |
.SH |
1836 |
SEE ALSO |
1837 |
.LP |
1838 |
.UL c, |
1839 |
.UL ed, |
1840 |
.UL m, |
1841 |
.UL rd, |
1842 |
.UL rs, |
1843 |
.UL sides, |
1844 |
.UL td, |
1845 |
.UL ts |
1846 |
.ds LH Vertex Entities |
1847 |
.ds RH V |
1848 |
.bp |
1849 |
.SH |
1850 |
NAME |
1851 |
.LP |
1852 |
v - get or set the current vertex context |
1853 |
.SH |
1854 |
SYNOPSIS |
1855 |
.LP |
1856 |
.B v |
1857 |
[ |
1858 |
.I id |
1859 |
[ |
1860 |
.B = |
1861 |
[ |
1862 |
.I template |
1863 |
] |
1864 |
] |
1865 |
] |
1866 |
.SH |
1867 |
DESCRIPTION |
1868 |
.LP |
1869 |
If the |
1870 |
.UL v |
1871 |
keyword is given by itself, then it establishes |
1872 |
the unnamed vertex context, which is the origin with no normal. |
1873 |
This context may be modified, but the changes will not be saved. |
1874 |
(The unnamed vertex is never used except as a source of default |
1875 |
values since all geometric entities call their vertices by name.)\0 |
1876 |
.LP |
1877 |
If the keyword is followed by an identifier |
1878 |
.I id, |
1879 |
then it reestablishes a previous context. |
1880 |
If the specified context was never defined, an error will result. |
1881 |
.LP |
1882 |
If the entity is given with an identifier |
1883 |
followed by an equals sign ('='), then a new context is established, |
1884 |
and cleared to the default vertex (the origin). |
1885 |
(Note that the equals sign must be separated from other |
1886 |
arguments by white space to be properly recognized.)\0 |
1887 |
If the equals sign is followed by a second identifier |
1888 |
.I template, |
1889 |
then this previously defined vertex will be used as a source of |
1890 |
default values instead. |
1891 |
This may be used to establish a vertex alias, or to modify an |
1892 |
existing vertex and give it a new name. |
1893 |
.LP |
1894 |
A non-zero vertex normal must be given for |
1895 |
certain entities, specifically |
1896 |
.UL ring |
1897 |
and |
1898 |
.UL torus |
1899 |
require a normal direction. |
1900 |
An |
1901 |
.UL f |
1902 |
entity will interpolate vertex normals if given, and |
1903 |
use the polygon plane normal otherwise. |
1904 |
See the |
1905 |
.UL prism |
1906 |
entry for an explanation of how it interprets and uses vertex |
1907 |
normals. |
1908 |
The other entities ignore vertex normals if present. |
1909 |
.LP |
1910 |
The actual position and normal direction for a vertex is determined |
1911 |
at the time of use by a geometric entity. |
1912 |
Specifically, the transformation in effect at the time the vertex is |
1913 |
defined is irrelevant. |
1914 |
The only transformation that matters is the one that is applied to |
1915 |
the geometry itself. |
1916 |
This prevents double-transformation of vertices and allows one set |
1917 |
of vertices to be used for multiple purposes, e.g. the front and |
1918 |
back sides of a drawer. |
1919 |
.SH |
1920 |
EXAMPLE |
1921 |
.DS |
1922 |
# Make a capped cylinder |
1923 |
v end1 = |
1924 |
p 0 0 0 |
1925 |
n 0 0 -1 |
1926 |
v end2 = |
1927 |
p 0 0 1 |
1928 |
cyl end1 1.2 end2 |
1929 |
# Forgot normal for end2 |
1930 |
v end2 |
1931 |
n 0 0 1 |
1932 |
ring end1 0 1.2 |
1933 |
ring end2 0 1.2 |
1934 |
.DE |
1935 |
.SH |
1936 |
SEE ALSO |
1937 |
.LP |
1938 |
.UL cone, |
1939 |
.UL cyl, |
1940 |
.UL f, |
1941 |
.UL n, |
1942 |
.UL p, |
1943 |
.UL prism, |
1944 |
.UL ring, |
1945 |
.UL sph, |
1946 |
.UL torus |
1947 |
.ds RH P |
1948 |
.bp |
1949 |
.SH |
1950 |
NAME |
1951 |
.LP |
1952 |
p - set the point location for the current vertex |
1953 |
.SH |
1954 |
SYNOPSIS |
1955 |
.LP |
1956 |
.B p |
1957 |
.I "px py pz" |
1958 |
.SH |
1959 |
DESCRIPTION |
1960 |
.LP |
1961 |
Set the 3-dimensional position for the current vertex to |
1962 |
.I (px,py,pz). |
1963 |
The actual position of the vertex will be determined by the |
1964 |
transformation in effect at the time the vertex is applied to a |
1965 |
geometric surface entity. |
1966 |
The transform current when the position is set is irrelevant. |
1967 |
.LP |
1968 |
The default vertex position is the origin, (0,0,0). |
1969 |
.SH |
1970 |
EXAMPLE |
1971 |
.DS |
1972 |
# Make a small circle of 6 spheres |
1973 |
v scent = |
1974 |
p 1 0 0 |
1975 |
xf -a 6 -rz 60 |
1976 |
sph scent .05 |
1977 |
xf |
1978 |
.DE |
1979 |
.SH |
1980 |
SEE ALSO |
1981 |
.LP |
1982 |
.UL cone, |
1983 |
.UL cyl, |
1984 |
.UL f, |
1985 |
.UL n, |
1986 |
.UL prism, |
1987 |
.UL ring, |
1988 |
.UL sph, |
1989 |
.UL torus, |
1990 |
.UL v |
1991 |
.ds RH N |
1992 |
.bp |
1993 |
.SH |
1994 |
NAME |
1995 |
.LP |
1996 |
n - set the surface normal direction for the current vertex |
1997 |
.SH |
1998 |
SYNOPSIS |
1999 |
.LP |
2000 |
.B n |
2001 |
.I "dx dy dz" |
2002 |
.SH |
2003 |
DESCRIPTION |
2004 |
.LP |
2005 |
Set the 3-dimensional surface normal for the current vertex to the |
2006 |
normalized vector along |
2007 |
.I (dx,dy,dz). |
2008 |
If this vector is zero, then the surface normal is effectively |
2009 |
unset. |
2010 |
The actual surface normal orientation of the vertex will be determined |
2011 |
by the transformation in effect at the time the vertex is applied to a |
2012 |
geometric surface entity. |
2013 |
The current transform when the normal is set is irrelevant. |
2014 |
.LP |
2015 |
The default vertex normal is the zero vector (i.e. no normal). |
2016 |
.SH |
2017 |
EXAMPLE |
2018 |
.DS |
2019 |
# Make a chain of 10 interlocking doughnuts |
2020 |
v tcent = |
2021 |
p 0 0 0 |
2022 |
n 0 1 0 |
2023 |
xf -a 10 -rx 90 -t .2 0 0 |
2024 |
torus tcent .1 .2 |
2025 |
xf |
2026 |
.DE |
2027 |
.SH |
2028 |
SEE ALSO |
2029 |
.LP |
2030 |
.UL f, |
2031 |
.UL p, |
2032 |
.UL prism, |
2033 |
.UL ring, |
2034 |
.UL torus, |
2035 |
.UL v |
2036 |
.ds LH Geometric Entities |
2037 |
.ds RH F |
2038 |
.bp |
2039 |
.SH |
2040 |
NAME |
2041 |
.LP |
2042 |
f - create an N-sided polygonal face |
2043 |
.SH |
2044 |
SYNOPSIS |
2045 |
.LP |
2046 |
.B f |
2047 |
.I "v1 v2 ... vN" |
2048 |
.SH |
2049 |
DESCRIPTION |
2050 |
.LP |
2051 |
Create a polygonal face made of the current material |
2052 |
by connecting the named vertices in order, and connecting the last |
2053 |
vertex to the first. |
2054 |
There must be at least three vertices, and if any vertex is undefined, |
2055 |
an error will result. |
2056 |
.LP |
2057 |
The surface orientation is determined by the right-hand rule; when |
2058 |
the curl of the fingers follows the given order of the vertices, the |
2059 |
surface normal points in the thumb direction. |
2060 |
Face vertices should be coplanar, though this is difficult to guarantee |
2061 |
in a 3-dimensional specification. |
2062 |
.LP |
2063 |
If any vertices have associated surface normals, they will be used |
2064 |
instead of the average plane normal, though it is safest to specify |
2065 |
either all normals or no normals, and to stick with triangles |
2066 |
when normals are used. |
2067 |
Also, specified normals should point in the general direction of the |
2068 |
surface for best results. |
2069 |
.LP |
2070 |
There is no explicit representation of holes in MGF. A hole must be |
2071 |
represented implicitly by connecting vertices to form "seams." For |
2072 |
example, a wall with a window in it might look as shown in Figure 1. |
2073 |
In many systems, the wall itself would be represented with the first |
2074 |
list of vertices, (v1,v2,v3,v4) and the hole associated with that |
2075 |
wall as a second set of vertices (v5,v6,v7,v8). In MGF, we must |
2076 |
give the whole thing as a single polygon, connecting the vertices so |
2077 |
as to create a "seam," as shown in Figure 2. |
2078 |
This could be written in MGF as "f v1 v2 v3 v4 v5 v6 v7 v8 v5 v4". |
2079 |
.LP |
2080 |
It is very important that the order of the hole be opposite to the |
2081 |
order of the outer perimeter, otherwise the polygon will be |
2082 |
"twisted" on top of itself. Note also that the seam was traversed |
2083 |
in both directions, once going from v4 to v5, and again returning |
2084 |
from v5 to v4. This is a necessary condition for a proper seam. |
2085 |
.LP |
2086 |
The choice of vertices to make into a seam is somewhat arbitrary, but |
2087 |
some rendering systems may not give sane results if you cross over a |
2088 |
hole with part of your seam. If we had chosen to create the seam |
2089 |
between v2 and v5 in the above example instead of v4 and v5, the seam |
2090 |
would cross our hole and may not render correctly\(dg. |
2091 |
.FS |
2092 |
\(dgFor systems that |
2093 |
are sensitive to this, it is probably safest for their MGF |
2094 |
loader/translator to re-expresses seams in terms of holes again, which can |
2095 |
be done easily so long as vertices are shared in the fashion shown. |
2096 |
.FE |
2097 |
.bp |
2098 |
Replace this page with the first page from "figures.ps". |
2099 |
.bp |
2100 |
.SH |
2101 |
EXAMPLE |
2102 |
.DS |
2103 |
# Make a pyramid |
2104 |
v apex = |
2105 |
p 1 1 1 |
2106 |
v base0 = |
2107 |
p 0 0 0 |
2108 |
v base1 = |
2109 |
p 0 2 0 |
2110 |
v base2 = |
2111 |
p 2 2 0 |
2112 |
v base3 = |
2113 |
p 2 0 0 |
2114 |
# Bottom |
2115 |
f base0 base1 base2 base3 |
2116 |
# Sides |
2117 |
f base0 apex base1 |
2118 |
f base1 apex base2 |
2119 |
f base2 apex base3 |
2120 |
f base3 apex base0 |
2121 |
.DE |
2122 |
.SH |
2123 |
SEE ALSO |
2124 |
.LP |
2125 |
.UL cone, |
2126 |
.UL cyl, |
2127 |
.UL m, |
2128 |
.UL prism, |
2129 |
.UL ring, |
2130 |
.UL sph, |
2131 |
.UL torus, |
2132 |
.UL v |
2133 |
.ds RH SPH |
2134 |
.bp |
2135 |
.SH |
2136 |
NAME |
2137 |
.LP |
2138 |
sph - create a sphere |
2139 |
.SH |
2140 |
SYNOPSIS |
2141 |
.LP |
2142 |
.B sph |
2143 |
.I "vc rad" |
2144 |
.SH |
2145 |
DESCRIPTION |
2146 |
.LP |
2147 |
Create a sphere made of the current material with its center at the |
2148 |
named vertex |
2149 |
.I vc |
2150 |
and a radius of |
2151 |
.I rad. |
2152 |
If the vertex is undefined an error will result. |
2153 |
.LP |
2154 |
The surface normal is usually directed outward, but will be directed |
2155 |
inward if the given radius is negative. |
2156 |
(This typically matters only for one-sided materials.)\0 |
2157 |
A zero radius is illegal. |
2158 |
.SH |
2159 |
EXAMPLE |
2160 |
.DS |
2161 |
# Create a thick glass sphere with a hollow inside |
2162 |
m glass = |
2163 |
sides 1 |
2164 |
ir 1.52 0 |
2165 |
c |
2166 |
rs .06 0 |
2167 |
ts .88 0 |
2168 |
v cent = |
2169 |
p 0 0 1.1 |
2170 |
# The outer shell |
2171 |
sph cent .1 |
2172 |
# The inner bubble |
2173 |
sph cent -.08 |
2174 |
.DE |
2175 |
.SH |
2176 |
SEE ALSO |
2177 |
.LP |
2178 |
.UL cone, |
2179 |
.UL cyl, |
2180 |
.UL f, |
2181 |
.UL m, |
2182 |
.UL prism, |
2183 |
.UL ring, |
2184 |
.UL torus, |
2185 |
.UL v |
2186 |
.ds RH CYL |
2187 |
.bp |
2188 |
.SH |
2189 |
NAME |
2190 |
.LP |
2191 |
cyl - create an open-ended, truncated right cylinder |
2192 |
.SH |
2193 |
SYNOPSIS |
2194 |
.LP |
2195 |
.B cyl |
2196 |
.I "v1 rad v2" |
2197 |
.SH |
2198 |
DESCRIPTION |
2199 |
.LP |
2200 |
Create a truncated right cylinder of radius |
2201 |
.I rad |
2202 |
using the current material, starting at the named vertex |
2203 |
.I v1 |
2204 |
and continuing to |
2205 |
.I v2. |
2206 |
The ends will be open, but may be capped using the |
2207 |
.UL ring |
2208 |
entity if desired. |
2209 |
.LP |
2210 |
The surface normal will usually be directed outward, but may be |
2211 |
directed inward by giving a negative value for |
2212 |
.I rad. |
2213 |
A zero radius is illegal, and |
2214 |
.I v1 |
2215 |
cannot equal |
2216 |
.I v2. |
2217 |
.SH |
2218 |
EXAMPLE |
2219 |
.DS |
2220 |
# A stylus with one rounded and one pointed end |
2221 |
o stylus |
2222 |
v vtip0 = |
2223 |
p 0 0 0 |
2224 |
v vtip1 = |
2225 |
p 0 0 .005 |
2226 |
v vend = |
2227 |
p 0 0 .05 |
2228 |
cyl vtip1 .0015 vend |
2229 |
sph vend .0015 |
2230 |
cone vtip0 0 vtip1 .0015 |
2231 |
o |
2232 |
.DE |
2233 |
.SH |
2234 |
SEE ALSO |
2235 |
.LP |
2236 |
.UL cone, |
2237 |
.UL f, |
2238 |
.UL m, |
2239 |
.UL prism, |
2240 |
.UL ring, |
2241 |
.UL sph, |
2242 |
.UL torus, |
2243 |
.UL v |
2244 |
.ds RH CONE |
2245 |
.bp |
2246 |
.SH |
2247 |
NAME |
2248 |
.LP |
2249 |
cone - create an open-ended, truncated right cone |
2250 |
.SH |
2251 |
SYNOPSIS |
2252 |
.LP |
2253 |
.B cone |
2254 |
.I "v1 rad1 v2 rad2" |
2255 |
.SH |
2256 |
DESCRIPTION |
2257 |
.LP |
2258 |
Create a truncated right cone using the current material. |
2259 |
The starting radius is |
2260 |
.I rad1 |
2261 |
at |
2262 |
.I v1 |
2263 |
and the ending radius is |
2264 |
is |
2265 |
.I rad2 |
2266 |
at |
2267 |
.I v2. |
2268 |
The ends will be open, but may be capped using the |
2269 |
.UL ring |
2270 |
entity if desired. |
2271 |
.LP |
2272 |
The surface normal will usually be directed outward, but may be |
2273 |
directed inward by giving negative values for both radii. |
2274 |
(It is illegal for the signs of the two radii to disagree.)\0 |
2275 |
One but not both radii may be zero, indicating that the cone comes |
2276 |
to a point. |
2277 |
.LP |
2278 |
Although it is not strictly forbidden to have equal cone radii, the |
2279 |
.UL cyl |
2280 |
entity should be used in such cases. |
2281 |
Likewise, the |
2282 |
.UL ring |
2283 |
entity must be used if |
2284 |
.I v1 |
2285 |
and |
2286 |
.I v2 |
2287 |
are equal. |
2288 |
.SH |
2289 |
EXAMPLE |
2290 |
.DS |
2291 |
# A parasol |
2292 |
o parasol |
2293 |
v v1 = |
2294 |
p 0 0 0 |
2295 |
v v2 = |
2296 |
p 0 0 .75 |
2297 |
v v3 = |
2298 |
p 0 0 .7 |
2299 |
m handle_mat |
2300 |
cyl v1 .002 v2 |
2301 |
m parasol_paper |
2302 |
cyl v2 0 v3 .33 |
2303 |
o |
2304 |
.DE |
2305 |
.SH |
2306 |
SEE ALSO |
2307 |
.LP |
2308 |
.UL cyl, |
2309 |
.UL f, |
2310 |
.UL m, |
2311 |
.UL prism, |
2312 |
.UL ring, |
2313 |
.UL sph, |
2314 |
.UL torus, |
2315 |
.UL v |
2316 |
.ds RH PRISM |
2317 |
.bp |
2318 |
.SH |
2319 |
NAME |
2320 |
.LP |
2321 |
prism - create a closed right prism |
2322 |
.SH |
2323 |
SYNOPSIS |
2324 |
.LP |
2325 |
.B prism |
2326 |
.I "v1 v2 ... vN length" |
2327 |
.SH |
2328 |
DESCRIPTION |
2329 |
.LP |
2330 |
Create a closed right prism using the current material. |
2331 |
One end face will be enclosed by the named vertices, and the |
2332 |
opposite end face will be a mirror image at a distance |
2333 |
.I length |
2334 |
from the original. |
2335 |
The edges will be extruded into N quadrilaterals connecting |
2336 |
the two end faces. |
2337 |
.LP |
2338 |
The order of vertices determines the original face orientation |
2339 |
according to the right-hand rule as explained for the |
2340 |
.UL f |
2341 |
entity. |
2342 |
Normally, the prism is extruded in the direction opposite to the |
2343 |
original surface normal, resulting in faces that all point outward. |
2344 |
If the specified |
2345 |
.I length |
2346 |
is negative, the prism will be extruded above the original face |
2347 |
and all surface normals will point inward. |
2348 |
.LP |
2349 |
If the vertices have associated normals, they are applied to the |
2350 |
side faces only, and should generally point in the appropriate |
2351 |
direction (i.e. in or out depending on whether |
2352 |
.I length |
2353 |
is negative or positive). |
2354 |
.SH |
2355 |
EXAMPLE |
2356 |
.DS |
2357 |
# Make a unit cube starting at the origin and \\\\ |
2358 |
extending to the positive octant |
2359 |
v cv0 = |
2360 |
p 0 0 0 |
2361 |
v cv1 = |
2362 |
p 0 1 0 |
2363 |
v cv2 = |
2364 |
p 1 1 0 |
2365 |
v cv3 = |
2366 |
p 1 0 0 |
2367 |
# Right hand rule has original face looking in -Z direction |
2368 |
prism cv0 cv1 cv2 cv3 1 |
2369 |
.DE |
2370 |
.SH |
2371 |
SEE ALSO |
2372 |
.LP |
2373 |
.UL cyl, |
2374 |
.UL cone, |
2375 |
.UL f, |
2376 |
.UL m, |
2377 |
.UL ring, |
2378 |
.UL sph, |
2379 |
.UL torus, |
2380 |
.UL v |
2381 |
.ds RH RING |
2382 |
.bp |
2383 |
.SH |
2384 |
NAME |
2385 |
.LP |
2386 |
ring - create a circular ring with inner and outer radii |
2387 |
.SH |
2388 |
SYNOPSIS |
2389 |
.LP |
2390 |
.B cyl |
2391 |
.I "vc rmin rmax" |
2392 |
.SH |
2393 |
DESCRIPTION |
2394 |
.LP |
2395 |
Create a circular face of the current material centered on the named |
2396 |
vertex |
2397 |
.I vc |
2398 |
with an inner radius of |
2399 |
.I rmin |
2400 |
and an outer radius of |
2401 |
.I rmax. |
2402 |
The surface orientation is determined by the normal vector |
2403 |
associated with |
2404 |
.I vc. |
2405 |
If this vertex is undefined or has no normal, an error will result. |
2406 |
The minimum radius may be equal to but not less than zero, and the |
2407 |
maximum radius must be strictly greater than the minimum. |
2408 |
.SH |
2409 |
EXAMPLE |
2410 |
.DS |
2411 |
# The proverbial brass ring |
2412 |
o brass_ring |
2413 |
m brass |
2414 |
v end1 = |
2415 |
p 0 -.005 0 |
2416 |
n 0 -1 0 |
2417 |
v end2 = |
2418 |
p 0 .005 0 |
2419 |
n 0 1 0 |
2420 |
ring end1 .02 .03 |
2421 |
cyl end1 .03 end2 |
2422 |
ring end2 .02 .03 |
2423 |
cyl end2 -.02 end1 |
2424 |
o |
2425 |
.DE |
2426 |
.SH |
2427 |
SEE ALSO |
2428 |
.LP |
2429 |
.UL cyl, |
2430 |
.UL cone, |
2431 |
.UL f, |
2432 |
.UL m, |
2433 |
.UL prism, |
2434 |
.UL sph, |
2435 |
.UL torus, |
2436 |
.UL v |
2437 |
.ds RH TORUS |
2438 |
.bp |
2439 |
.SH |
2440 |
NAME |
2441 |
.LP |
2442 |
torus - create a regular torus |
2443 |
.SH |
2444 |
SYNOPSIS |
2445 |
.LP |
2446 |
.B torus |
2447 |
.I "vc rmin rmax" |
2448 |
.SH |
2449 |
DESCRIPTION |
2450 |
.LP |
2451 |
Create a torus of the current material centered on the named vertex |
2452 |
.I vc |
2453 |
with an inner radius of |
2454 |
.I rmin |
2455 |
and an outer radius of |
2456 |
.I rmax. |
2457 |
The plane of the torus will be perpendicular to the normal vector |
2458 |
associated with |
2459 |
.I vc. |
2460 |
If this vertex is undefined or has no normal, an error will result. |
2461 |
.LP |
2462 |
If a torus with an inward facing surface normal is desired, |
2463 |
.I rmin |
2464 |
and |
2465 |
.I rmax |
2466 |
may be negative. |
2467 |
The minimum radius may be zero, but may not be negative when |
2468 |
.I rmax |
2469 |
is positive or vice versa. |
2470 |
The magnitude or |
2471 |
.I rmax |
2472 |
must always be strictly greater than that of |
2473 |
.I rmin. |
2474 |
.SH |
2475 |
EXAMPLE |
2476 |
.DS |
2477 |
# The proverbial brass ring -- easy grip version |
2478 |
o brass_ring |
2479 |
m brass |
2480 |
v center = |
2481 |
p 0 0 0 |
2482 |
n 0 1 0 |
2483 |
torus center .02 .03 |
2484 |
o |
2485 |
.DE |
2486 |
.SH |
2487 |
SEE ALSO |
2488 |
.LP |
2489 |
.UL cyl, |
2490 |
.UL cone, |
2491 |
.UL f, |
2492 |
.UL m, |
2493 |
.UL prism, |
2494 |
.UL ring, |
2495 |
.UL sph, |
2496 |
.UL v |
2497 |
.ds RH |
2498 |
.ds LH |
2499 |
.bp |
2500 |
.NH |
2501 |
MGF Translators |
2502 |
.LP |
2503 |
Initially, there are four translators for MGF data, but only |
2504 |
one of these is distributed with the MGF parser itself, |
2505 |
.I mgfilt. |
2506 |
Two of the other translators, |
2507 |
.I mgf2rad |
2508 |
and |
2509 |
.I rad2mgf |
2510 |
convert between MGF and the Radiance scene description language, |
2511 |
and are distributed for free with the rest of the Radiance |
2512 |
package\(dg. |
2513 |
.FS |
2514 |
\(dgRadiance is available by anonymous ftp from hobbes.lbl.gov and |
2515 |
nestor.epfl.ch, or by WWW from |
2516 |
"http://radsite.lbl.gov/radiance/HOME.html" |
2517 |
.FE |
2518 |
A third translator, |
2519 |
.I mgf2meta, |
2520 |
converts to a 2-dimensional line plot, and is also |
2521 |
distributed with Radiance. |
2522 |
.LP |
2523 |
Mgfilt is a simple but useful utility that takes MGF on its input |
2524 |
and produces MGF on its output. |
2525 |
It uses the parser to convert entities that are not wanted or |
2526 |
understood, and produces only the requested ones. |
2527 |
This is useful for seeing what exactly a program must understand |
2528 |
when it supports a given set of entities, and may serve as a |
2529 |
substitute for linking to the parser library for programmers who |
2530 |
wish to interpret the ASCII input directly but without all the |
2531 |
unwanted entities. |
2532 |
In future releases of MGF, this utility will also be handy for |
2533 |
taking new entities and producing older versions of MGF for |
2534 |
translators that have not yet been updated properly. |
2535 |
.ds LH Translators |
2536 |
.ds RH MGFILT |
2537 |
.bp |
2538 |
.SH |
2539 |
NAME |
2540 |
.LP |
2541 |
mgfilt - get usable MGF entities from input |
2542 |
.SH |
2543 |
SYNOPSIS |
2544 |
.LP |
2545 |
.B mgfilt |
2546 |
.B version |
2547 |
[ |
2548 |
.B input .. |
2549 |
] |
2550 |
.br |
2551 |
or |
2552 |
.br |
2553 |
.B mgfilt |
2554 |
.B "e1,e2,.." |
2555 |
[ |
2556 |
.B input .. |
2557 |
] |
2558 |
.SH |
2559 |
DESCRIPTION |
2560 |
.LP |
2561 |
.I Mgfilt |
2562 |
takes one or more MGF input files and converts all the entities to |
2563 |
the types listed. |
2564 |
In the first form, a single integer is given for the |
2565 |
.I version |
2566 |
of MGF that is to be produced. |
2567 |
Since MGF is in its first major release, this is not yet a useful |
2568 |
form, but it will be when the second major release comes out. |
2569 |
.LP |
2570 |
In the second form, |
2571 |
.I mgfilt |
2572 |
produces only the entities listed in the first argument, which must |
2573 |
be comma-separated. |
2574 |
The listed entity order is not important, but all entities given |
2575 |
must be defined in the current version of MGF. |
2576 |
Unknown entities will be summarily discarded on the input, and a |
2577 |
warning message will be printed to the standard error. |
2578 |
.SH |
2579 |
EXAMPLES |
2580 |
.LP |
2581 |
To take an MGF version 3 file and send it to a version 2 |
2582 |
translator: |
2583 |
.IP |
2584 |
mgfilt 2 input.mgf | mgf2rad > input.rad |
2585 |
.LP |
2586 |
To take an MGF file and produce only flat polygonal faces |
2587 |
with no materials: |
2588 |
.IP |
2589 |
mgfilt f,v,p,xf input.mgf > flatpoly.mgf |
2590 |
.SH |
2591 |
SEE ALSO |
2592 |
.LP |
2593 |
mgf2rad, rad2mgf |
2594 |
.ds RH MGF2RAD |
2595 |
.bp |
2596 |
.SH |
2597 |
NAME |
2598 |
.LP |
2599 |
mgf2rad - convert Materials and Geometry Format file to RADIANCE description |
2600 |
.SH |
2601 |
SYNOPSIS |
2602 |
.LP |
2603 |
.B mgf2rad |
2604 |
[ |
2605 |
.B "\-m matfile" |
2606 |
][ |
2607 |
.B "\-e mult" |
2608 |
][ |
2609 |
.B "\-g dist" |
2610 |
] |
2611 |
[ |
2612 |
.B input .. |
2613 |
] |
2614 |
.SH |
2615 |
DESCRIPTION |
2616 |
.LP |
2617 |
.I Mgf2rad |
2618 |
converts one or more Materials and Geometry Format (MGF) |
2619 |
files to a RADIANCE scene description. |
2620 |
By definition, all output dimensions are in meters. |
2621 |
The material names and properties |
2622 |
for the surfaces will be those assigned in MGF. |
2623 |
Any materials not defined in MGF will result in an error during |
2624 |
translation. |
2625 |
Light sources are described inline as IES luminaire files, and |
2626 |
.I mgf2rad |
2627 |
calls the program |
2628 |
.I ies2rad(1) |
2629 |
to translate these files. |
2630 |
If an IES file in turn contains an MGF description of the local |
2631 |
fixture geometry, this may result in a recursive call to |
2632 |
.I mgf2rad, |
2633 |
which is normal and should be transparent. |
2634 |
The only side-effect of this additional translation is the |
2635 |
appearance of other RADIANCE scene and data files produced |
2636 |
automatically by |
2637 |
.I ies2rad. |
2638 |
.LP |
2639 |
The |
2640 |
.I \-m |
2641 |
option may be used to put all the translated materials into a separate |
2642 |
RADIANCE file. |
2643 |
This is not always advisable, as any given material name may be |
2644 |
reused at different points in the MGF description, and writing them |
2645 |
to a separate file loses the contextual association between |
2646 |
materials and surfaces. |
2647 |
As long as unique material names are used throughout the MGF |
2648 |
description and material properties are not redefined, there |
2649 |
will be no problem. |
2650 |
Note that this is the only way to get all the translated materials |
2651 |
into a single file, since no output is produced for unreferenced |
2652 |
materials; i.e. translating just the MGF materials does not work. |
2653 |
.LP |
2654 |
The |
2655 |
.I \-e |
2656 |
option may be used to multiply all the emission values by the |
2657 |
given |
2658 |
.I mult |
2659 |
factor. |
2660 |
The |
2661 |
.I \-g |
2662 |
option may be used to establish a glow distance (in meters) |
2663 |
for all emitting surfaces. |
2664 |
These two options are employed principally by |
2665 |
.I ies2rad, |
2666 |
and are not generally useful to most users. |
2667 |
.SH |
2668 |
EXAMPLES |
2669 |
.LP |
2670 |
To translate two MGF files into one RADIANCE materials file and |
2671 |
one geometry file: |
2672 |
.IP |
2673 |
mgf2rad -m materials.rad building1.mgf building2.mgf > building1+2.rad |
2674 |
.LP |
2675 |
To create an octree directly from two MGF files and one RADIANCE |
2676 |
file: |
2677 |
.IP |
2678 |
oconv '\\!mgf2rad materials.mgf scene.mgf' source.rad > scene.oct |
2679 |
.SH |
2680 |
FILES |
2681 |
.LP |
2682 |
tmesh.cal Used to smooth polygonal geometry |
2683 |
.br |
2684 |
*.rad RADIANCE source descriptions created by ies2rad |
2685 |
.br |
2686 |
*.dat RADIANCE source data created by ies2rad |
2687 |
.br |
2688 |
source.cal Used for IES source coordinates |
2689 |
.SH |
2690 |
AUTHOR |
2691 |
.LP |
2692 |
Greg Ward |
2693 |
.SH |
2694 |
SEE ALSO |
2695 |
.LP |
2696 |
ies2rad(1), mgf2meta(1), obj2rad(1), oconv(1), rad2mgf(1), xform(1) |
2697 |
.ds RH RAD2MGF |
2698 |
.bp |
2699 |
.SH |
2700 |
NAME |
2701 |
.LP |
2702 |
rad2mgf - convert RADIANCE scene description to Materials and Geometry Format |
2703 |
.SH |
2704 |
SYNOPSIS |
2705 |
.LP |
2706 |
.B rad2mgf |
2707 |
[ |
2708 |
.B \-dU |
2709 |
] |
2710 |
[ |
2711 |
.B input .. |
2712 |
] |
2713 |
.SH |
2714 |
DESCRIPTION |
2715 |
.LP |
2716 |
.I Rad2mgf |
2717 |
converts one or more RADIANCE scene files |
2718 |
to the Materials and Geometry Format (MGF). |
2719 |
Input units are specified with the |
2720 |
.I \-mU |
2721 |
option, where |
2722 |
.I U |
2723 |
is one of 'm' (meters), 'c' (centimeters), 'f' (feet) or 'i' |
2724 |
(inches). |
2725 |
The assumed unit is meters, which is the required output unit for |
2726 |
MGF (thus the need to know). |
2727 |
If the input dimensions are in none of these units, then the user |
2728 |
should apply |
2729 |
.I xform(1) |
2730 |
with the |
2731 |
.I \-s |
2732 |
option to bring the units into line prior to translation. |
2733 |
.LP |
2734 |
The MGF material names and properties |
2735 |
for the surfaces will be those assigned in RADIANCE. |
2736 |
If a referenced material has not been defined, then its name will |
2737 |
be invoked in the MGF output without definition, and the description |
2738 |
will be incomplete. |
2739 |
.SH |
2740 |
LIMITATIONS |
2741 |
.LP |
2742 |
Although MGF supports all of the geometric types and the most |
2743 |
common material types used in RADIANCE, there is currently no |
2744 |
support for advanced BRDF materials, patterns, textures or mixtures. |
2745 |
Also, the special types "source" and "antimatter" are not supported, |
2746 |
and all light source materials are converted to simple diffuse emitters |
2747 |
(except "illum" materials, which are converted to their alternates). |
2748 |
These primitives are reproduced as comments in the output and |
2749 |
must be replaced manually if necessary. |
2750 |
.LP |
2751 |
The RADIANCE "instance" type is treated specially. |
2752 |
.I Rad2mgf |
2753 |
converts each instance to an MGF include statement, using the corresponding |
2754 |
transformation and a file name derived from the octree name. |
2755 |
(The original octree suffix is replaced by ".mgf".)\0 |
2756 |
For this to work, the user must separately create the referenced |
2757 |
MGF files from the original RADIANCE descriptions. |
2758 |
The description file names can usually be determined using the |
2759 |
.I getinfo(1) |
2760 |
command run on the octrees in question. |
2761 |
.SH |
2762 |
EXAMPLES |
2763 |
.LP |
2764 |
To convert three RADIANCE files (in feet) to one MGF file: |
2765 |
.IP |
2766 |
mgf2rad -df file1.rad file2.rad file3.rad > scene.mgf |
2767 |
.LP |
2768 |
To translate a RADIANCE materials file to MGF: |
2769 |
.IP |
2770 |
mgf2rad materials.rad > materials.mgf |
2771 |
.SH |
2772 |
AUTHOR |
2773 |
.LP |
2774 |
Greg Ward |
2775 |
.SH |
2776 |
SEE ALSO |
2777 |
.LP |
2778 |
getinfo(1), ies2rad(1), mgf2meta(1), mgf2rad(1), obj2rad(1), oconv(1), xform(1) |
2779 |
.ds RH MGF2META |
2780 |
.bp |
2781 |
.SH |
2782 |
NAME |
2783 |
.LP |
2784 |
mgf2meta - convert Materials and Geometry Format file to Metafile graphics |
2785 |
.SH |
2786 |
SYNOPSIS |
2787 |
.LP |
2788 |
.B mgf2meta |
2789 |
[ |
2790 |
.B "-t threshold" |
2791 |
] |
2792 |
.B "{x|y|z} xmin xmax ymin ymax zmin zmax" |
2793 |
[ |
2794 |
.B input .. |
2795 |
] |
2796 |
.SH |
2797 |
DESCRIPTION |
2798 |
.LP |
2799 |
.I Mgf2meta |
2800 |
converts one or more Materials and Geometry Format (MGF) |
2801 |
files to a 2-D orthographic projection along the selected axis in the |
2802 |
.I metafile(1) |
2803 |
graphics format. |
2804 |
All geometry is clipped to the specified bounding box, and the |
2805 |
resulting orientation is as follows: |
2806 |
.sp .5 |
2807 |
.nf |
2808 |
Projection Orientation |
2809 |
======= ======== |
2810 |
x Y-axis right, Z-axis up |
2811 |
y Z-axis right, X-axis up |
2812 |
z X-axis right, Z-axis up |
2813 |
.fi |
2814 |
.LP |
2815 |
If multiple input files are given, the first file prints in black, |
2816 |
the second prints in red, the third in green and the fourth in blue. |
2817 |
If more than four input files are given, they cycle through the |
2818 |
colors again in three other line types: dashed, dotted and |
2819 |
dot-dashed. |
2820 |
.LP |
2821 |
The |
2822 |
.I \-t |
2823 |
option may be used to randomly throw out line segments that are |
2824 |
shorter than the given |
2825 |
.I threshold |
2826 |
(given as a fraction of the plot width). |
2827 |
Segments are included with a |
2828 |
probability equal to the square of the line length over the square |
2829 |
of the threshold. |
2830 |
This can greatly reduce the number of lines in the drawing (and |
2831 |
therefore improve the drawing speed) with only a modest loss in |
2832 |
quality. |
2833 |
A typical value for this parameter is 0.005. |
2834 |
.LP |
2835 |
All MGF material information is ignored on the input. |
2836 |
.SH |
2837 |
EXAMPLES |
2838 |
.LP |
2839 |
To project two MGF files along the Z-axis and display them under |
2840 |
X11: |
2841 |
.IP |
2842 |
mgf2meta z 0 10 0 15 0 9 building1.mgf building2.mgf | x11meta |
2843 |
.LP |
2844 |
To convert a RADIANCE scene to a line drawing in RADIANCE picture |
2845 |
format: |
2846 |
.IP |
2847 |
rad2mgf scene.rad | mgf2meta x `getbbox -h scene.rad` | meta2tga | |
2848 |
ra_t8 -r > scene.pic |
2849 |
.SH |
2850 |
AUTHOR |
2851 |
.LP |
2852 |
Greg Ward |
2853 |
.SH |
2854 |
SEE ALSO |
2855 |
.LP |
2856 |
getbbox(1), meta2tga(1), metafile(5), mgf2rad(1), pflip(1), |
2857 |
protate(1), psmeta(1), ra_t8(1), rad2mgf(1), t4014(1), x11meta(1) |
2858 |
.ds RH |
2859 |
.ds LH |
2860 |
.bp |
2861 |
.NH |
2862 |
MGF Parser Library |
2863 |
.LP |
2864 |
The principal motivation for creating a standard parser library for |
2865 |
MGF is to make it easy for software developers to offer some base |
2866 |
level of compliance. |
2867 |
The key to making MGF easy to support in fact is the parser, which |
2868 |
has the ability to express higher order entities in terms of |
2869 |
lower order ones. |
2870 |
For example, tori are part of the MGF specification, but if a given |
2871 |
program or translator does not support them, the parser will convert |
2872 |
them to cones. |
2873 |
If cones are not supported either, it will convert them further into |
2874 |
smoothed polygons. |
2875 |
If smoothing (vertex normal information) is not supported, it will |
2876 |
be ignored and the program will just get flat polygons. |
2877 |
This is done in such a way that future versions of the standard may |
2878 |
include new entities that old software does not even have to know |
2879 |
about, and they will be converted appropriately. |
2880 |
Forward compatibility is thus built right into the parser loading |
2881 |
mechanism itself -- the programmer simply links to the new code and |
2882 |
the new standard is supported without any further changes. |
2883 |
.SH |
2884 |
Language |
2885 |
.LP |
2886 |
The provided MGF parser is written in ANSI-C. |
2887 |
This language was chosen for reasons of portability and efficiency. |
2888 |
Almost all systems support some form of ANSI-compatible C, and many |
2889 |
languages can cross-link to C libraries without modification. |
2890 |
Backward compatibility to Kernighan and Ritchie C is achieved by |
2891 |
compiling with the -DNOPROTO flag. |
2892 |
.LP |
2893 |
All of the data structures and prototypes needed for the library |
2894 |
are in the header file "parser.h". |
2895 |
This file is the best resource for the parser and is updated with |
2896 |
each MGF release. |
2897 |
.SH |
2898 |
Mechanism |
2899 |
.LP |
2900 |
The parser works by a simple callback mechanism to routines that |
2901 |
actually interpret the individual entities. |
2902 |
Some of these routines will belong to the calling program, and some |
2903 |
will be entity support routines included in the library itself. |
2904 |
There is a global array of function pointers, called |
2905 |
.I mg_ehand. |
2906 |
It is defined thus: |
2907 |
.DS |
2908 |
extern int (*mg_ehand[MG_NENTITIES])(int argc, char **argv); |
2909 |
.DE |
2910 |
Before parsing begins, this dispatch table is initialized to point to the |
2911 |
routines that will handle each supported entity. |
2912 |
Every entity handler has the same basic prototype, which is the |
2913 |
same as the |
2914 |
.I main |
2915 |
function, i.e: |
2916 |
.DS |
2917 |
extern int \f2handler\f1(int argc, char **argv); |
2918 |
.DE |
2919 |
The first argument is the number of words in the MGF entity |
2920 |
(counting the entity itself) and the second argument is an array of |
2921 |
nul-terminated strings with the entity and its arguments. |
2922 |
The function should return zero or one of the error |
2923 |
codes defined in "parser.h". |
2924 |
A non-zero return value causes the parser to abort, returning the |
2925 |
error up through its call stack to the entry function, usually |
2926 |
.I mg_load. |
2927 |
.LP |
2928 |
A special function pointer for undefined entities is |
2929 |
defined as follows: |
2930 |
.DS |
2931 |
extern int (*mg_uhand)(int argc, char **argv); |
2932 |
.DE |
2933 |
By default, this points to the library function |
2934 |
.I mg_defuhand, |
2935 |
which prints an error message on the first unknown entity and keeps a |
2936 |
count from then on, which is stored in the global unsigned integer |
2937 |
.I mg_nunknown. |
2938 |
If the |
2939 |
.I mg_uhand |
2940 |
pointer is assigned a value of NULL instead, parsing will abort at the |
2941 |
first unrecognized entity. |
2942 |
The reason this is not the default action is that ignoring unknown entities |
2943 |
offers a certain base level of forward compatibility. |
2944 |
Ignoring things one does not understand is not the best approach, but it |
2945 |
is usually better than quitting with an error message if the input is |
2946 |
in fact valid, but is a later version of the standard. |
2947 |
The real solution is to update the interpreter by linking to a new version |
2948 |
of the parser, or use a new version of the |
2949 |
.I mgfilt |
2950 |
command to convert the new MGF input to an older standard. |
2951 |
.LP |
2952 |
The |
2953 |
.I mg_uhand |
2954 |
pointer may also be used to customize the language for a particular |
2955 |
application by adding entities, though this is discouraged because it |
2956 |
tends to weaken the standard. |
2957 |
.LP |
2958 |
The skeletal framework for an MGF loader or translator is to assign |
2959 |
function pointers to the |
2960 |
.I mg_ehand |
2961 |
array, call the parser initialization function |
2962 |
.I mg_init, |
2963 |
then call the file loader function |
2964 |
.I mg_load |
2965 |
once for each input file. |
2966 |
This will in turn make calls back to the functions assigned to |
2967 |
.I mg_ehand. |
2968 |
To give a simple example, let us look at a |
2969 |
translator that understands only flat polygonal faces, putting out |
2970 |
vertex locations immediately after each "face" keyword: |
2971 |
.DS |
2972 |
#include <stdio.h> |
2973 |
#include "parser.h" |
2974 |
|
2975 |
int |
2976 |
myfaceh(ac, av) /* face handling routine */ |
2977 |
int ac; |
2978 |
char **av; |
2979 |
{ |
2980 |
C_VERTEX *vp; /* vertex structure pointer */ |
2981 |
FVECT vert; /* vertex point location */ |
2982 |
int i; |
2983 |
|
2984 |
if (ac < 4) /* check # arguments */ |
2985 |
return(MG_EARGC); |
2986 |
printf("face\\\\n"); /* begin face output */ |
2987 |
for (i = 1; i < ac; i++) { |
2988 |
if ((vp = c_getvert(av[i])) == NULL) /* vertex from name */ |
2989 |
return(MG_EUNDEF); |
2990 |
xf_xfmpoint(vert, vp->p); /* apply transform */ |
2991 |
printf("%15.9f %15.9f %15.9f\\\\n", |
2992 |
vert[0], vert[1], vert[2]); /* output vertex */ |
2993 |
} |
2994 |
printf(";\\\\n"); /* end of face output */ |
2995 |
return(MG_OK); /* normal exit */ |
2996 |
} |
2997 |
|
2998 |
main(argc, argv) /* translate MGF file(s) */ |
2999 |
int argc; |
3000 |
char **argv; |
3001 |
{ |
3002 |
int i; |
3003 |
/* initialize dispatch table */ |
3004 |
mg_ehand[MG_E_FACE] = myfaceh; /* ours */ |
3005 |
mg_ehand[MG_E_VERTEX] = c_hvertex; /* parser lib */ |
3006 |
mg_ehand[MG_E_POINT] = c_hvertex; /* parser lib */ |
3007 |
mg_ehand[MG_E_XF] = xf_handler; /* parser lib */ |
3008 |
mg_init(); /* initialize parser */ |
3009 |
for (i = 1; i < argc; i++) /* load each file argument */ |
3010 |
if (mg_load(argv[i]) != MG_OK) /* and check for error */ |
3011 |
exit(1); |
3012 |
exit(0); /* all done! */ |
3013 |
} |
3014 |
.DE |
3015 |
Hopefully, this example demonstrates just how easy it is to |
3016 |
write an MGF translator. |
3017 |
Of course, translators get more complicated the more entity |
3018 |
types they support, but the point is that one does not |
3019 |
.I have |
3020 |
to support every entity -- the parser handles what the translator |
3021 |
does not. |
3022 |
Also, the library includes many general entity handlers, |
3023 |
further reducing the burden on the programmer. |
3024 |
This same principle means that it is not necessary to modify an |
3025 |
existing program to accommodate a new version of MGF -- one need only |
3026 |
link to the new parser library to comply with the new standard. |
3027 |
.SH |
3028 |
Division of Labor |
3029 |
.LP |
3030 |
As seen in the previous example, there are two parser routines that |
3031 |
are normally called directly in an MGF translator or loader program. |
3032 |
The first is |
3033 |
.I mg_init, |
3034 |
which takes no arguments but relies on the program having |
3035 |
initialized those parts of the global |
3036 |
.I mg_ehand |
3037 |
array it cares about. |
3038 |
The second routine is |
3039 |
.I mg_load, |
3040 |
which is called once on each input file. |
3041 |
(A third routine, |
3042 |
.I mg_clear, |
3043 |
may be called to free the parser data structures after each file or |
3044 |
after all files, if the program plans to continue rather than |
3045 |
exit.)\0 |
3046 |
.LP |
3047 |
The rest of the routines in a translator or loader program are |
3048 |
called indirectly through the |
3049 |
.I mg_ehand |
3050 |
dispatch table, and they are the ones that do the real work of |
3051 |
supporting the MGF entities. |
3052 |
In addition to converting or discarding entities that the calling |
3053 |
program does not know or care about, the parser library includes a |
3054 |
set of context handlers that greatly simplify the translation |
3055 |
process. |
3056 |
There are three handlers for each of the three named contexts and |
3057 |
their constituents, and two handlers for the two hierarchical |
3058 |
context entities. |
3059 |
To use these handlers, one simply sets the appropriate positions in the |
3060 |
.I mg_ehand |
3061 |
dispatch table to point to these functions. |
3062 |
Additional functions and global data structures provide convenient |
3063 |
access to the relevant contexts, and all of these are detailed in |
3064 |
the following manual pages. |
3065 |
.ds LH Basic Parser Routines |
3066 |
.ds RH MG_INIT |
3067 |
.bp |
3068 |
.SH |
3069 |
NAME |
3070 |
.LP |
3071 |
mg_init, mg_ehand, mg_uhand - initialize MGF entity handlers |
3072 |
.SH |
3073 |
SYNOPSIS |
3074 |
.LP |
3075 |
#include "parser.h" |
3076 |
.LP |
3077 |
.B void |
3078 |
mg_init( |
3079 |
.B void |
3080 |
) |
3081 |
.LP |
3082 |
.B int |
3083 |
mg_defuhand( |
3084 |
.B int |
3085 |
argc, |
3086 |
.B char |
3087 |
**argv ) |
3088 |
.LP |
3089 |
.B "extern int" |
3090 |
(*mg_ehand[MG_NENTITIES])( |
3091 |
.B int |
3092 |
argc, |
3093 |
.B char |
3094 |
**argv ) |
3095 |
.LP |
3096 |
.B "extern int" |
3097 |
(*mg_uhand)( |
3098 |
.B int |
3099 |
argc, |
3100 |
.B char |
3101 |
**argv ) |
3102 |
.LP |
3103 |
.B "extern unsigned" |
3104 |
mg_nunknown |
3105 |
.SH |
3106 |
DESCRIPTION |
3107 |
.LP |
3108 |
The parser dispatch table, |
3109 |
.I mg_ehand |
3110 |
is initially set to all NULL pointers, and it |
3111 |
is the duty of the calling program to assign entity handler functions to |
3112 |
each of the supported entity positions in the array. |
3113 |
The entities are given in the include file "parser.h" as the |
3114 |
following: |
3115 |
.DS |
3116 |
#define MG_E_COMMENT 0 /* # */ |
3117 |
#define MG_E_COLOR 1 /* c */ |
3118 |
#define MG_E_CCT 2 /* cct */ |
3119 |
#define MG_E_CONE 3 /* cone */ |
3120 |
#define MG_E_CMIX 4 /* cmix */ |
3121 |
#define MG_E_CSPEC 5 /* cspec */ |
3122 |
#define MG_E_CXY 6 /* cxy */ |
3123 |
#define MG_E_CYL 7 /* cyl */ |
3124 |
#define MG_E_ED 8 /* ed */ |
3125 |
#define MG_E_FACE 9 /* f */ |
3126 |
#define MG_E_INCLUDE 10 /* i */ |
3127 |
#define MG_E_IES 11 /* ies */ |
3128 |
#define MG_E_IR 12 /* ir */ |
3129 |
#define MG_E_MATERIAL 13 /* m */ |
3130 |
#define MG_E_NORMAL 14 /* n */ |
3131 |
#define MG_E_OBJECT 15 /* o */ |
3132 |
#define MG_E_POINT 16 /* p */ |
3133 |
#define MG_E_PRISM 17 /* prism */ |
3134 |
#define MG_E_RD 18 /* rd */ |
3135 |
#define MG_E_RING 19 /* ring */ |
3136 |
#define MG_E_RS 20 /* rs */ |
3137 |
#define MG_E_SIDES 21 /* sides */ |
3138 |
#define MG_E_SPH 22 /* sph */ |
3139 |
#define MG_E_TD 23 /* td */ |
3140 |
#define MG_E_TORUS 24 /* torus */ |
3141 |
#define MG_E_TS 25 /* ts */ |
3142 |
#define MG_E_VERTEX 26 /* v */ |
3143 |
#define MG_E_XF 27 /* xf */ |
3144 |
|
3145 |
#define MG_NENTITIES 28 /* total # entities */ |
3146 |
.DE |
3147 |
.LP |
3148 |
Once the |
3149 |
.I mg_ehand |
3150 |
array has been set by the program, the |
3151 |
.I mg_init |
3152 |
routine must be called to complete the initialization process. |
3153 |
This should be done once and only once per invocation, before any other |
3154 |
parser routines are called. |
3155 |
.LP |
3156 |
The |
3157 |
.I mg_uhand |
3158 |
variable points to the current handler for unknown entities |
3159 |
encountered on the input. |
3160 |
Its default value points to the |
3161 |
.I mg_defuhand |
3162 |
function, which simply increments the global variable |
3163 |
.I mg_nunknown, |
3164 |
printing a warning message on the standard error on the first |
3165 |
offense. |
3166 |
(This message may be avoided by incrementing |
3167 |
.I mg_nunknown |
3168 |
before processing begins.)\0 |
3169 |
If |
3170 |
.I mg_uhand |
3171 |
is assigned a value of NULL, then an unknown entity will return an |
3172 |
.I MG_EUNK |
3173 |
error, which will cause the parser to abort. |
3174 |
(See the |
3175 |
.I mg_load |
3176 |
page for a list of errors.)\0 |
3177 |
If the |
3178 |
.I mg_uhand |
3179 |
pointer is assigned to another function, that function will receive |
3180 |
any unknown entities and their arguments, and the parsing will |
3181 |
abort if the new function returns a non-zero error value. |
3182 |
This offers a convenient way to customize the language by adding |
3183 |
non-standard entities. |
3184 |
.SH |
3185 |
DIAGNOSTICS |
3186 |
.LP |
3187 |
If an inconsistent set of entities has been set for support, the |
3188 |
.I mg_init |
3189 |
routine will print an informative message to standard error and abort |
3190 |
the calling program with a call to |
3191 |
.I exit. |
3192 |
This is normally unacceptable behavior for a library routine, but since |
3193 |
such an error indicates a fault with the calling program itself, |
3194 |
recovery is impossible. |
3195 |
.SH |
3196 |
SEE ALSO |
3197 |
.LP |
3198 |
mg_load, mg_handle |
3199 |
.ds RH MG_LOAD |
3200 |
.bp |
3201 |
.SH |
3202 |
NAME |
3203 |
.LP |
3204 |
mg_load, mg_clear, mg_file, mg_err - load MGF file, clear data structures |
3205 |
.SH |
3206 |
SYNOPSIS |
3207 |
.LP |
3208 |
#include "parser.h" |
3209 |
.LP |
3210 |
.B int |
3211 |
mg_load( |
3212 |
.B char |
3213 |
*filename ) |
3214 |
.LP |
3215 |
.B void |
3216 |
mg_clear( |
3217 |
.B void |
3218 |
) |
3219 |
.LP |
3220 |
.B extern |
3221 |
MG_FCTXT *mg_file |
3222 |
.LP |
3223 |
.B "extern char" |
3224 |
*mg_err[MG_NERRS] |
3225 |
.SH |
3226 |
DESCRIPTION |
3227 |
.LP |
3228 |
The |
3229 |
.I mg_load |
3230 |
function loads the named file, or standard input if |
3231 |
.I filename |
3232 |
is the NULL pointer. |
3233 |
Calls back to the appropriate MGF handler routines are made through the |
3234 |
.I mg_ehand |
3235 |
dispatch table. |
3236 |
.LP |
3237 |
The global |
3238 |
.I mg_file |
3239 |
variable points to the current file context structure, which |
3240 |
may be useful for the interpretation of certain entities, such as |
3241 |
.UL ies, |
3242 |
which must know the directory path of the enclosing file. |
3243 |
This structure is of the defined type |
3244 |
.I MG_FCTXT, |
3245 |
given in "parser.h" as: |
3246 |
.DS |
3247 |
typedef struct mg_fctxt { |
3248 |
char fname[96]; /* file name */ |
3249 |
FILE *fp; /* stream pointer */ |
3250 |
int fid; /* unique file context id */ |
3251 |
char inpline[4096]; /* input line */ |
3252 |
int lineno; /* line number */ |
3253 |
struct mg_fctxt *prev; /* previous context */ |
3254 |
} MG_FCTXT; |
3255 |
.DE |
3256 |
.SH |
3257 |
DIAGNOSTICS |
3258 |
.LP |
3259 |
If an error is encountered during parsing, |
3260 |
.I mg_load |
3261 |
will print an appropriate error message to the standard error stream |
3262 |
and return one of the non-zero values from "parser.h" listed below: |
3263 |
.DS |
3264 |
#define MG_OK 0 /* normal return value */ |
3265 |
#define MG_EUNK 1 /* unknown entity */ |
3266 |
#define MG_EARGC 2 /* wrong number of arguments */ |
3267 |
#define MG_ETYPE 3 /* argument type error */ |
3268 |
#define MG_EILL 4 /* illegal argument value */ |
3269 |
#define MG_EUNDEF 5 /* undefined reference */ |
3270 |
#define MG_ENOFILE 6 /* cannot open input file */ |
3271 |
#define MG_EINCL 7 /* error in included file */ |
3272 |
#define MG_EMEM 8 /* out of memory */ |
3273 |
#define MG_ESEEK 9 /* file seek error */ |
3274 |
#define MG_EBADMAT 10 /* bad material specification */ |
3275 |
|
3276 |
#define MG_NERRS 11 |
3277 |
.DE |
3278 |
If it is inappropriate to send output to standard error, the calling |
3279 |
program should use the routines listed under |
3280 |
.I mg_open |
3281 |
for better control over the parsing process. |
3282 |
.LP |
3283 |
The |
3284 |
.I mg_err |
3285 |
array contains error messages corresponding to each of the values |
3286 |
listed above in the native country's language. |
3287 |
.SH |
3288 |
SEE ALSO |
3289 |
.LP |
3290 |
mg_fgetpos, mg_handle, mg_init, mg_open |
3291 |
.ds RH MG_OPEN |
3292 |
.bp |
3293 |
.SH |
3294 |
NAME |
3295 |
.LP |
3296 |
mg_open, mg_read, mg_parse, mg_close - MGF file loading subroutines |
3297 |
.SH |
3298 |
SYNOPSIS |
3299 |
.LP |
3300 |
#include "parser.h" |
3301 |
.LP |
3302 |
.B int |
3303 |
mg_open( MG_FCTXT *fcp, |
3304 |
.B char |
3305 |
*filename ) |
3306 |
.LP |
3307 |
.B int |
3308 |
mg_read( |
3309 |
.B void |
3310 |
) |
3311 |
.LP |
3312 |
.B int |
3313 |
mg_parse( |
3314 |
.B void |
3315 |
) |
3316 |
.LP |
3317 |
.B void |
3318 |
mg_close( |
3319 |
.B void |
3320 |
) |
3321 |
.SH |
3322 |
DESCRIPTION |
3323 |
.LP |
3324 |
Most loaders and translators will call the |
3325 |
.I mg_load |
3326 |
routine to handle the above operations, but some programs or |
3327 |
entity handlers require tighter control over the loading process. |
3328 |
.LP |
3329 |
The |
3330 |
.I mg_open |
3331 |
routine takes an uninitialized |
3332 |
.I MG_FCTXT |
3333 |
structure and a file name as its arguments. |
3334 |
If |
3335 |
.I filename |
3336 |
is the NULL pointer, the standard input is "opened." |
3337 |
The |
3338 |
.I fcp |
3339 |
structure will be set by |
3340 |
.I mg_open |
3341 |
prior to its return, and the global |
3342 |
.I mg_file |
3343 |
pointer will be assigned to point to it. |
3344 |
This variable must not be destroyed until after the file is closed |
3345 |
with a call to |
3346 |
.I mg_close. |
3347 |
(See the |
3348 |
.I mg_load |
3349 |
page for a definition of |
3350 |
.I mg_file |
3351 |
and the |
3352 |
.I MG_FCTXT |
3353 |
type.)\0 |
3354 |
.LP |
3355 |
The |
3356 |
.I mg_read |
3357 |
function reads the next input line from the current file, |
3358 |
returning the number of characters in the line, or zero if the |
3359 |
end of file is reached or there is a file error. |
3360 |
The function skips over escaped newlines, and keeps track of the |
3361 |
line number in the current file context |
3362 |
.I mg_file, |
3363 |
which also contains the line that was read. |
3364 |
.LP |
3365 |
The |
3366 |
.I mg_parse |
3367 |
function breaks the current line in the |
3368 |
.I mg_file |
3369 |
structure into words and calls the appropriate handler routine, if |
3370 |
any. |
3371 |
Blank lines and unsupported entities cause a quick return. |
3372 |
.LP |
3373 |
The |
3374 |
.I mg_close |
3375 |
routine closes the current input file (unless it is the standard |
3376 |
input) and returns to the previous file context (if any). |
3377 |
.SH |
3378 |
DIAGNOSTICS |
3379 |
.LP |
3380 |
The |
3381 |
.I mg_open |
3382 |
function returns |
3383 |
.I MG_OK |
3384 |
(0) normally, or |
3385 |
.I MG_ENOFILE |
3386 |
if the open fails for some reason. |
3387 |
.LP |
3388 |
The |
3389 |
.I mg_parse |
3390 |
function returns |
3391 |
.I MG_OK |
3392 |
if the current line was successfully interpreted, or one of the |
3393 |
defined error values if there is a problem. |
3394 |
(See the |
3395 |
.I mg_load |
3396 |
page for the defined error values.)\0 |
3397 |
.SH |
3398 |
SEE ALSO |
3399 |
.LP |
3400 |
mg_fgetpos, mg_handle, mg_init, mg_load |
3401 |
.ds RH MG_FGETPOS |
3402 |
.bp |
3403 |
.SH |
3404 |
NAME |
3405 |
.LP |
3406 |
mg_fgetpos, mg_fgoto - get current file position and seek to pointer |
3407 |
.SH |
3408 |
SYNOPSIS |
3409 |
.LP |
3410 |
#include "parser.h" |
3411 |
.LP |
3412 |
.B void |
3413 |
mg_fgetpos( MG_FPOS *pos ) |
3414 |
.LP |
3415 |
.B int |
3416 |
mg_fgoto( MG_FPOS *pos ) |
3417 |
.SH |
3418 |
DESCRIPTION |
3419 |
.LP |
3420 |
The |
3421 |
.I mg_fgetpos |
3422 |
gets the current MGF file position and loads it into the passed |
3423 |
.I MG_FPOS |
3424 |
structure, |
3425 |
.I pos. |
3426 |
.LP |
3427 |
The |
3428 |
.I mg_fgoto |
3429 |
function seeks to the position |
3430 |
.I pos, |
3431 |
taken from a previous call to |
3432 |
.I mg_fgetpos. |
3433 |
.SH |
3434 |
DIAGNOSTICS |
3435 |
.LP |
3436 |
If |
3437 |
.I mg_fgoto |
3438 |
is passed an illegal pointer or one that does not correspond to the |
3439 |
current |
3440 |
.I mg_file |
3441 |
context, it will return the |
3442 |
.I MG_ESEEK |
3443 |
error value. |
3444 |
Normally, it returns |
3445 |
.I MG_OK |
3446 |
(0). |
3447 |
.SH |
3448 |
SEE ALSO |
3449 |
.LP |
3450 |
mg_load, mg_open |
3451 |
.ds RH MG_HANDLE |
3452 |
.bp |
3453 |
.SH |
3454 |
NAME |
3455 |
.LP |
3456 |
mg_handle, mg_entity, mg_ename, mg_nqcdivs - entity assistance and control |
3457 |
.SH |
3458 |
SYNOPSIS |
3459 |
.LP |
3460 |
.B int |
3461 |
mg_handle( |
3462 |
.B int |
3463 |
en, |
3464 |
.B int |
3465 |
ac, |
3466 |
.B char |
3467 |
*av ) |
3468 |
.LP |
3469 |
.B int |
3470 |
mg_entity( |
3471 |
.B char |
3472 |
*name ) |
3473 |
.LP |
3474 |
.B "extern char" |
3475 |
mg_ename[MG_NENTITIES][MG_MAXELEN] |
3476 |
.LP |
3477 |
.B "extern int" |
3478 |
mg_nqcdivs |
3479 |
.SH |
3480 |
DESCRIPTION |
3481 |
.LP |
3482 |
The |
3483 |
.I mg_handle |
3484 |
routine may be used to pass entities back to the parser |
3485 |
to be redirected through the |
3486 |
.I mg_ehand |
3487 |
dispatch table. |
3488 |
This method is recommended rather than calling through |
3489 |
.I mg_ehand |
3490 |
directly, since the parser sometimes has its own support routines |
3491 |
that it needs to call for specific entities. |
3492 |
The first argument, |
3493 |
.I en, |
3494 |
is the corresponding entity number, or -1 if |
3495 |
.I mg_handle |
3496 |
should figure it out from the first |
3497 |
.I av |
3498 |
argument. |
3499 |
.LP |
3500 |
The |
3501 |
.I mg_entity |
3502 |
function gets an entity number from its name, using a hash |
3503 |
table on the |
3504 |
.I mg_ename |
3505 |
list. |
3506 |
.LP |
3507 |
The |
3508 |
.I mg_ename |
3509 |
table contains the string names corresponding to each MGF entity in |
3510 |
the designated order. |
3511 |
(See the |
3512 |
.I mg_init |
3513 |
page for the list of MGF entities.)\0 |
3514 |
.LP |
3515 |
The global integer variable |
3516 |
.I mg_nqcdivs |
3517 |
tells the parser how many subdivisions to use per quarter circle (90 |
3518 |
degrees) when tesselating curved geometry. |
3519 |
The default value is 5, and it may be reset at any time by the |
3520 |
calling program. |
3521 |
.SH |
3522 |
DIAGNOSTICS |
3523 |
.LP |
3524 |
The |
3525 |
.I mg_handle |
3526 |
function returns |
3527 |
.I MG_OK |
3528 |
if the entity is handled correctly, or one of the predefined error |
3529 |
values if there is a problem. |
3530 |
(See the |
3531 |
.I mg_load |
3532 |
page for a list of error values.)\0 |
3533 |
.LP |
3534 |
The |
3535 |
.I mg_entity |
3536 |
function returns -1 if the passed name does not appear in the |
3537 |
.I mg_ename |
3538 |
list. |
3539 |
.SH |
3540 |
SEE ALSO |
3541 |
.LP |
3542 |
mg_init, mg_load, mg_open |
3543 |
.ds RH ISINT, ISFLT, ISNAME |
3544 |
.bp |
3545 |
.SH |
3546 |
NAME |
3547 |
.LP |
3548 |
isint, isflt, isname - determine if string fits integer or real format, |
3549 |
or is legal identifier |
3550 |
.SH |
3551 |
SYNOPSIS |
3552 |
.LP |
3553 |
.B int |
3554 |
isint( |
3555 |
.B char |
3556 |
*str ) |
3557 |
.LP |
3558 |
.B int |
3559 |
isflt( |
3560 |
.B char |
3561 |
*str ) |
3562 |
.LP |
3563 |
.B int |
3564 |
isname( |
3565 |
.B char |
3566 |
*str ) |
3567 |
.SH |
3568 |
DESCRIPTION |
3569 |
.LP |
3570 |
The |
3571 |
.I isint |
3572 |
function checks to see if the passed string |
3573 |
.I str |
3574 |
matches a decimal integer format (positive or negative), |
3575 |
and returns 1 or 0 based on whether it does or does not. |
3576 |
.LP |
3577 |
The |
3578 |
.I isflt |
3579 |
function checks to see if the passed string |
3580 |
.I str |
3581 |
matches a floating point format (positive or negative with optional |
3582 |
exponent), and returns 1 or 0 based on whether it does or does not. |
3583 |
.LP |
3584 |
The |
3585 |
.I isname |
3586 |
function checks to see if the passed string |
3587 |
.I str |
3588 |
is a legal identifier name. |
3589 |
In MGF, a legal identifier must begin with a letter and contain only |
3590 |
visible ASCII characters (those between decimal 33 and 127 inclusive). |
3591 |
The one caveat to this is that names may begin with one or more |
3592 |
underscores ('_'), but this is a trick employed by the parser to |
3593 |
maintain a separate name space from the user, and is not legal usage |
3594 |
otherwise. |
3595 |
.LP |
3596 |
Note that a string that matches an integer format is also a valid |
3597 |
floating point value. |
3598 |
Conversely, a string that is not a floating point number cannot be a |
3599 |
valid integer. |
3600 |
.LP |
3601 |
These routines are useful for checking arguments passed to entity |
3602 |
handlers that certain types in certain positions. |
3603 |
If an invalid argument is passed, the handler should return an |
3604 |
.I MG_ETYPE |
3605 |
error. |
3606 |
.SH |
3607 |
SEE ALSO |
3608 |
.LP |
3609 |
mg_init, mg_load |
3610 |
.ds LH Entity Support Routines |
3611 |
.ds RH C_HVERTEX |
3612 |
.bp |
3613 |
.SH |
3614 |
NAME |
3615 |
.LP |
3616 |
c_hvertex, c_getvert, c_cvname, c_cvertex - vertex entity support |
3617 |
.SH |
3618 |
SYNOPSIS |
3619 |
.LP |
3620 |
#include "parser.h" |
3621 |
.LP |
3622 |
.B int |
3623 |
c_hvertex( |
3624 |
.B int |
3625 |
argc, |
3626 |
.B char |
3627 |
**argv ) |
3628 |
.LP |
3629 |
C_VERTEX *c_getvert( |
3630 |
.B char |
3631 |
*name ) |
3632 |
.LP |
3633 |
.B "extern char" |
3634 |
*c_vname |
3635 |
.LP |
3636 |
.B extern |
3637 |
C_VERTEX *c_cvertex |
3638 |
.SH |
3639 |
DESCRIPTION |
3640 |
.LP |
3641 |
The |
3642 |
.I c_hvertex |
3643 |
function handles the MGF vertex entities, |
3644 |
.UL v, |
3645 |
.UL p |
3646 |
and |
3647 |
.UL n. |
3648 |
If either |
3649 |
.UL p |
3650 |
or |
3651 |
.UL n |
3652 |
is supported, then |
3653 |
.UL v |
3654 |
must be also. |
3655 |
The assignments are normally made to the |
3656 |
.I mg_ehand |
3657 |
array prior to parser initialization, like so: |
3658 |
.DS |
3659 |
mg_ehand[MG_E_VERTEX] = c_hvertex; /* support "v" entity */ |
3660 |
mg_ehand[MG_E_POINT] = c_hvertex; /* support "p" entity */ |
3661 |
mg_ehand[MG_E_NORMAL] = c_hvertex; /* support "n" entity */ |
3662 |
/* other entity handler assignments... */ |
3663 |
mg_init(); /* initialize parser */ |
3664 |
.DE |
3665 |
If vertex normals are not understood by any of the program-supported |
3666 |
entities, then the |
3667 |
.I MG_E_NORMAL |
3668 |
entry may be left with its original NULL assignment. |
3669 |
.LP |
3670 |
The |
3671 |
.I c_getvert |
3672 |
call takes the name of a defined vertex and returns a pointer to its |
3673 |
.I C_VERTEX |
3674 |
structure, defined in "parser.h" as: |
3675 |
.DS |
3676 |
typedef FLOAT FVECT[3]; /* a 3-d real vector */ |
3677 |
|
3678 |
typedef struct { |
3679 |
int clock; /* incremented each change -- resettable */ |
3680 |
FVECT p, n; /* point and normal */ |
3681 |
} C_VERTEX; /* vertex context */ |
3682 |
.DE |
3683 |
The |
3684 |
.I clock |
3685 |
member will be incremented each time the value gets changed by a |
3686 |
.UL p |
3687 |
or |
3688 |
.UL n |
3689 |
entity, and may be reset by the controlling program if desired. |
3690 |
This is a convenient way to keep track of whether or not a vertex has |
3691 |
changed since its last use. |
3692 |
To link identical vertices, one must also check that the current |
3693 |
transform has not changed, which is uniquely identified by the |
3694 |
global |
3695 |
.I xf_context->xid |
3696 |
variable, but only if one is using the parser libraries transform |
3697 |
handler. |
3698 |
(See the |
3699 |
.I xf_handler |
3700 |
page.)\0 |
3701 |
.LP |
3702 |
It is possible but not recommended to alter the contents of the |
3703 |
vertex structure returned by |
3704 |
.I c_getvert. |
3705 |
Normally it is read during the |
3706 |
interpretation of entities using named vertices. |
3707 |
.LP |
3708 |
The name of the current vertex is given by the global |
3709 |
.I c_cvname |
3710 |
variable, which is set to NULL if the unnamed vertex is current. |
3711 |
The current vertex value is pointed to by the global variable |
3712 |
.I c_cvertex, |
3713 |
which should never be NULL. |
3714 |
.SH |
3715 |
DIAGNOSTICS |
3716 |
.LP |
3717 |
The |
3718 |
.I c_hvertex |
3719 |
function returns |
3720 |
.I MG_OK |
3721 |
(0) if the vertex is handled correctly, or one of the predefined |
3722 |
error values if there is a problem. |
3723 |
(See the |
3724 |
.I mg_load |
3725 |
page for a list of errors.)\0 |
3726 |
.LP |
3727 |
The |
3728 |
.I c_getvert |
3729 |
function returns NULL if the specified vertex name is undefined, at |
3730 |
which point the calling function should return an |
3731 |
.I MG_EUNDEF |
3732 |
error. |
3733 |
.SH |
3734 |
SEE ALSO |
3735 |
.LP |
3736 |
c_hcolor, c_hmaterial, mg_init, mg_load, xf_handler |
3737 |
.ds RH C_HCOLOR |
3738 |
.bp |
3739 |
.SH |
3740 |
NAME |
3741 |
.LP |
3742 |
c_hcolor, c_getcolor, c_ccname, c_ccolor, c_ccvt, c_isgrey - |
3743 |
color entity support |
3744 |
.SH |
3745 |
SYNOPSIS |
3746 |
.LP |
3747 |
#include "parser.h" |
3748 |
.LP |
3749 |
.B int |
3750 |
c_hcolor( |
3751 |
.B int |
3752 |
argc, |
3753 |
.B char |
3754 |
**argv ) |
3755 |
.LP |
3756 |
C_COLOR *c_getcolor( |
3757 |
.B char |
3758 |
*name ) |
3759 |
.LP |
3760 |
.B "extern char" |
3761 |
*c_ccname |
3762 |
.LP |
3763 |
.B extern |
3764 |
C_COLOR *c_ccolor |
3765 |
.LP |
3766 |
.B void |
3767 |
c_ccvt( C_COLOR *cvp, |
3768 |
.B int |
3769 |
cflags ) |
3770 |
.LP |
3771 |
.B int |
3772 |
c_isgrey( C_COLOR *cvp ) |
3773 |
.SH |
3774 |
DESCRIPTION |
3775 |
.LP |
3776 |
The |
3777 |
.I c_hcolor |
3778 |
function supports the MGF entities, |
3779 |
.UL c, |
3780 |
.UL cxy, |
3781 |
.UL cspec, |
3782 |
.UL cct |
3783 |
and |
3784 |
.UL cmix. |
3785 |
It is an error to support any of the color field entities without |
3786 |
supporting the |
3787 |
.UL c |
3788 |
entity itself. |
3789 |
The assignments are normally made to the |
3790 |
.I mg_ehand |
3791 |
array prior to parser initialization, like so: |
3792 |
.DS |
3793 |
mg_ehand[MG_E_COLOR] = c_hcolor; /* support "c" entity */ |
3794 |
mg_ehand[MG_E_CXY] = c_hcolor; /* support "cxy" entity */ |
3795 |
mg_ehand[MG_E_CSPEC] = c_hcolor; /* support "cspec" entity */ |
3796 |
mg_ehand[MG_E_CCT] = c_hcolor; /* support "cct" entity */ |
3797 |
mg_ehand[MG_E_CMIX] = c_hcolor; /* support "cmix" entity */ |
3798 |
/* other entity handler assignments... */ |
3799 |
mg_init(); /* initialize parser */ |
3800 |
.DE |
3801 |
If the loader/translator has no use for spectral data, the entries for |
3802 |
.UL cspec |
3803 |
and |
3804 |
.UL cct |
3805 |
may be left with their original NULL assignments and these entities will |
3806 |
be re-expressed appropriately as tristimulus values. |
3807 |
.LP |
3808 |
The |
3809 |
.I c_getcolor |
3810 |
function takes the name of a defined color and returns a pointer to its |
3811 |
.I C_COLOR |
3812 |
structure, defined in "parser.h" as: |
3813 |
.DS |
3814 |
#define C_CMINWL 380 /* minimum wavelength */ |
3815 |
#define C_CMAXWL 780 /* maximum wavelength */ |
3816 |
#define C_CNSS 41 /* number of spectral samples */ |
3817 |
#define C_CWLI ((C_CMAXWL-C_CMINWL)/(C_CNSS-1)) |
3818 |
#define C_CMAXV 10000 /* nominal maximum sample value */ |
3819 |
#define C_CLPWM (683./C_CMAXV) /* peak lumens/watt multiplier */ |
3820 |
|
3821 |
typedef struct { |
3822 |
int clock; /* incremented each change */ |
3823 |
short flags; /* what's been set */ |
3824 |
short ssamp[C_CNSS]; /* spectral samples, min wl to max */ |
3825 |
long ssum; /* straight sum of spectral values */ |
3826 |
float cx, cy; /* xy chromaticity value */ |
3827 |
float eff; /* efficacy (lumens/watt) */ |
3828 |
} C_COLOR; /* color context */ |
3829 |
.DE |
3830 |
The |
3831 |
.I clock |
3832 |
member will be incremented each time the value gets changed by a |
3833 |
color field entity, and may be reset by the calling program if |
3834 |
desired. |
3835 |
This is a convenient way to keep track of whether or not a color has |
3836 |
changed since its last use. |
3837 |
The |
3838 |
.I flags |
3839 |
member indicates which color representations have been assigned, |
3840 |
and is an inclusive OR of one or more of the following: |
3841 |
.DS |
3842 |
#define C_CSSPEC 01 /* flag if spectrum is set */ |
3843 |
#define C_CDSPEC 02 /* flag if defined w/ spectrum */ |
3844 |
#define C_CSXY 04 /* flag if xy is set */ |
3845 |
#define C_CDXY 010 /* flag if defined w/ xy */ |
3846 |
#define C_CSEFF 020 /* flag if efficacy set */ |
3847 |
.DE |
3848 |
.LP |
3849 |
It is possible but not recommended to alter the contents of the |
3850 |
color structure returned by |
3851 |
.I c_getcolor. |
3852 |
Normally, this routine is never called directly, since there are no |
3853 |
entities that access colors by name other than |
3854 |
.UL c. |
3855 |
.LP |
3856 |
The global variable |
3857 |
.I c_ccname |
3858 |
points to the name of the current color, or NULL if it is unnamed. |
3859 |
The variable |
3860 |
.I c_ccolor |
3861 |
points to the current color value, which should never be NULL. |
3862 |
.LP |
3863 |
The |
3864 |
.I c_ccvt |
3865 |
routine takes a |
3866 |
.I C_COLOR |
3867 |
structure and a set of desired flag settings and computes the |
3868 |
missing color representation(s). |
3869 |
.LP |
3870 |
The |
3871 |
.I c_isgrey |
3872 |
function returns 1 if the passed color is very close to neutral |
3873 |
grey, or 0 otherwise. |
3874 |
.SH |
3875 |
DIAGNOSTICS |
3876 |
.LP |
3877 |
The |
3878 |
.I c_hcolor |
3879 |
function returns |
3880 |
.I MG_OK |
3881 |
(0) if the color is handled correctly, or one of the predefined |
3882 |
error values if there is a problem. |
3883 |
(See the |
3884 |
.I mg_load |
3885 |
page for a list of errors.)\0 |
3886 |
.LP |
3887 |
The |
3888 |
.I c_getcolor |
3889 |
function returns NULL if the specified color name is undefined, at |
3890 |
which point the calling function should return an |
3891 |
.I MG_EUNDEF |
3892 |
error. |
3893 |
.SH |
3894 |
SEE ALSO |
3895 |
.LP |
3896 |
c_hmaterial, c_hvertex, mg_init, mg_load |
3897 |
.ds RH C_HMATERIAL |
3898 |
.bp |
3899 |
.SH |
3900 |
NAME |
3901 |
.LP |
3902 |
c_hmaterial, c_getmaterial, c_cmname, c_cmaterial - |
3903 |
material entity support |
3904 |
.SH |
3905 |
SYNOPSIS |
3906 |
.LP |
3907 |
#include "parser.h" |
3908 |
.LP |
3909 |
.B int |
3910 |
c_hmaterial( |
3911 |
.B int |
3912 |
argc, |
3913 |
.B char |
3914 |
**argv ) |
3915 |
.LP |
3916 |
C_MATERIAL *c_getmaterial( |
3917 |
.B char |
3918 |
*name ) |
3919 |
.LP |
3920 |
.B "extern char" |
3921 |
*c_cmname |
3922 |
.LP |
3923 |
.B extern |
3924 |
C_MATERIAL *c_cmaterial |
3925 |
.SH |
3926 |
DESCRIPTION |
3927 |
.LP |
3928 |
The |
3929 |
.I c_hmaterial |
3930 |
function supports the MGF entities, |
3931 |
.UL m, |
3932 |
.UL ed, |
3933 |
.UL ir, |
3934 |
.UL rd, |
3935 |
.UL rs, |
3936 |
.UL sides, |
3937 |
.UL td, |
3938 |
and |
3939 |
.UL ts. |
3940 |
It is an error to support any of the material field entities without |
3941 |
supporting the |
3942 |
.UL m |
3943 |
entity itself. |
3944 |
The assignments are normally made to the |
3945 |
.I mg_ehand |
3946 |
array prior to parser initialization, like so: |
3947 |
.DS |
3948 |
mg_ehand[MG_E_MATERIAL] = c_hmaterial; /* support "m" entity */ |
3949 |
mg_ehand[MG_E_ED] = c_hmaterial; /* support "ed" entity */ |
3950 |
mg_ehand[MG_E_IR] = c_hmaterial; /* support "ir" entity */ |
3951 |
mg_ehand[MG_E_RD] = c_hmaterial; /* support "rd" entity */ |
3952 |
mg_ehand[MG_E_RS] = c_hmaterial; /* support "rs" entity */ |
3953 |
mg_ehand[MG_E_SIDES] = c_hmaterial; /* support "sides" entity */ |
3954 |
mg_ehand[MG_E_TD] = c_hmaterial; /* support "td" entity */ |
3955 |
mg_ehand[MG_E_TS] = c_hmaterial; /* support "ts" entity */ |
3956 |
/* other entity handler assignments... */ |
3957 |
mg_init(); /* initialize parser */ |
3958 |
.DE |
3959 |
Any of the above entities besides |
3960 |
.UL m |
3961 |
may be unsupported, but the parser will not attempt to include their |
3962 |
effect into other members, e.g. an unsupported |
3963 |
.UL rs |
3964 |
component will not be added back into the |
3965 |
.UL rd |
3966 |
member. |
3967 |
It is therefore safer to support all of the relevant material |
3968 |
entities and make final approximations from the complete |
3969 |
.I C_MATERIAL |
3970 |
structure. |
3971 |
.LP |
3972 |
The |
3973 |
.I c_getmaterial |
3974 |
function takes the name of a defined material and returns a pointer to its |
3975 |
.I C_MATERIAL |
3976 |
structure, defined in "parser.h" as: |
3977 |
.DS |
3978 |
#define C_1SIDEDTHICK 0.005 /* assumed thickness of 1-sided mat. */ |
3979 |
|
3980 |
typedef struct { |
3981 |
int clock; /* incremented each change -- resettable */ |
3982 |
int sided; /* 1 if surface is 1-sided, 0 for 2-sided */ |
3983 |
float nr, ni; /* index of refraction, real and imaginary */ |
3984 |
float rd; /* diffuse reflectance */ |
3985 |
C_COLOR rd_c; /* diffuse reflectance color */ |
3986 |
float td; /* diffuse transmittance */ |
3987 |
C_COLOR td_c; /* diffuse transmittance color */ |
3988 |
float ed; /* diffuse emittance */ |
3989 |
C_COLOR ed_c; /* diffuse emittance color */ |
3990 |
float rs; /* specular reflectance */ |
3991 |
C_COLOR rs_c; /* specular reflectance color */ |
3992 |
float rs_a; /* specular reflectance roughness */ |
3993 |
float ts; /* specular transmittance */ |
3994 |
C_COLOR ts_c; /* specular transmittance color */ |
3995 |
float ts_a; /* specular transmittance roughness */ |
3996 |
} C_MATERIAL; /* material context */ |
3997 |
.DE |
3998 |
The |
3999 |
.I clock |
4000 |
member will be incremented each time the value gets changed by a |
4001 |
material field entity, and may be reset by the calling program if |
4002 |
desired. |
4003 |
This is a convenient way to keep track of whether or not a material has |
4004 |
changed since its last use. |
4005 |
.LP |
4006 |
All reflectance and transmittance values correspond to normal |
4007 |
incidence, and may vary as a function of angle depending on the |
4008 |
index of refraction. |
4009 |
A solid object is normally represented with a one-sided material. |
4010 |
A two-sided material is most appropriate for thin surfaces, though |
4011 |
it may be used also when the surface normal orientations in a model |
4012 |
are unreliable. |
4013 |
.LP |
4014 |
If a transparent or translucent surface is one-sided, then the |
4015 |
absorption will change as a function of distance through the |
4016 |
material, and a single value for diffuse or specular transmittance is |
4017 |
ambiguous. |
4018 |
We therefore define a standard thickness, |
4019 |
.I C_1SIDEDTHICK, |
4020 |
which is the object thickness to which the given values correspond, |
4021 |
so that one may compute the isotropic absorptance of the material. |
4022 |
.LP |
4023 |
It is possible but not recommended to alter the contents of the |
4024 |
material structure returned by |
4025 |
.I c_getmaterial. |
4026 |
Normally, this routine is never called directly, since there are no |
4027 |
entities that access materials by name other than |
4028 |
.UL m. |
4029 |
.LP |
4030 |
The global variable |
4031 |
.I c_cmname |
4032 |
points to the name of the current material, or NULL if it is unnamed. |
4033 |
The variable |
4034 |
.I c_cmaterial |
4035 |
points to the current material value, which should never be NULL. |
4036 |
.SH |
4037 |
DIAGNOSTICS |
4038 |
.LP |
4039 |
The |
4040 |
.I c_hmaterial |
4041 |
function returns |
4042 |
.I MG_OK |
4043 |
(0) if the color is handled correctly, or one of the predefined |
4044 |
error values if there is a problem. |
4045 |
(See the |
4046 |
.I mg_load |
4047 |
page for a list of errors.)\0 |
4048 |
.LP |
4049 |
The |
4050 |
.I c_getmaterial |
4051 |
function returns NULL if the specified material name is undefined, at |
4052 |
which point the calling function should return an |
4053 |
.I MG_EUNDEF |
4054 |
error. |
4055 |
.SH |
4056 |
SEE ALSO |
4057 |
.LP |
4058 |
c_hcolor, c_hvertex, mg_init, mg_load |
4059 |
.ds RH OBJ_HANDLER |
4060 |
.bp |
4061 |
.SH |
4062 |
NAME |
4063 |
.LP |
4064 |
obj_handler, obj_clear, obj_nnames, obj_name - object name support |
4065 |
.SH |
4066 |
SYNOPSIS |
4067 |
.LP |
4068 |
.B int |
4069 |
obj_handler( |
4070 |
.B int |
4071 |
argc, |
4072 |
.B char |
4073 |
**argv ) |
4074 |
.LP |
4075 |
.B void |
4076 |
obj_clear( |
4077 |
.B void |
4078 |
) |
4079 |
.LP |
4080 |
.B "extern int" |
4081 |
obj_nnames |
4082 |
.LP |
4083 |
.B "extern char" |
4084 |
**obj_name |
4085 |
.SH |
4086 |
DESCRIPTION |
4087 |
.LP |
4088 |
The |
4089 |
.I obj_handler |
4090 |
routine should be assigned to the |
4091 |
.I MG_E_OBJECT |
4092 |
entry of the parser's |
4093 |
.I mg_ehand |
4094 |
array prior to calling |
4095 |
.I mg_load |
4096 |
if the loader/translator wishes to support hierarchical object |
4097 |
names. |
4098 |
.LP |
4099 |
The |
4100 |
.I obj_clear |
4101 |
function may be used to clear the object name stack and free any |
4102 |
associated memory, but this is usually not necessary since |
4103 |
.UL o |
4104 |
begin and end entities are normally balanced in the input. |
4105 |
.LP |
4106 |
The global |
4107 |
.I obj_nnames |
4108 |
variable indicates the number of names currently in the object |
4109 |
stack, and the |
4110 |
.I obj_name |
4111 |
list contains the name strings in the same order as they were |
4112 |
encountered on the input. |
4113 |
(I.e. the most recently pushed name is last.)\0 |
4114 |
.SH |
4115 |
DIAGNOSTICS |
4116 |
.LP |
4117 |
The |
4118 |
.I obj_handler |
4119 |
function returns |
4120 |
.I MG_OK |
4121 |
(0) if the color is handled correctly, or one of the predefined |
4122 |
error values if there is a problem. |
4123 |
(See the |
4124 |
.I mg_load |
4125 |
page for a list of errors.)\0 |
4126 |
.SH |
4127 |
SEE ALSO |
4128 |
.LP |
4129 |
mg_init, mg_load, xf_handler |
4130 |
.ds RH XF_HANDLER |
4131 |
.bp |
4132 |
.SH |
4133 |
NAME |
4134 |
.LP |
4135 |
xf_handler, xf_clear, xf_context, xf_argend - transformation support |
4136 |
.SH |
4137 |
SYNOPSIS |
4138 |
.LP |
4139 |
.B int |
4140 |
xf_handler( |
4141 |
.B int |
4142 |
argc, |
4143 |
.B char |
4144 |
**argv ) |
4145 |
.LP |
4146 |
.B void |
4147 |
xf_clear( |
4148 |
.B void |
4149 |
) |
4150 |
.LP |
4151 |
.B extern |
4152 |
XF_SPEC *xf_context |
4153 |
.LP |
4154 |
.B "extern char" |
4155 |
**xf_argend |
4156 |
.SH |
4157 |
DESCRIPTION |
4158 |
.LP |
4159 |
The |
4160 |
.I xf_handler |
4161 |
routine should be assigned to the |
4162 |
.I MG_E_XF |
4163 |
entry of the parser's |
4164 |
.I mg_ehand |
4165 |
array prior to calling |
4166 |
.I mg_load |
4167 |
if the loader/translator wishes to support hierarchical |
4168 |
transformations. |
4169 |
(Note that all MGF geometric entities require this support.)\0 |
4170 |
.LP |
4171 |
The |
4172 |
.I xf_clear |
4173 |
function may be used to clear the transform stack and free any |
4174 |
associated memory, but this is usually not necessary since |
4175 |
.UL xf |
4176 |
begin and end entities are normally balanced in the input. |
4177 |
.LP |
4178 |
The global |
4179 |
.I xf_context |
4180 |
variable points to the current transformation context, which is of |
4181 |
the type |
4182 |
.I XF_SPEC, |
4183 |
described in "parser.h": |
4184 |
.DS |
4185 |
typedef struct xf_spec { |
4186 |
long xid; /* unique transform id */ |
4187 |
short xac; /* context argument count */ |
4188 |
short rev; /* boolean true if vertices reversed */ |
4189 |
XF xf; /* cumulative transformation */ |
4190 |
struct xf_array *xarr; /* transformation array pointer */ |
4191 |
struct xf_spec *prev; /* previous transformation context */ |
4192 |
} XF_SPEC; /* followed by argument buffer */ |
4193 |
.DE |
4194 |
The |
4195 |
.I xid |
4196 |
member is a identifier associated with this transformation, |
4197 |
which should be the same for identical transformations, as an aid to |
4198 |
vertex sharing. |
4199 |
(See also the |
4200 |
.I c_hvertex |
4201 |
page.)\0 |
4202 |
The |
4203 |
.I xac |
4204 |
member indicates the total number of transform arguments, and is |
4205 |
used to indicate the position of the first argument relative to the |
4206 |
last one pointed to by the global |
4207 |
.I xf_argend |
4208 |
variable. |
4209 |
.LP |
4210 |
The first transform argument starts at |
4211 |
.I xf_argv, |
4212 |
which is a macro defined in "parser.h" as: |
4213 |
.DS |
4214 |
#define xf_argv (xf_argend - xf_context->xac) |
4215 |
.DE |
4216 |
Note that accessing this macro will result in a segmentation violation |
4217 |
if the current context is NULL, so one should first test the second macro |
4218 |
.I xf_argc |
4219 |
against zero. |
4220 |
This macro is defined as: |
4221 |
.DS |
4222 |
#define xf_argc (xf_context==NULL ? 0 : xf_context->xac) |
4223 |
.DE |
4224 |
.LP |
4225 |
Normally, neither of these macros will be used, since there are |
4226 |
routines for transforming points, vectors and scalars directly based |
4227 |
on the current transformation context. |
4228 |
(See the |
4229 |
.I xf_xfmpoint |
4230 |
page for details.)\0 |
4231 |
.LP |
4232 |
The |
4233 |
.I rev |
4234 |
member of the |
4235 |
.I XF_SPEC |
4236 |
structure indicates whether or not this transform reverses the order |
4237 |
of polygon vertices. |
4238 |
This member will be 1 if the transformation mirrors about an odd |
4239 |
number of coordinate axes, thus inverting faces. |
4240 |
The usual thing to do in this circumstance is to interpret the |
4241 |
vertex arguments in the reverse order, so as to bring the face back |
4242 |
to its original orientation in the new position. |
4243 |
.LP |
4244 |
The |
4245 |
.I xf |
4246 |
member contains the transformation scalefactor (in xf.sca) |
4247 |
and 4x4 homogeneous matrix (in xf.xfm), but these will usually not |
4248 |
be accessed directly. |
4249 |
Likewise, the |
4250 |
.I xarr |
4251 |
and |
4252 |
.I prev |
4253 |
members point to data that should not be needed by the calling |
4254 |
program. |
4255 |
.SH |
4256 |
DIAGNOSTICS |
4257 |
.LP |
4258 |
The |
4259 |
.I xf_handler |
4260 |
function returns |
4261 |
.I MG_OK |
4262 |
(0) if the color is handled correctly, or one of the predefined |
4263 |
error values if there is a problem. |
4264 |
(See the |
4265 |
.I mg_load |
4266 |
page for a list of errors.)\0 |
4267 |
.SH |
4268 |
SEE ALSO |
4269 |
.LP |
4270 |
mg_init, mg_load, obj_handler, xf_xfmpoint |
4271 |
.ds RH XF_XFMPOINT |
4272 |
.bp |
4273 |
.SH |
4274 |
NAME |
4275 |
.LP |
4276 |
xf_xfmpoint, xf_xfmvect, xf_rotvect, xf_scale - apply current |
4277 |
transformation |
4278 |
.SH |
4279 |
SYNOPSIS |
4280 |
.LP |
4281 |
.B void |
4282 |
xf_xfmpoint( FVECT pnew, FVECT pold ) |
4283 |
.LP |
4284 |
.B void |
4285 |
xf_xfmvect( FVECT vnew, FVECT vold ) |
4286 |
.LP |
4287 |
.B void |
4288 |
xf_rotvect( FVECT nnew, FVECT nold ) |
4289 |
.LP |
4290 |
.B double |
4291 |
xf_scale( |
4292 |
.B double |
4293 |
sold ) |
4294 |
.SH |
4295 |
DESCRIPTION |
4296 |
.LP |
4297 |
The |
4298 |
.I xf_xfmpoint |
4299 |
routine applies the current transformation defined by |
4300 |
.I xf_context |
4301 |
to the point |
4302 |
.I pold, |
4303 |
scaling, rotating and moving it to its proper location, which is put in |
4304 |
.I pnew. |
4305 |
(As for |
4306 |
.I xf_xfmvect |
4307 |
and |
4308 |
.I xf_rotvect, |
4309 |
the two arguments may point to the same vector.)\0 |
4310 |
.LP |
4311 |
The |
4312 |
.I xf_xfmvect |
4313 |
routine applies the current transformation to the vector |
4314 |
.I vold, |
4315 |
scaling and rotating it to its proper location, which is put in |
4316 |
.I vnew. |
4317 |
The only difference between |
4318 |
.I xf_xfmpoint |
4319 |
and |
4320 |
.I xf_xfmvect |
4321 |
is that in the latter, the final translation is not applied. |
4322 |
.LP |
4323 |
The |
4324 |
.I xf_rotvect |
4325 |
routine rotates the vector |
4326 |
.I nold |
4327 |
using the current transformation, and stores the result in |
4328 |
.I nnew. |
4329 |
No translation or scaling is applied, which is the appropriate |
4330 |
action for surface normal vectors for example. |
4331 |
.LP |
4332 |
The |
4333 |
.I xf_scale |
4334 |
function takes a scalar argument |
4335 |
.I sold |
4336 |
and applies the current scale factor, returning the result. |
4337 |
.SH |
4338 |
SEE ALSO |
4339 |
.LP |
4340 |
xf_handler |
4341 |
.ds LH |
4342 |
.ds RH |
4343 |
.bp |
4344 |
.NH |
4345 |
Application Notes |
4346 |
.NH 2 |
4347 |
Relation to Standard Practices in Computer Graphics |
4348 |
.LP |
4349 |
For those coming from a computer graphics background, some of the |
4350 |
choices in the material model may seem strange or even capricious. |
4351 |
Why not simply stick with RGB colors and a Phong specular component |
4352 |
like everyone else? |
4353 |
What is the point in choosing the number of sides to a material? |
4354 |
.LP |
4355 |
In the real world, a surface can have only one side, |
4356 |
defining the interface between one volume and another. |
4357 |
Many object-space rendering packages (e.g. z-buffer algorithms) take |
4358 |
advantage of this fact by culling back-facing polygons and thus saving |
4359 |
as much as 50% of the preprocessing time. |
4360 |
However, many models rely on an |
4361 |
approximation whereby a single surface is used to represent a very thin |
4362 |
volume, such as a pane of glass, and this also can provide significant |
4363 |
calculational savings in an image-space algorithm (such as |
4364 |
ray-tracing). |
4365 |
Also, many models are created in such a way that the front vs. back |
4366 |
information is lost or confused, so that the back side of one or |
4367 |
more surfaces may have to serve as the front side during rendering. |
4368 |
(AutoCAD is one easily identified culprit in this department.)\0 |
4369 |
Since both types of surface models are useful and any |
4370 |
rendering algorithm may ultimately be applied, MGF provides a way |
4371 |
to specify sidedness rather than picking one interpretation or the other. |
4372 |
.LP |
4373 |
The problem with RGB is that there is no accepted standard, and even |
4374 |
if we were to set one it would either be impossible to realize (i.e. |
4375 |
impossible to create phosphors with the chosen colors) or it would |
4376 |
have a gamut that excludes many saturated colors. |
4377 |
The CIE color system was very carefully conceived and developed, |
4378 |
and is the standard to which all photometric measurements adhere. |
4379 |
It is therefore the logical choice in any standard format, though it |
4380 |
has been too often ignored by the computer graphics community. |
4381 |
.LP |
4382 |
Regarding Phong shading, this was never a physical model and making it |
4383 |
behave basic laws of reciprocity and energy balance is difficult. |
4384 |
More to the point, specular power has almost nothing to do with |
4385 |
surface microstructure, and is difficult to set properly |
4386 |
even if every physical characteristic of a material has |
4387 |
been carefully measured. |
4388 |
This is the ultimate indictment of any physical model -- that it |
4389 |
is incapable of reproducing any measurement whatsoever. |
4390 |
.LP |
4391 |
Admittedly, the compliment of diffuse and specular component plus |
4392 |
surface roughness and index of refraction used in MGF is less than a |
4393 |
perfect model, but it is serviceable for most materials and |
4394 |
relatively simple to incorporate into a rendering algorithm. |
4395 |
In the long term, MGF shall probably include full spectral |
4396 |
scattering functions, though the sheer quantity of data involved |
4397 |
makes this burdensome from both the measurement side and the |
4398 |
simulation side. |
4399 |
.NH 3 |
4400 |
Converting between Phong Specular Power and Gaussian Roughness |
4401 |
.LP |
4402 |
So-called specular reflection and transmission are modeled using a |
4403 |
Gaussian distribution of surface facets. |
4404 |
The roughness parameters to the |
4405 |
.UL rs |
4406 |
and |
4407 |
.UL ts |
4408 |
entities specify |
4409 |
the root-mean-squared (RMS) surface facet slope, which varies from 0 |
4410 |
for a perfectly smooth surface to around .2 for a fairly rough one. |
4411 |
The effect this will have on the reflected component distribution is |
4412 |
well-defined, but predicting the behavior of the transmitted |
4413 |
component requires further assumptions. |
4414 |
We assume that the surface |
4415 |
scatters light passing through it just as much as it scatters |
4416 |
reflected light. |
4417 |
This assumption is approximately correct for a |
4418 |
two-sided transparent material with an index of refraction of 1.5 |
4419 |
(like glass) and both sides having the given RMS facet slope. |
4420 |
.LP |
4421 |
Oftentimes, one is translating from a Phong exponent on the cosine |
4422 |
of the half-vector-to-normal angle to the more physical but less |
4423 |
familiar Gaussian model of MGF. |
4424 |
The hardest part is translating the specular power to a roughness value. |
4425 |
For this, we recommend the following approximation: |
4426 |
.IP |
4427 |
roughness = 0.6/sqrt(specular_power) |
4428 |
.LP |
4429 |
It is not a perfect correlation, but it is about as close as one can get. |
4430 |
.NH 3 |
4431 |
Converting between RGB and CIE Colors |
4432 |
.LP |
4433 |
Unlike most graphics languages, MGF does not use an RGB color model, |
4434 |
simply because there is no recognized definition for this model. |
4435 |
It is based on computer monitor phosphors, which vary from one |
4436 |
CRT to the next. |
4437 |
(There is an RGB standard defined in the TV |
4438 |
industry, but this has a rather poor correlation to most computer |
4439 |
monitors and it is impossible to express many real-world colors |
4440 |
within its limited gamut.)\0 |
4441 |
.LP |
4442 |
MGF uses two alternative, well-defined standards, spectral power |
4443 |
distributions and the 1931 CIE 2 degree standard observer. |
4444 |
With the CIE standard, any viewable |
4445 |
color may be exactly represented as an (x,y) chromaticity value. |
4446 |
Unfortunately, the interaction between |
4447 |
colors (i.e. colored light sources and interreflections) cannot be |
4448 |
specified exactly with any finite coordinate set, including CIE |
4449 |
chromaticities. |
4450 |
So, MGF offers the ability to give reflectance, |
4451 |
transmittance or emittance as a function of wavelength over the visible |
4452 |
spectrum. |
4453 |
This function is still discretized, but at a user-selectable |
4454 |
resolution. |
4455 |
Furthermore, spectral colors may be mixed, providing (nearly) |
4456 |
arbitrary basis functions, which can produce more accurate results in |
4457 |
some cases and are merely a convenience for translation in others. |
4458 |
.LP |
4459 |
Conversion back and forth between CIE chromaticity coordinates and spectral |
4460 |
samples is provided within the MGF parser. |
4461 |
Unfortunately, conversion |
4462 |
to and from RGB values depends on a particular RGB definition, and as we |
4463 |
have said, there is no recognized standard. |
4464 |
We therefore recommend that |
4465 |
you decide yourself what chromaticity values to use for each RGB primary, |
4466 |
and adopt the following code to convert between CIE and RGB coordinates. |
4467 |
.LP |
4468 |
.nf |
4469 |
#ifdef NTSC |
4470 |
#define CIE_x_r 0.670 /* standard NTSC primaries */ |
4471 |
#define CIE_y_r 0.330 |
4472 |
#define CIE_x_g 0.210 |
4473 |
#define CIE_y_g 0.710 |
4474 |
#define CIE_x_b 0.140 |
4475 |
#define CIE_y_b 0.080 |
4476 |
#define CIE_x_w 0.3333 /* monitor white point */ |
4477 |
#define CIE_y_w 0.3333 |
4478 |
#else |
4479 |
#define CIE_x_r 0.640 /* nominal CRT primaries */ |
4480 |
#define CIE_y_r 0.330 |
4481 |
#define CIE_x_g 0.290 |
4482 |
#define CIE_y_g 0.600 |
4483 |
#define CIE_x_b 0.150 |
4484 |
#define CIE_y_b 0.060 |
4485 |
#define CIE_x_w 0.3333 /* monitor white point */ |
4486 |
#define CIE_y_w 0.3333 |
4487 |
#endif |
4488 |
|
4489 |
#define CIE_D ( CIE_x_r*(CIE_y_g - CIE_y_b) + \\ |
4490 |
CIE_x_g*(CIE_y_b - CIE_y_r) + \\ |
4491 |
CIE_x_b*(CIE_y_r - CIE_y_g) ) |
4492 |
#define CIE_C_rD ( (1./CIE_y_w) * \\ |
4493 |
( CIE_x_w*(CIE_y_g - CIE_y_b) - \\ |
4494 |
CIE_y_w*(CIE_x_g - CIE_x_b) + \\ |
4495 |
CIE_x_g*CIE_y_b - CIE_x_b*CIE_y_g ) ) |
4496 |
#define CIE_C_gD ( (1./CIE_y_w) * \\ |
4497 |
( CIE_x_w*(CIE_y_b - CIE_y_r) - \\ |
4498 |
CIE_y_w*(CIE_x_b - CIE_x_r) - \\ |
4499 |
CIE_x_r*CIE_y_b + CIE_x_b*CIE_y_r ) ) |
4500 |
#define CIE_C_bD ( (1./CIE_y_w) * \\ |
4501 |
( CIE_x_w*(CIE_y_r - CIE_y_g) - \\ |
4502 |
CIE_y_w*(CIE_x_r - CIE_x_g) + \\ |
4503 |
CIE_x_r*CIE_y_g - CIE_x_g*CIE_y_r ) ) |
4504 |
|
4505 |
#define CIE_rf (CIE_y_r*CIE_C_rD/CIE_D) |
4506 |
#define CIE_gf (CIE_y_g*CIE_C_gD/CIE_D) |
4507 |
#define CIE_bf (CIE_y_b*CIE_C_bD/CIE_D) |
4508 |
|
4509 |
float xyz2rgbmat[3][3] = { /* XYZ to RGB */ |
4510 |
{(CIE_y_g - CIE_y_b - CIE_x_b*CIE_y_g + CIE_y_b*CIE_x_g)/CIE_C_rD, |
4511 |
(CIE_x_b - CIE_x_g - CIE_x_b*CIE_y_g + CIE_x_g*CIE_y_b)/CIE_C_rD, |
4512 |
(CIE_x_g*CIE_y_b - CIE_x_b*CIE_y_g)/CIE_C_rD}, |
4513 |
{(CIE_y_b - CIE_y_r - CIE_y_b*CIE_x_r + CIE_y_r*CIE_x_b)/CIE_C_gD, |
4514 |
(CIE_x_r - CIE_x_b - CIE_x_r*CIE_y_b + CIE_x_b*CIE_y_r)/CIE_C_gD, |
4515 |
(CIE_x_b*CIE_y_r - CIE_x_r*CIE_y_b)/CIE_C_gD}, |
4516 |
{(CIE_y_r - CIE_y_g - CIE_y_r*CIE_x_g + CIE_y_g*CIE_x_r)/CIE_C_bD, |
4517 |
(CIE_x_g - CIE_x_r - CIE_x_g*CIE_y_r + CIE_x_r*CIE_y_g)/CIE_C_bD, |
4518 |
(CIE_x_r*CIE_y_g - CIE_x_g*CIE_y_r)/CIE_C_bD} |
4519 |
}; |
4520 |
|
4521 |
float rgb2xyzmat[3][3] = { /* RGB to XYZ */ |
4522 |
{CIE_x_r*CIE_C_rD/CIE_D,CIE_x_g*CIE_C_gD/CIE_D,CIE_x_b*CIE_C_bD/CIE_D}, |
4523 |
{CIE_y_r*CIE_C_rD/CIE_D,CIE_y_g*CIE_C_gD/CIE_D,CIE_y_b*CIE_C_bD/CIE_D}, |
4524 |
{(1.-CIE_x_r-CIE_y_r)*CIE_C_rD/CIE_D, |
4525 |
(1.-CIE_x_g-CIE_y_g)*CIE_C_gD/CIE_D, |
4526 |
(1.-CIE_x_b-CIE_y_b)*CIE_C_bD/CIE_D} |
4527 |
}; |
4528 |
|
4529 |
|
4530 |
cie_rgb(rgbcolor, ciecolor) /* convert CIE to RGB */ |
4531 |
register float *rgbcolor, *ciecolor; |
4532 |
{ |
4533 |
register int i; |
4534 |
|
4535 |
for (i = 0; i < 3; i++) { |
4536 |
rgbcolor[i] = xyz2rgbmat[i][0]*ciecolor[0] + |
4537 |
xyz2rgbmat[i][1]*ciecolor[1] + |
4538 |
xyz2rgbmat[i][2]*ciecolor[2] ; |
4539 |
if (rgbcolor[i] < 0.0) /* watch for negative values */ |
4540 |
rgbcolor[i] = 0.0; |
4541 |
} |
4542 |
} |
4543 |
|
4544 |
|
4545 |
rgb_cie(ciecolor, rgbcolor) /* convert RGB to CIE */ |
4546 |
register float *ciecolor, *rgbcolor; |
4547 |
{ |
4548 |
register int i; |
4549 |
|
4550 |
for (i = 0; i < 3; i++) |
4551 |
ciecolor[i] = rgb2xyzmat[i][0]*rgbcolor[0] + |
4552 |
rgb2xyzmat[i][1]*rgbcolor[1] + |
4553 |
rgb2xyzmat[i][2]*rgbcolor[2] ; |
4554 |
} |
4555 |
.fi |
4556 |
.LP |
4557 |
An alternative to adopting the above code is to use the MGF "cmix" |
4558 |
entity to convert from RGB directly by naming the three primaries in |
4559 |
terms of their chromaticities, e.g: |
4560 |
.DS |
4561 |
c R = |
4562 |
cxy 0.640 0.330 |
4563 |
c G = |
4564 |
cxy 0.290 0.600 |
4565 |
c B = |
4566 |
cxy 0.150 0.060 |
4567 |
.DE |
4568 |
.LP |
4569 |
Then, converting from RGB to MGF colors is as simple as multiplying each |
4570 |
component by its relative luminance in a cmix statement, for instance: |
4571 |
.DS |
4572 |
c white = |
4573 |
cmix 0.265 R 0.670 G 0.065 B |
4574 |
.DE |
4575 |
.LP |
4576 |
For the chosen RGB standard, the above specification would result a pure |
4577 |
white. |
4578 |
The reason the coefficients are not all 1 as you might expect is |
4579 |
that cmix uses relative luminance as the standard for its weights. |
4580 |
Since |
4581 |
blue is less luminous for the same energy than red, which is in turn |
4582 |
less luminous than green, the weights cannot be the same to achieve an |
4583 |
even spectral balance. |
4584 |
Unfortunately, computing these relative weights |
4585 |
is not straightforward, though it is given in the above macros as CIE_rf, |
4586 |
CIE_gf and CIE_bf. |
4587 |
(The common factors in these macros may of course |
4588 |
be removed since |
4589 |
.UL cmix |
4590 |
weights are all relative.)\0 |
4591 |
Alternatively, one could measure the actual full scale luminance of |
4592 |
the phosphors with a luminance probe and get the same relative |
4593 |
values. |
4594 |
.NH 2 |
4595 |
Relation to IESNA LM-63 and Luminaire Catalogs |
4596 |
.LP |
4597 |
Recently, the Illuminating Engineering Society of North America |
4598 |
(IESNA) adopted MGF as the official standard for |
4599 |
representing luminaire geometry and materials. |
4600 |
The way this works in an IES luminaire data file is through the |
4601 |
addition of a keyword called LUMINOUSGEOMETRY, which is given on a |
4602 |
line in the header portion of a file (before the TILT specification) |
4603 |
like so: |
4604 |
.LP |
4605 |
.B [LUMINOUSGEOMETRY] |
4606 |
.I mgf_file |
4607 |
.LP |
4608 |
The given MGF file must exist relative to the directory containing |
4609 |
the IES file (i.e. the same stipulations and restrictions on pathnames |
4610 |
apply as for the MGF |
4611 |
.UL i |
4612 |
entity). |
4613 |
Furthermore, the position of the MGF geometry must be |
4614 |
such that the gross geometric specification of emitting surfaces |
4615 |
in the IES file completely |
4616 |
blocks or encloses the luminous portions of the MGF description. |
4617 |
Specifically, any ray traced towards the MGF geometry must strike |
4618 |
the IES gross geometry before it strikes any luminous surface in the |
4619 |
MGF description. |
4620 |
This provides a convenient way of preventing overcounting in the |
4621 |
illumination calculation, while still allowing for accurate fixture |
4622 |
appearance. |
4623 |
.LP |
4624 |
To give two examples, let us consider first a recessed can, followed |
4625 |
by a hanging direct/indirect fluorescent fixture. |
4626 |
.LP |
4627 |
The most appropriate IES geometric specification for the emitting |
4628 |
area of a can light would be a circular disk. |
4629 |
Since the IES gross geometry gives only the diameter of the disk, the |
4630 |
actual 3-dimensional placement is implicitly defined as having a |
4631 |
center at the origin, with the radiating disk facing in the |
4632 |
negative Z direction (nadir, downwards). |
4633 |
The MGF geometry would then be placed such that any luminous portion |
4634 |
was above this disk, and no portion of it would obstruct the IES |
4635 |
geometry. |
4636 |
The most sensible position therefore has the IES disk flush with the |
4637 |
MGF can opening, as shown in Figure 3. |
4638 |
.bp |
4639 |
Replace this page with the second page from "figures.ps". |
4640 |
.bp |
4641 |
.LP |
4642 |
In the case of a direct/indirect fluorescent fixture, light will |
4643 |
exit both the top and the bottom sides, and the IES geometry must |
4644 |
enclose the radiating portion of the fixture entirely. |
4645 |
It is acceptable to have additional MGF geometry above the |
4646 |
fixture so long as it does not radiate, which is what we must do if |
4647 |
we wish to include the support rods, as shown in Figure 4. |
4648 |
.LP |
4649 |
Note that the origin is always in the exact center of the IES |
4650 |
geometry. |
4651 |
.LP |
4652 |
Not all fixtures will fit the simple IES geometry specification so |
4653 |
nicely. |
4654 |
For odd-shaped fixtures, it may be necessary to use an IES geometry |
4655 |
that does not match the radiating area terribly well in order that |
4656 |
it completely block or enclose the required MGF specification. |
4657 |
.LP |
4658 |
The unit of length in the MGF file is always meters, regardless of |
4659 |
the units specified in the enclosing IES file. |
4660 |
However, any and all multipliers applied to the candlepower data in the |
4661 |
IES file will also be applied to the emittance of surfaces in the |
4662 |
MGF specification, so that one MGF file may serve similar |
4663 |
luminaires that differ in their total output. |
4664 |
.NH |
4665 |
Credits |
4666 |
.LP |
4667 |
The MGF language grew out of a joint investigation into physical |
4668 |
representations for rendering undertaken by the author |
4669 |
(Greg Ward of LBL) and Holly Rushmeier of the National |
4670 |
Institute of Standards and Technology. |
4671 |
After deciding that a complete and robust specification was |
4672 |
an extreme challenge, we shelved the project for another time. |
4673 |
A few months later, the author spoke with Ian Ashdown and Robert |
4674 |
Shakespeare, who are both members of the IES Computing Committee, |
4675 |
about the need for extending the existing data standard to |
4676 |
include luminaire geometry and near-field photometry. |
4677 |
We then moved forward as a team towards a somewhat less ambitious |
4678 |
approach to physical materials and geometry that had the advantage |
4679 |
of simplicity and the possibility of support with a standard parser |
4680 |
library. |
4681 |
The author went to work over the next two months |
4682 |
on the detailed design of the language |
4683 |
and an ANSI-C parser, with regular feedback from the other three |
4684 |
team members. |
4685 |
Several months and several versions later, we arrived at release |
4686 |
1.0, which is the occasion of this document's creation. |
4687 |
.LP |
4688 |
Funding for this work... would be nice. |