| 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.)
|
