cv/mgflib/spec.txt

                MATERIALS AND GEOMETRY FORMAT
                SCCSid "$SunId$ LBL"

Introduction
============
The following file format is a simple ASCII representation of surface
geometry and materials for the purpose of visible-light simulation
and rendering.  The overall objective of this format is to provide
a very simple yet fairly complete modeling language that does not
place unreasonable demands on the applications programmer or the
object library creator.

Similar to Wavefront's .OBJ file format, our format utilizes a
number of object entities, one per line, some of which establish
a context for the entities that follow.  Specifically, there is
a context for the current vertex, the current color, and the
current material.  The current vertex is used only for setting
values related to that vertex.  The current color is used for
setting values related to that color, as well as by certain
material attributes which take an optional color setting.
The current material is used for setting material-related
parameters, and for establishing the material for the following
geometric entities.  In addition to these three named contexts,
there are two hierarchical (i.e. cumulative) contexts, the
current transform and the current object name.

Each entity is given by a short keyword, followed by space- or tab-
delimited arguments on a single line.  A single entity may be extended
over multiple lines using a backslash ('\') character right before the
end of line, though no extended line may exceed 4096 characters in total
length.

Entities and Contexts
=====================
There are three contexts in effect at all times, current vertex,
current color and current material.  Initially, these contexts are
unnamed, and have specific default values.  The unnamed vertex is the
origin.  The unnamed color is neutral gray.  The unnamed material is a
perfect (two-sided) absorber.  The unnamed contexts may be modified,
but those modifications will not be saved.  Thus, reestablishing an
unnamed context always gets its initial default value.  To save a new
context or modify an old one, it must first be named.  Entities
associated with named contexts (i.e. "v", "c" and "m") may be followed
by an identifier and an equals sign ('='), indicating a new context.
If there is no equals, then the context must already be defined, and
the appearance of the entity merely reestablishes this context.  If the
context id is followed by an equals, then a new context is defined,
destroying any previous instance of that context name.  Redefining or
changing values of a context does not affect earlier uses of the same
name, however.  Contexts are always associated with a name id, which is
any non-blank sequence of printing ASCII characters.  An optional
template may be given following the equals, which is a previously
defined context to use as a source of default values for this
definition.  If no template is given, then the unnamed context of that
type is used to set initial values.  Named contexts continue until the
next context definition of the same type.

Hierarchical Contexts
=====================
Two entities define a second type of context, which is hierarchical.
These are the transform ("xf") entity and the object ("o") entity.
The object entity is used simply for naming collections of surfaces.
An object entity with a name applies to the following surfaces up
until an object entity with no name, which signifies the end of this
object's scope.  Object entities may be nested to any level, and
can be thought of as parts and subparts of an enclosing global object.
Note that this is strictly for ease of identification, and has no
real meaning as far as the geometric description goes.  In contrast,
the transform entity is very significant as it determines how enclosing
objects are to be scaled and placed in the final description.  Hierarchical
contexts may be nested in any way, but should not overlap.

Without further ado, here are the proposed entities and their interpretations:

Keyword Arguments               Meaning
------- ---------               -------
#       anything                a comment
i       filename [xform]        include file (with transformation)
ies     filename [-m f][xform]  include IES luminaire (with transformation)
v       [id [= [template]]]     get/set vertex context
p       x y z                   set point position for current vertex
n       dx dy dz                set surface normal for current vertex
c       [id [= [template]]]     get/set color context
cxy     x y                     set CIE (x,y) chromaticity for current color
cspec   l_min l_max v1 v2 ..    set relative spectrum for current color
cct     temperature             set spectrum based on black body temperature
cmix    w1 c1 w2 c2 ..          mix named colors to make current color
m       [id [= [template]]]     get/set material context
sides   {1|2}                   set number of sides for current material
rd      rho_d                   set diffuse reflectance for current material
td      tau_d                   set diffuse transmittance for current material
ed      epsilon_d               set diffuse emittance for current material
rs      rho_s alpha_r           set specular reflectance for current material
ts      tau_s alpha_t           set specular transmittance for current material
o       [name]                  begin/end object context
f       v1 v2 v3 ..             polygon using current material, spec. vertices
sph     vc radius               sphere
cyl     v1 radius v2            truncated right cylinder (open-ended)
cone    v1 rad1 v2 rad2         truncated right cone (open-ended)
prism   v1 v2 v3 .. length      truncated right prism (closed solid)
ring    vc rmin rmax            circular ring with inner and outer radii
torus   vc rmin rmax            circular torus with inner and outer radii
xf      [xform]                 begin/end transformation context

These are the context dependencies of each entity:

Entities                                Contexts
--------                                --------
p, n                                    vertex
cxy, cspec, cmix                        color
sides                                   material
rd, td, ed, rs, ts                      color, material
f, sph, cyl, cone, ring, torus, prism   material, object, transformation

Transformations
===============
A rigid body transformation is given with the transform entity, or as
part of an included file.  The following transformation flags and
arguments are defined:

        -t dx dy dz             translate objects along the given vector
        -rx degrees             rotate objects about the X-axis
        -ry degrees             rotate objects about the Y-axis
        -rz degrees             rotate objects about the Z-axis
        -s scalefactor          scale objects by the given factor
        -mx                     mirror objects about the Y-Z plane
        -my                     mirror objects about the X-Z plane
        -mz                     mirror objects about the X-Y plane
        -i N                    repeat the following arguments N times
        -a N                    make an array of N geometric instances

Transform arguments have a cumulative effect.  That is, a rotation
about X of 20 degrees followed by a rotation about X of -50 degrees
results in a total rotation of -30 degrees.  However, if the two
rotations are separated by some translation vector, the cumulative
effect is quite different.  It is best to think of each argument as
acting on the included geometric objects, and each subsequent transformation
argument affects the objects relative to their new position/orientation.

For example, rotating an object about its center requires translating
the object back to the origin, applying the desired rotation, and translating
it again back to its original position.

Rotations are given in degrees counter-clockwise about a principal axis.
That is, with the thumb of the right hand pointing in the direction
of the axis, rotation follows the curl of the fingers.

The transform command itself is also cumulative, but in the reverse
order.  That is, later transformations (i.e. enclosed transformations)
are prepended to existing (i.e. enclosing) ones.  A transform command
with no arguments is used to return to the previous condition.  It is
necessary that transforms and their end statements ("xf" by itself) be
balanced in a file, so that later or enclosing files are not affected.

Transformations apply only to geometric types, e.g. polygons, spheres, etc.
Vertices and the components that go into geometry are not directly affected.
This is to avoid confusion and the inadvertent multiple application of a
given transformation.

Arrays
======
The -a N transform specification causes the following transform
arguments to be repeated along with the contents of the included
objects N times.  The first instance of the geometry will be in its
initial location; the second instance will be repositioned according
to the named transformation; the third instance will be repositioned by
applying this transformation twice, and so on up to N-1 applications.

Multi-dimensional arrays may be specified with a single include
entity by giving multiple array commands separated by their
corresponding transforms.  A final transformation may be given
by preceeding it with a -i 1 specification.  In other words, the
scope of an array command continues until the next -i or -a option.

Other Details
=============
End of line may be any one of the sequences:  linefeed ('\n'), carriage-
return ('\r'), or a carriage return followed by a linefeed.

Blank lines are ignored on the input, as are any blanks preceeding
a keyword on a line.  Indentation may improve readability, especially
in context definitions.

The comment character ('#') must be followed by at least one blank
character (space or tab) for easy parsing.  Like any other line,
a comment may be extended to multiple lines using a backslash ('\').

Include filename paths are relative to the current file.  Absolute
paths are expressly forbidden.  UNIX conventions should be used for the
path separator ('/') and disk names should not be used (i.e. no
"C:\file").  To further enhance portability across systems, directory
names should be 8 characters or fewer with no suffix, filenames should
fit within an 8.3 format, and all characters should be lower case.
(They will be automatically promoted to upper case by DOS systems.)
We suggest the standard suffix ".mgf" for "materials and geometry format".

The XYZ coordinate system is right-handed, and lengths are always in
SI meters.  This is not really a limitation as the first statement
in the file can always be a transform with the -s option to convert
to a more convenient set of units.  Included IES files will also start
out in meters, and it is important to specify a transform into the
local coordinate system.  The -m option (preceeding any transform)
may be used to specify an output multiplication factor.

Vertex normals need not be normalized, and a normal equal to (0,0,0) indicates
that the exact surface normal should be used.  (This is the default.)

Color in this system does not include intensity, only hue and
saturation.  Intensity, such as reflectance or emittance, is explicitly
included in the other material parameters.  All colors are absolute,
e.g. spectral reflectance or transmittance under uniform white light.

A CIE xy chromaticity pair is the most basic color specification.  A
full spectrum is the most general specification, and the starting (i.e.
minimum) and ending (i.e. maximum) wavelengths are given along with a
set of evenly spaced values.  Wavelengths are given in nanometers, and
should be within the range of 380-780.  The spectral values themselves,
which can be thought of as relative power density per nanometer, start
at the first wavelength and proceed at even increments to the last
wavelength.  The values in between will be interpolated as necessary,
so there must be at least two specified points.  The color temperature
entity corresponds to the spectrum of a black body at the specified
temperature (in degrees Kelvin).  The color mixing entity is intended
not only for the mixing of named colors, but also for color
specifications  using an arbitrary set of basis functions.  The mixing
coefficients are in effect relative luminances for each color
"primary."  The actual total of the mixing coefficients or spectral
values is irrelevant, since the results will always be normalized.

Diffuse emittance is always given in SI units of lumens/meter^2.  Note that
this is emittance, not exitance, and does not include light reflected or
transmitted by the surface.

The roughness associated with specular reflectance and transmittance
is the RMS surface facet slope.  A value of 0 indicates a perfectly
smooth surface, meaning that reflected or transmitted rays will not
be scattered.

The sum of the diffuse and specular reflectances and transmittances
must be strictly less than one (with no negative values, obviously).

The object entity establishes a hierarchical context, consisting of
this identifier and all those preceding.  It has no real meaning except
to group the following surfaces up until an empty object statement
under a descriptive name for improved file readability.

Surfaces are two-sided unless the "sides" entity is used to set the
number of sides for a material to one.  If a surfaces is one-sided,
then it appears invisible when viewed from the back side.  This means
that a transmitting object will affect the light coming in through the
front surface and ignore the characteristics of the back surface.  As
long as the characteristics are the same, the results should be
correct.  If the rendering technique does not allow for one-sided
surfaces, an approximately correct result can be obtained for one-sided
transmitting surfaces by using the square root of the given tau_s and
half the given alpha_t.  If a rendering technique does not permit
two-sided surfaces, then each surface must be made into two for
full compliance if "sides" is set to 2 (the default).

The surface normal of a face is oriented by the right-hand rule.
Specifically, the surface normal faces towards the viewer when the
vertices circulate counter-clockwise.  Faces may be concave or convex,
but must be planar.  Holes may be represented as concave polygons with
coincident sides (i.e. seams).

A prism consists of a set of coplanar vertices specifying an end-face,
and a length value.  The prism will be extruded so that the end-face
points outward, unless the length value is negative, in which case the
object is extruded in the opposite direction, resulting in inward-
directed surface normals.  If surface normals are specified for the
vertices, they will be applied to the side faces but not the end
faces, and they must generally point in the appropriate direction
(i.e. in or out depending on whether extrusion is negative or positive).

A sphere, cylinder or cone with negative radii is interpreted as having
an inward facing surface normal.  Otherwise, the normal is assumed
to face outwards.  (It is illegal for a cone to have one positive and
one negative radius.)

The central vertex for a ring or torus must have an associated normal,
which serves to orient the ring.  The inner radius must be given first,
and must be strictly less than the outer radius.  The inner radius may
be zero but not negative.  There is an exception for a torus with
inward-pointing normal, which is identified by a negative outer radius
and a non-positive inner radius.

Examples
========
The following is a complete example input file (don't ask me what it is):

        # Define some materials:
        m red_plastic =
                c red =
                        cxy .8 .1
                rd 0.5
                # reestablish unnamed (neutral) color context:
                c
                rs 0.04 0.02
        m green_plastic =
                c green =
                        cxy .2 .6
                rd 0.4
                c
                rs .05 0
        m bright_emitter =
                c
                ed 1000
        m dark =
                c
                rd .08
        # Define some vertices:
        v v1 =
                p 10 5 7
        v v2 =
                p 15 3 9
        v v3 =
                p 20 -7 6
        v v4 =
                p 20 10 6
        v v5 =
                p 10 10 6
        v v6 =
                p 10 -7 6
        v cv1 =
                p -5 3 8
                n 0 0 -1
        v cv2 =
                p -3 3 8
                n 0 0 1
        # make some faces:
        m green_plastic
        f v1 v3 v4
        m red_plastic
        f v3 v4 v5
        f v5 v6 v7
        m bright_emitter
        f v3 v4 v5 v6
        # make a cylindrical source with dark end caps:
        m bright_emitter
        cyl cv1 .15 cv2
        m dark
        ring cv1 0 .15
        ring cv2 0 .15

The following is a more typical example, which relies on a material library:

        # Include our materials:
        i material.mgf
        # Modify red_plastic to have no specular component:
        m red_plastic
                rs 0 0
        # Make an alias for blue_plastic:
        m outer_material = blue_plastic
        # Make a new material based on brass, with greater roughness:
        m rough_brass = brass
                c brass_color
                rs 0.9 0.15
        # Load our vertices:
        i lum1vert.mgf
        # Modify appropriate vertices to make luminaire longer:
        v v10
                p 5 -2 -.1
        v v11
                p 5 2 -.1
        v v8
                p 5 2 0
        v v9
                p 5 -2 0
        # Load our surfaces, rotating them -90 degrees about Z:
        i lum1face.mgf -rz -90
        # Make a 2-D array of sequins covering the face of the fixture:
        m silver
        i sequin.mgf -a 5 -t .5 0 0 -a 4 -t 0 .75 0

Note that by using libraries and modifying values, it is possible to create
a variety of fixtures without requiring large files to describe each one.

Interpretation
==============
Interpretation of this language will be simplified by the creation
of a general parser that will be able to express the defined entities
in simpler forms and remove entities that would not be understood by
the caller.

For example, a caller may ask the standard parser to produce only
the entities for diffuse uncolored materials, vertices without normals,
and polygons.  The parser would then expand all include statements,
remove all color statements, convert spheres and cones to polygonal
approximations, and so forth.

This way, a single general parser can permit software to operate
at whatever level it is capable, with a minimal loss of generality.
Furthermore, distribution of a standard parser will improve
both forward and backward compatibility as new entities are added
to the specification.

Rationale
=========
Why create yet another file format for geometric data, when so many
others already exist?  The main answer to this question is that we
are not merely defining geometry, but materials as well.  Though the
number of committee and de facto standards for geometric data is large,
the number of standards for geometry + materials is small.  Of these,
almost all are non-physical in origin, i.e. they are based on common,
ad hoc computer graphics rendering practices and cannot be used to create
physical simulations.  Of the one or two formats that were intended
for or could be adapted to physical simulation, the syntax and semantics
are at the same time too complex and too limiting to serve as a suitable
standard.

Specifically, establishing the above, new standard has the following
advantages:

        o It is easy to parse.
        o It is easy to support, at least as a least common denominator.
        o It is ASCII and fairly easy for a person to read and understand.
        o It supports simple color, material and vertex libraries.
        o It includes a simple yet fairly complete material specification.
        o It is easy to skip unsupported entities (e.g. color, vertex normals)
        o It supports transformations and instances.
        o It is easy to add new entities, and as long as these entities can
                be approximated by the original set, backwards compatibility
                can be maintained through a standard parsing library.

Most of the disadvantages of this format relate to its simplicity, but
since simplicity was our most essential goal, this could not be helped.
Specifically:

        o There is no general representation of curved surfaces (though
                vertex normals make approximations straightforward).
        o There are no general surface scattering functions.
        o There are no textures or bump-maps.

If any of these seems particularly important, I will look into adding them,
though they will tend to complicate the specification and make it more
difficult to support.
Revision:	1.7
Committed:	Tue Mar 7 14:53:31 1995 UTC (30 years, 7 months ago) by greg
Content type:	text/plain
Branch:	MAIN
Changes since 1.6:	+12 -11 lines
Log Message:	added cct entity