Unofficial MDM/MDX Format Specification

Notes:

Container object. References all MDM data.

Notes:

General information about MDM data. Used mainly to navigate file data.

Notes:

Container object. References surface data.

Background:

Surfaces are described by geometry, level-of-detail and color data. A model can consist of multiple surfaces.

Notes:

General information about a surface. Used mainly to navigate surface data.

Notes:

Vertex location, normal and texture coordinates.

The number of weights usually does not exceed 3 (at least i have never seen any model with more).

Background:

Vertex normals manipulate the shading of a surface (for example smooth or flat).

Texture coordinate values refer to the process of UV-mapping.

Notes:

Weights are used to define a vertex location in conjunction with all other weights of a vertex. The weights and their offsets are specified in binding pose.

The sum of all weights for a vertex should always be equal to 1.

Notes:

A triangle for a surface.

Notes:

The collapse map is used to render a surface with varying level of detail (LOD) dependent on view distance during runtime (progressive mesh algorithm).

Background:

The collapse map is a list of vertex indices pointing into the list of vertices for this surface. The value j at index i of the collapse map describes a collapse operation. This operation can be read as "vertex i is to be mapped/collapsed to vertex j".

A user will take a fully detailed mesh and gradually reduce vertex and triangle count at runtime by using the pre-calculated collapse map. For this, he first determines the amount of vertices the mesh should have. Then he applies the collapse operations starting from the end of the collapse map.

The particular method used was described by Stan Melax in a publication from November 1998, see "A Simple, Fast, and Effective Polygon Reduction Algorithm" for further details. A demo implementation can be found at: https://github.com/melax/sandbox/tree/master/bunnylod

Notes:

Defines which bones a surface references. Probably used for optimization inside the engine. Needs to be hierarchically ordered.

Notes:

Frame independent tag information.

MDM tags are different from MDS tags in that their location and orientation values are stored in binding pose and with location offset to the parent bone. The orientation values therefore are fixed and controlled by the parent bone, whereas a bone in MDS is actually the tag and can be animated/oriented per frame.

Background:

Tags are used to attach external models to a model. Attachment means that the external models origin aligns itself with the models tag location and orientation. As the external model is parented to the tag (nested in tag space), any animation of the tag will also affect the external model.

Domain specific scripts tell the engine which external models to attach to a given tag. These scripts are either located in mapscript files (attachtotag command) or .skin files. Sometimes they are also hard coded.

An example use case is a hat model (defined separately) attached to a head model. This way, characters can be assembled with different looks without having to duplicate their model definitions. Tags therefore support reuse.

Another example use case is that of a tank turret model attached to a tank model. Instead of having a shooting animation (rotate turret left, shoot, rotate turret right) be recorded as vertex positions across several key-frames inside a single model, a tag can be used to control  the shooting animation of a separated model. This safes memory, as the  tags animation data most likely takes much less space compared to the animation data of the tank turret inside a single model.

However, reuse and memory savings are traded against loss in performance. Vertex positions of the external models have to be recalculated against the current frame tags location and orientation.

Notes:

Container object. References all MDX data.

Notes:

General information about MDX data. Used mainly to navigate file data.

Notes:

Container object. References bounding volume and bone animation data.

Notes:

Describes bounding volume information: axially aligned bounding box and bounding sphere. Additionally contains the root bone location.

Notes:

Bone location and orientation in a specific frame.

Bone orientation values are given as compressed 16-Bit integers. To convert this range to a range of floats, the given value is linearly mapped. For this, a hard coded scale value is used. The result is an angle in the range of [0, 360). To convert the angles to a rotation matrix, we first roll, then pitch, then yaw (intrinsic). TODO recheck signed integer to angle range

Bone location values are given as offset direction from a parent bone. Combined with the parent_dist value in the bone info field and the parent bones frame location, one can calculate the bones frame location. Linear mapping is done the same way as with the bone orientation values to get the angle values from the range of integer to the range of floats. To convert the angles to a direction vector, we first pitch (latitude), then yaw (longitude).

Notes:

Frame independent bone information.