1 |
TRANSLATING TO MGF FROM OTHER FORMATS |
2 |
RCSid "$Id$" |
3 |
|
4 |
The description of the parser and the MGF specification should provide |
5 |
enough information to get you started using MGF scene files, but we |
6 |
thought it would be helpful to also provide some hints and |
7 |
suggestions for translating to MGF from other formats. |
8 |
Specifically, we will discuss several issues that come up repeatedly |
9 |
when converting from more usual computer graphics scene formats to |
10 |
MGF, most of them having to do with materials. First, let's look at |
11 |
some geometry-related issues. |
12 |
|
13 |
Vertex Naming |
14 |
============= |
15 |
Many scene formats do not name vertices; many do not even share |
16 |
vertices. Does it matter what names are given to vertices in MGF? |
17 |
Not a lot, but it can affect memory and file size. In a way, vertex |
18 |
sharing is nothing more than a form of file compression, and the |
19 |
better you are at sharing vertex information, the smaller your file |
20 |
will be. (Vertex sharing is also important for some rendering |
21 |
algorithms, which depend on it for computing surface adjacency.) |
22 |
|
23 |
If you are translating from a format that shares unnamed vertices, |
24 |
such as Wavefront's .OBJ format, you will want to name your MGF |
25 |
vertices according to some simple pattern. In most cases, a name |
26 |
such as "v%d" will do, where %d is replaced by an incremented |
27 |
integer. |
28 |
|
29 |
If, on the other hand, you are translating from a format that does |
30 |
not share vertices, you should do one of two things. You should |
31 |
either select your MGF vertex names from a small, recycled pool of |
32 |
names, or figure out some way to share vertices that were not shared |
33 |
before. In the first case, you will just allocate as many vertex |
34 |
names as you need for any given object, then reuse these names and |
35 |
therefore the parser's memory for other objects. In the second case, |
36 |
you will cache vertex names and values in some LRU table of |
37 |
predetermined size, and use this table to merge vertices in the |
38 |
file. (See rad2mgf.c as an example of how this can be done.) |
39 |
|
40 |
For some objects, there may be little point in merging vertices, and |
41 |
you may want to treat these surfaces separately. For example, |
42 |
putting out an MGF ring means putting out a central vertex, which |
43 |
must have both a position point and a normal direction. It is somewhat |
44 |
unlikely that any other MGF entity will share this point, and quite |
45 |
unlikely that it will share the normal direction, so there is little |
46 |
sense in trying to merge or otherwise reuse it. |
47 |
|
48 |
Points and Lines |
49 |
================ |
50 |
Although points and lines are really 3-d surfaces, many CAD |
51 |
systems include them in their models. The question then is, |
52 |
what do we do with these in MGF? If the idea is to produce a point |
53 |
or line on the final display that is one or two pixels wide, there |
54 |
is little one can do to guarantee such a thing will happen because |
55 |
the pixel size is dependent on view and display parameters as well |
56 |
as object location. |
57 |
|
58 |
There are two ways of dealing with points and lines in MGF. The |
59 |
first is to say, "Hey, these are 0 and 1 dimensional entities, so |
60 |
they won't appear in 3 dimensions," and get rid of them. The second |
61 |
approach is to assign some user-specified dimension for the "width" |
62 |
of points and lines, and turn them into spheres and cylinders. It |
63 |
might be best to instead create minimal polyhedron analogs, such as |
64 |
tetrahedra for points and triangular prisms for lines. That way, an |
65 |
itty-bitty point won't be converted into 200 polygons because the |
66 |
translator reading in the MGF file can't handle curved surfaces. |
67 |
|
68 |
Polygons with Holes |
69 |
=================== |
70 |
There is no explicit representation of holes in MGF. A hole must be |
71 |
represented implicitly by connecting vertices to form "seams." For |
72 |
example, a wall with a window in it might look like this: |
73 |
|
74 |
v1.-----------------------------------------------.v4 |
75 |
| | |
76 |
| v8.---------------.v5 | |
77 |
| | | | |
78 |
| | | | |
79 |
| v7.---------------.v6 | |
80 |
| | |
81 |
| | |
82 |
v2.-----------------------------------------------.v3 |
83 |
|
84 |
In many systems, the wall itself would be represented with the first |
85 |
list of vertices, (v1,v2,v3,v4) and the hole associated with that |
86 |
wall as a second set of vertices (v5,v6,v7,v8). In MGF, we must |
87 |
give the whole thing as a single polygon, connecting the vertices so |
88 |
as to create a "seam," thus: |
89 |
|
90 |
v1.----------------------<------------------------.v4 |
91 |
| _____--><---'| |
92 |
| v8.------->-------.v5 | |
93 |
| | v | |
94 |
v ^ | ^ |
95 |
| v7.-------<-------.v6 | |
96 |
| | |
97 |
| | |
98 |
v2.---------------------->------------------------.v3 |
99 |
|
100 |
which could be written in MGF as "f v1 v2 v3 v4 v5 v6 v7 v8 v5 v4". |
101 |
|
102 |
It is very important that the order of the hole be opposite to the |
103 |
order of the outer perimeter, otherwise the polygon will be |
104 |
"twisted" on top of itself. Note also that the seam was traversed |
105 |
in both directions, once going from v4 to v5, and again returning |
106 |
from v5 to v4. This is a necessary condition for a proper seam. |
107 |
(The final edge from v4 back to v1 is implied in MGF.) |
108 |
|
109 |
The choice of vertices to make into a seam is somewhat arbitrary, but |
110 |
some rendering systems may not give sane results if you cross over a |
111 |
hole with part of your seam. If we had chosen to create the seam |
112 |
between v2 and v5 in the above example instead of v4 and v5, the seam |
113 |
would cross our hole and may not render correctly. (For systems that |
114 |
are sensitive to this, it is probably safest for their MGF |
115 |
loader/translator re-expresses seams in terms of holes again, which can |
116 |
be done easily so long as vertices are shared in the above fashion.) |
117 |
|
118 |
Non-planar Polygons |
119 |
=================== |
120 |
Polygons in MGF should be planar. There is nothing about the format |
121 |
that enforces this, but the rendering or modeling software on the other |
122 |
end may have real problems if this requirement is violated. The parser |
123 |
itself does not test for non-planar polygons, so when in doubt about a |
124 |
model, it is safest to test for planarity and break a polygon into triangles |
125 |
if it is even slightly non-planar. |
126 |
|
127 |
NURBS, CSG, Blobbies, Etc. |
128 |
========================== |
129 |
Sorry, folks, this is just plain hard. If and until MGF supports these |
130 |
higher-order entities, it will be necessary for you to convert them to |
131 |
smoothed triangle meshes. Fortunately, a lot of modeling software |
132 |
already knows how to do this, so if you wrote the modeler, you probably |
133 |
have access to the necessary code. (By the way, if you ever want to see |
134 |
these primitives in MGF, you might just think about sharing the wealth, |
135 |
because the MGF parser needs to mesh every primitive it supports.) |
136 |
|
137 |
Materials |
138 |
========= |
139 |
The MGF material model was designed to accommodate most common |
140 |
physical surfaces. Included are reasonable models for plastic |
141 |
and metal, thin glass and translucent surfaces. Not included at |
142 |
this time are surfaces with anisotropic reflection, refraction and/or |
143 |
surface textures. These were deemed either unnecessary or too |
144 |
difficult to standardize for the initial format. Also, light |
145 |
sources are known only by the emissive nature of their surface(s), |
146 |
and MGF itself only provides for diffuse emission. (As MGF is |
147 |
destined to be part of the IES luminaire data standard, it was |
148 |
assumed that this combined format would be used for such purposes as |
149 |
describing light source output and geometry.) |
150 |
|
151 |
The "sides" entity is used to control the number of sides a surface |
152 |
should have. In the real world, a surface can have only one side, |
153 |
defining the interface between one volume and another. Many |
154 |
object-space rendering packages (e.g. z-buffer algorithms) take |
155 |
advantage of this fact by culling back-facing polygons and thus saving |
156 |
roughly 50% of the calculation time. However, many models rely on an |
157 |
approximation whereby a single surface is used to represent a very thin |
158 |
volume, such as a pane of glass, and this also can provide significant |
159 |
calculational savings in an image-space algorithm (such as |
160 |
ray-tracing). Since both types of surfaces are useful and both types |
161 |
of rendering algorithms may ultimately be applied, MGF provides a way |
162 |
to specify sidedness rather than picking one interpretation or the other. |
163 |
|
164 |
So-called specular reflection and transmission are modeled using a |
165 |
Gaussian distribution of surface normals. The "alpha_r" and |
166 |
"alpha_t" parameters to the respective "rs" and "ts" entities specify |
167 |
the root-mean-squared (RMS) surface facet slope, which varies from 0 |
168 |
for a perfectly smooth surface to around .2 for a fairly rough one. |
169 |
The effect this will have on the reflected component distribution is |
170 |
well-defined, but predicting the behavior of the transmitted |
171 |
component requires further assumptions. We assume that the surface |
172 |
scatters light passing through it just as much as it scatters |
173 |
reflected light. This assumption is approximately correct for a |
174 |
two-sided transparent material with an index of refraction of 1.5 |
175 |
(about that of glass) and both sides having the given RMS facet |
176 |
slope. |
177 |
|
178 |
Oftentimes, one is translating from a Phong exponent on the cosine |
179 |
of the half-vector-to-normal angle to the more physical but less |
180 |
familiar Gaussian model of MGF. The hardest part is translating |
181 |
the specular power to a roughness value. For this, we recommend |
182 |
the following approximation: |
183 |
|
184 |
roughness = 0.6/sqrt(specular_power) |
185 |
|
186 |
It's not a perfect correlation, but it's about as good as you can get. |
187 |
|
188 |
Colors |
189 |
====== |
190 |
Unlike most graphics languages, MGF does not use an RGB color model, |
191 |
simply because there is no recognized definition for this model. |
192 |
It is based on computer monitor phosphors, which vary from one |
193 |
CRT to the next. (There is an RGB standard defined in the TV |
194 |
industry, but this has a rather poor correlation to most computer |
195 |
monitors.) |
196 |
|
197 |
MGF uses two alternative, well-defined standards. The first is the CIE |
198 |
standard xy chromaticity coordinates. With this standard, any viewable |
199 |
color may be exactly reproduced. Unfortunately, the interaction between |
200 |
colors (i.e. colored light sources and interreflections) cannot be |
201 |
specified exactly with any finite coordinate set, including CIE |
202 |
chromaticities. So, MGF offers the ability to give reflectance, |
203 |
transmittance or emittance as a function of wavelength over the visible |
204 |
spectrum. This function is still discretized, but at a user-selectable |
205 |
resolution. Furthermore, spectral colors may be mixed, providing (nearly) |
206 |
arbitrary basis functions, which can produce more accurate results in |
207 |
some cases and are merely a convenience for translation in others. |
208 |
|
209 |
Conversion back and forth between CIE chromaticity coordinates and spectral |
210 |
samples is provided within the MGF parser. Unfortunately, conversion |
211 |
to and from RGB values depends on a particular RGB definition, and as we |
212 |
have said, there is no recognized standard. We therefore recommend that |
213 |
you decide yourself what chromaticity values to use for each RGB primary, |
214 |
and adopt the following code to convert between CIE and RGB coordinates. |
215 |
|
216 |
#ifdef NTSC |
217 |
#define CIE_x_r 0.670 /* standard NTSC primaries */ |
218 |
#define CIE_y_r 0.330 |
219 |
#define CIE_x_g 0.210 |
220 |
#define CIE_y_g 0.710 |
221 |
#define CIE_x_b 0.140 |
222 |
#define CIE_y_b 0.080 |
223 |
#define CIE_x_w 0.3333 /* monitor white point */ |
224 |
#define CIE_y_w 0.3333 |
225 |
#else |
226 |
#define CIE_x_r 0.640 /* nominal CRT primaries */ |
227 |
#define CIE_y_r 0.330 |
228 |
#define CIE_x_g 0.290 |
229 |
#define CIE_y_g 0.600 |
230 |
#define CIE_x_b 0.150 |
231 |
#define CIE_y_b 0.060 |
232 |
#define CIE_x_w 0.3333 /* monitor white point */ |
233 |
#define CIE_y_w 0.3333 |
234 |
#endif |
235 |
|
236 |
#define CIE_D ( CIE_x_r*(CIE_y_g - CIE_y_b) + \ |
237 |
CIE_x_g*(CIE_y_b - CIE_y_r) + \ |
238 |
CIE_x_b*(CIE_y_r - CIE_y_g) ) |
239 |
#define CIE_C_rD ( (1./CIE_y_w) * \ |
240 |
( CIE_x_w*(CIE_y_g - CIE_y_b) - \ |
241 |
CIE_y_w*(CIE_x_g - CIE_x_b) + \ |
242 |
CIE_x_g*CIE_y_b - CIE_x_b*CIE_y_g ) ) |
243 |
#define CIE_C_gD ( (1./CIE_y_w) * \ |
244 |
( CIE_x_w*(CIE_y_b - CIE_y_r) - \ |
245 |
CIE_y_w*(CIE_x_b - CIE_x_r) - \ |
246 |
CIE_x_r*CIE_y_b + CIE_x_b*CIE_y_r ) ) |
247 |
#define CIE_C_bD ( (1./CIE_y_w) * \ |
248 |
( CIE_x_w*(CIE_y_r - CIE_y_g) - \ |
249 |
CIE_y_w*(CIE_x_r - CIE_x_g) + \ |
250 |
CIE_x_r*CIE_y_g - CIE_x_g*CIE_y_r ) ) |
251 |
|
252 |
#define CIE_rf (CIE_y_r*CIE_C_rD/CIE_D) |
253 |
#define CIE_gf (CIE_y_g*CIE_C_gD/CIE_D) |
254 |
#define CIE_bf (CIE_y_b*CIE_C_bD/CIE_D) |
255 |
|
256 |
float xyz2rgbmat[3][3] = { /* XYZ to RGB */ |
257 |
{(CIE_y_g - CIE_y_b - CIE_x_b*CIE_y_g + CIE_y_b*CIE_x_g)/CIE_C_rD, |
258 |
(CIE_x_b - CIE_x_g - CIE_x_b*CIE_y_g + CIE_x_g*CIE_y_b)/CIE_C_rD, |
259 |
(CIE_x_g*CIE_y_b - CIE_x_b*CIE_y_g)/CIE_C_rD}, |
260 |
{(CIE_y_b - CIE_y_r - CIE_y_b*CIE_x_r + CIE_y_r*CIE_x_b)/CIE_C_gD, |
261 |
(CIE_x_r - CIE_x_b - CIE_x_r*CIE_y_b + CIE_x_b*CIE_y_r)/CIE_C_gD, |
262 |
(CIE_x_b*CIE_y_r - CIE_x_r*CIE_y_b)/CIE_C_gD}, |
263 |
{(CIE_y_r - CIE_y_g - CIE_y_r*CIE_x_g + CIE_y_g*CIE_x_r)/CIE_C_bD, |
264 |
(CIE_x_g - CIE_x_r - CIE_x_g*CIE_y_r + CIE_x_r*CIE_y_g)/CIE_C_bD, |
265 |
(CIE_x_r*CIE_y_g - CIE_x_g*CIE_y_r)/CIE_C_bD} |
266 |
}; |
267 |
|
268 |
float rgb2xyzmat[3][3] = { /* RGB to XYZ */ |
269 |
{CIE_x_r*CIE_C_rD/CIE_D,CIE_x_g*CIE_C_gD/CIE_D,CIE_x_b*CIE_C_bD/CIE_D}, |
270 |
{CIE_y_r*CIE_C_rD/CIE_D,CIE_y_g*CIE_C_gD/CIE_D,CIE_y_b*CIE_C_bD/CIE_D}, |
271 |
{(1.-CIE_x_r-CIE_y_r)*CIE_C_rD/CIE_D, |
272 |
(1.-CIE_x_g-CIE_y_g)*CIE_C_gD/CIE_D, |
273 |
(1.-CIE_x_b-CIE_y_b)*CIE_C_bD/CIE_D} |
274 |
}; |
275 |
|
276 |
|
277 |
cie_rgb(rgbcolor, ciecolor) /* convert CIE to RGB */ |
278 |
register float *rgbcolor, *ciecolor; |
279 |
{ |
280 |
register int i; |
281 |
|
282 |
for (i = 0; i < 3; i++) { |
283 |
rgbcolor[i] = xyz2rgbmat[i][0]*ciecolor[0] + |
284 |
xyz2rgbmat[i][1]*ciecolor[1] + |
285 |
xyz2rgbmat[i][2]*ciecolor[2] ; |
286 |
if (rgbcolor[i] < 0.0) |
287 |
rgbcolor[i] = 0.0; |
288 |
} |
289 |
} |
290 |
|
291 |
|
292 |
rgb_cie(ciecolor, rgbcolor) /* convert RGB to CIE */ |
293 |
register float *ciecolor, *rgbcolor; |
294 |
{ |
295 |
register int i; |
296 |
|
297 |
for (i = 0; i < 3; i++) |
298 |
ciecolor[i] = rgb2xyzmat[i][0]*rgbcolor[0] + |
299 |
rgb2xyzmat[i][1]*rgbcolor[1] + |
300 |
rgb2xyzmat[i][2]*rgbcolor[2] ; |
301 |
} |
302 |
|
303 |
An alternative to adopting the above code is to use the MGF "cmix" |
304 |
entity to convert from RGB directly by naming the three primaries in |
305 |
terms of their chromaticities, e.g: |
306 |
|
307 |
c r = |
308 |
cxy 0.640 0.330 |
309 |
c g = |
310 |
cxy 0.290 0.600 |
311 |
c b = |
312 |
cxy 0.150 0.060 |
313 |
|
314 |
Then, converting from RGB to MGF colors is as simple as multiplying each |
315 |
component by its relative luminance in a cmix statement, for instance: |
316 |
|
317 |
c white = |
318 |
cmix 0.265 r 0.670 g 0.065 b |
319 |
|
320 |
For the chosen RGB standard, the above specification would result a pure |
321 |
white. The reason the coefficients are not all 1 as you might expect is |
322 |
that cmix uses relative luminance as the standard for its weights. Since |
323 |
blue is less luminous for the same energy than red, which is in turn |
324 |
less luminous than green, the weights cannot be the same to achieve an |
325 |
even spectral balance. Unfortunately, computing these relative weights |
326 |
is not straightforward, though it is given in the above macros as CIE_rf, |
327 |
CIE_gf and CIE_bf. (The common factors in these macros may of course |
328 |
be removed for simplification purposes.) |