This is an old revision of the document!

The GLM and GLA formats are defined in the renderer/mdx_format.h file included in the JK2 SDK. (Not in the JKA SDK though.)


Bone References

The Structure of the bone references and its meaning is not explained in mdx_format.h. It should look somewhat like this:

typedef struct
	int boneReferences[1];		// variable sized (mdxmSurface_t->numBoneReferences)
} mdxmBoneReferences_t;

It's an array of bone indices. The vertices only use 5 bits to store the bone indices and can thus only address 32 bones. There can be more than 32 bones per model and the boneReferences are the “dictionary” to translate the 5 bit indices back to the “real” indices. A bone index of n in a vertex means: Actually use the bone index stored at index n in the boneReferences array. This implies a 32 bones per surface limit.

Interpreting Tags

Tags are surfaces that are interpreted as position/rotation information. Usually, they consist of 3 vertices and 1 triangle. There can be more, but less won't work - even though the triangle's order is not actually used, it has to exist.

Let v0 be the position of the vertex with index 0, v1 the position of the vertex with index 1 and v2 the position of the vertex with index 2.

Then the X+ axis is v0-v2, Y+ is v1-v2. In Raven models, the X Axis is the short side (leg) of the triangle, the Y axis the long one.


Compressed Bone Pool

Despite anything mdx_format.h might claim, the contents of the bone pool are not of type mdxaCompBone_t but mdxaCompQuatBone_t - probably because 14 bytes is a lot smaller than 24 bytes, especially when there's 80.000 of them like in _humanoid.gla.

The content of the compressed bone pool are the offsets of each bone, relative to its relative base position. So in order to get the absolute position of a bone, you have to walk down the hierarchy and combine the relative offsets to get the absolute offset, which you can then add to the bone's basePose. But when rendering you only want to know the absolute offset of each vertex, which is probably why they save it this way.

If there's a fScale in the header, you also have to take that into account.

fileformats/ghoul2.1321121641.txt.gz · Last modified: 2011/11/12 19:14 by mrwonko
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki