Using asset importer I was able to make a model file converter to a custom format for my engine. I can take various formats like Md5, Collada, etc and convert them to my format. The animation video shows some Doom 3 Md5 models converted to load with my engine.
You can download the code on GitHub
Here are the formats for the files as requested.
This is the mesh data file. It's in a nice conventient format to read directly into the VBO and IBO of your application. It's also in ASCII format similar to md5 because it's easier to store float values. Here's the format description:
First comes the magic string at the top of the file:
Load this in first and make sure this is the string at the top. If not, the mesh file is probably invalid or a newer version of the illmesh format.
After that comes a set of booleans saying whether or not the mesh contains certain data. If it does, make sure your application accounts for that.
Then the number of verteces in the Vertex Buffer Object and number of indices in the Index Buffer Object. Use these numbers to allocate the needed memory.
The next block just contains the VBO data to read in. It's important to know the order of the data. The data is interleaved to improve Vertex Shader Cache performance and all that technical stuff. I'd recommend you keep your application's VBO in the same format.
So if blend data is present for skinning, each vertex allows itself to be affected by up to 4 bones. This is all you'll need in most cases. Doom 3 models typically have up to 2 bones affecting each vertex on average. The bone index corresponds to the bone index in the skeleton that will be described later. The blend weight is how much the corresponding bone's transform relative to the bind pose affects this vertex. The blend weights should all be normalized or else strange results will happen. The nice thing about this format is that no bones or skinning are necessary to render the mesh even if there is blend data. It'll just be in its bind pose.
After this comes the Vertex Index Array. As mentioned earlier, every 3 indices makes up a triangle. This data can go directly into the index buffer object.
This is the skeleton file. The indices of the bones in here should correspond to bone indices in the vertex buffer object of the mesh.
First comes the magic string at the top of the file just like with the mesh file. Make sure this is the first string to make sure the file is correct.
Next comes the number of bones.
Next come all of the 4x4 matrices that make up the bind pose for each bone in row major order. (I think) Just make sure the for loop that reads it is in this form if reading into a glm::mat4.
After that comes the bone heirarchy.
After that come the bone names which are needed to cross reference which bone is animated from the animation file. Bone names are also really useful for controlling certain things in the game itself, like attaching props that characters hold in their hands.
This is the animation file.
First comes the magic string at the top of the file just like with the mesh file. Make sure this is the first string to make sure the file is correct.
Then come the frame rate, number of frames, and number of animated bones in this file. The number of bones animated may not necessarily correspond to the number of bones in the skeleton. Use the bone names to reference the correct bone in the skeleton.
Then come the keyframes for each bone in the form of the position, quaternion, and scale. These are the absolute transforms, not the transforms relative to the bind pose. They are still transforms relative to the parent though so you still need to traverse the bone heirarchy.
Interpolate these in between the keyframes to get smooth animations. Then create the final transform by applying them in this order: position * rotation * scale.