ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/radiance/ray/src/cv/mgflib/translat.txt
(Generate patch)

Comparing ray/src/cv/mgflib/translat.txt (file contents):
Revision 1.1 by greg, Wed Sep 7 16:32:20 1994 UTC vs.
Revision 1.2 by greg, Thu Sep 8 12:10:10 1994 UTC

# Line 32 | Line 32 | either select your MGF vertex names from a small, recy
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.)
# Line 53 | Line 53 | what do we do with these in MGF?  If the idea is to pr
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
# Line 111 | Line 111 | some rendering systems may not give sane results if yo
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  
# Line 121 | Line 121 | Polygons in MGF should be planar.  There is nothing ab
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.
# Line 159 | Line 159 | volume, such as a pane of glass, and this also can pro
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
# Line 191 | Line 191 | Unlike most graphics languages, MGF does not use an RG
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
# Line 203 | Line 204 | transmittance or emittance as a function of wavelength
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
# Line 299 | Line 300 | register float  *ciecolor, *rgbcolor;
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
# Line 321 | Line 323 | that cmix uses relative luminance as the standard for
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.)

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines