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 parsers memory for other objects. In the second case, |
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.) |
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 scene location. |
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 |
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 necessary that their MGF |
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 |
|
|
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 |
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. |
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 model or the other. |
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 |
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 graphics.) |
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 for chromaticity coordinates. With this standard, any viewable |
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 |
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 a convenience in others. |
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 |
300 |
|
rgb2xyzmat[i][2]*rgbcolor[2] ; |
301 |
|
} |
302 |
|
|
303 |
< |
Another alternative is to use the MGF "cmix" entity to convert from RGB |
304 |
< |
directly by naming the three primaries in terms of their chromaticities, e.g: |
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 |
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, so it is given in the above macros as CIE_rf, |
327 |
< |
CIE_gf and CIE_bf. |
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.) |