GLA file format specification...

[npauerk]

Nope, I don't have it, but I was wondering if any coders here would be interested in researching Raven's cryptic animation format. I don't actually know if the GLA format is a binary or ASCII text format, but I'm assuming ASCII. As of right now, Raven has provided nothing that will allow editors to export new animations to their proprietary format, and I'm itching to do something about it. But this isn't the kind of project that I really want to take on alone, so any help would be appreciated.

 

UPDATE

 

Okay so it was a bad idea. I realized my mistake when I got home last night. The GLA format is indeed binary. The only other thing I can think of that will allow us to understand the format better is to see how the code implements it. The only problem is that Raven has done a very good job of hiding anything and everything related to the implementation of Ghoul2.

[normal]

The files are not in ASCII.

 

That's all I know right now. Other than the 3-4 byte header.

 

 

[TheSnerd]

Already from your first guess being the format ascii I tend to think that you have never done something like that before - it takes a lot of time and trial & error to get a decent description of the file format... I got other things to do

[BoBo_Fett]

The header file is in the SDK.

from mdx_format.h:

 

// mdxaHeader_t - this contains the header for the file, with sanity checking and version checking, plus number of lod's to be expected

//

typedef struct {

//

// ( first 3 fields are same format as MD3/MDR so we can apply easy model-format-type checks )

//

int ident; // "IDP3" = MD3, "RDM5" = MDR, "2LGA"(GL2 Anim) = MDXA

int version; // 1,2,3 etc as per format revision

//

char name[MAX_QPATH]; // GLA name (eg "skeletons/marine") // note: extension missing

float fScale; // will be zero if build before this field was defined, else scale it was built with

 

// frames and bones are shared by all levels of detail

//

int numFrames;

int ofsFrames; // points at mdxaFrame_t array

int numBones; // (no offset to these since they're inside the frames array)

int ofsCompBonePool; // offset to global compressed-bone pool that all frames use

int ofsSkel; // offset to mdxaSkel_t info

 

int ofsEnd; // EOF, which of course gives overall file size

 

} mdxaHeader_t;

 

 

// for each bone... (doesn't actually need a struct for this, just makes source clearer)

// {

typedef struct

{

int offsets[1]; // variable sized (mdxaHeader_t->numBones), each offset points to an mdxaSkel_t below

} mdxaSkelOffsets_t;

// }

 

 

 

// for each bone... (mdxaHeader_t->numBones)

// {

// mdxaSkel_t - contains hierarchical info only...

 

typedef struct {

char name[MAX_QPATH]; // name of bone

unsigned int flags;

int parent; // index of bone that is parent to this one, -1 = NULL/root

mdxaBone_t BasePoseMat; // base pose

mdxaBone_t BasePoseMatInv; // inverse, to save run-time calc

int numChildren; // number of children bones

int children[1]; // [mdxaSkel_t->numChildren] (variable sized)

} mdxaSkel_t; // struct size = (int)( &((mdxaSkel_t *)0)->children[ mdxaSkel_t->numChildren ] );

// }

 

 

// (offset @ mdxaHeader_t->ofsFrames)

//

// array of 3 byte indices here (hey, 25% saving over 4-byte really adds up)...

//

//

// access as follows to get the index for a given <iFrameNum, iBoneNum>

//

// (iFrameNum * mdxaHeader_t->numBones * 3) + (iBoneNum * 3)

//

// then read the int at that location and AND it with 0x00FFFFFF. I use the struct below simply for easy searches

typedef struct

{

int iIndex; // this struct for pointing purposes, need to and with 0x00FFFFFF to be meaningful

} mdxaIndex_t;

//

// (note that there's then an alignement-pad here to get the next struct back onto 32-bit alignement)

//

// this index then points into the following...

 

 

// Compressed-bone pool that all frames use (mdxaHeader_t->ofsCompBonePool) (defined at end because size unknown until end)

// for each bone in pool (unknown number, no actual total stored at the moment)...

// {

// mdxaCompBone_t (defined at file top because of struct dependancy)

// }