A8.2 Recognized Sections
These conventions are used in the definitions of each section.
ASCII mesh conventions.
$Mesh { ... }
Encloses a modeling context. The next vertex to be defined will have an index of 1. Nested meshes are allowed.
$ObjectName { string }
The name of the object under construction. The string must be enclosed in double quotes.
$ModelName { string }
The name of the model that the object is in. The string must be enclosed in double quotes.
$ModelRange { x1 y1 z1 x2 y2 z2 }
The recommended model range required for the object under construction. x1, y1, and z1 represent the minimum x, y, and z values required; x2, y2, and z2 represent the maxima.
$PointOfRotation { }
The invariant point used for rotation and scaling.
$Comment { }
A $Comment section is guaranteed to remain unrecognized, and thus will not be acted on by all future versions of the parser. Note that the tokens inside a $Comment section are still parsed and must therefore still nest correctly. Apart from this, the contents of a $Comment section are ignored; this allows (possibly) nested sections of a file to be commented out.
$Transform { real1 real2 ... real16 }
The 16 elements of a 4×4 transformation matrix. If the object under construction is nested inside another, then the transformation is relative to its parent.
Before the first $Vertices section in the current mesh (even an empty list of vertices), $Transform affects the local origin of the object under construction. After the appearance of the first $Vertices, the origin is unaffected, and the coordinates of all vertices defined afterward are affected. The transform should not contain any rotation (which should be specified by $Orientation below).
$Orientation { real1 real2 ... real16 }
The 16 elements of a 4×4 transformation matrix. If the object under construction is nested inside another, then the transformation is relative to its parent.
Whether the origin of the mesh under construction or the coordinates of subsequently defined vertices are affected depends on whether the first vertex has yet been defined (see $Vertices and $VerticesUV).
$Vertices { x1 y1 z1 ... xn yn zn }, n >= 0
An array of vertices for use in future $Triangles, $Quads, and $Polygons sections. The first vertex has an index of 1. The actual world coordinates of the vertex depend on the current transformation matrix defined by the $Transform section. All vertices defined by $Vertices will have the same texture coordinates. Vertices are stored in a scaled format: 1/2 representing the minimum model range, +1/2 the maximum model range.
$VerticesUV { x1 y1 z1 kU1 kV1 ... xn yn zn kUn kVn }, n >= 0
Similar to $Vertices, except that each vertex has an associated texture coordinate kU and kV (each in the range [0, 1]).
$Hints { Anything* }
Optimization hints for the display of the containing $Mesh. Any sequence of tokens is valid.
A8.2.1 Polygon Appearance
$Texture { token+ }
A token represents a valid filename or texture. If the token is missing, then there is no current texture. A token may be a full pathname, but this limits portability of the .ams file. A defined path is searched if the file is a relative pathname. (On the PC version this is given by the Script&TextureLoadPath entry of the DynamicVisualizer.ini file.)
$Rgb { k_red k_green k_blue }
Color.
$Surface { k_ambient k_diffuse k_specular k_opacity }
Surface properties.
$Quality { PointCloud  WireFrame  Flat  Gouraud  Phong }
A token not from this list is taken to be flat.
All polygons are singlesided and are completely transparent from behind. The ordering of the vertices determines which side of the polygon will be rendered. If you want to render both sides of a polygon, it is best to duplicate the vertices for each side so that gouraud (smooth) shading works properly.
$Triangles { u1 v1 w1 ... u3n v3n w3n }, n >= 0
$Quads { t1 u1 v1 w1 ... t4n u4n v4n w4n }, n >= 0
$Polygons { { v1 v2 ... vn }* }, n >= 0
n can be different for each polygon in the section.
