MD5Importer and Bip/character models


I am using Neaktor's MD5Importer to load .md5mesh and .md5anim files of characters. I am using the character data from Max Payne 2, converted first to MilkShape 3D and then to MD5MESH using Unwrap 3D. Both the models and animations display fine in those two programs.

When I load a mesh in to a JME program with the MD5Importer, however, I notice two important things:

  1. The models are not aligned to 0, 0, 0, as they are in both editing programs. In particular, they appear offset by about 1 metre (unit), so appear embedded in the floor of the room I put them in (which in turn is centred at the origin).

    I can 'fix' this by setting the local coordinate of the model up in the air a bit, but this doesn't feel right as a permanent fix, and I notice that if I use the same model in a PhysicsGameState as a dynamic node, then it falls right into the floor again.

  2. I notice that the character animation applied to such a mesh, although looking generally right, is subtly different to how it appears in either editing application. In particular, the models seem to 'sway' about slightly, whereas in the other programs, they seem to have their feet planted on the ground.

    I think both issues relate to the way the importer handles the .md5mesh and .md5anim files for my models. Here is an excerpt of my .md5mesh file

    numJoints 89

    numMeshes 6

    joints {

    "Bip01" -1 ( -0.000000 0.000001 0.944276 ) ( 0.707107 -0.707106 0.000000 )

    "Bip01_Footsteps" 0 ( -0.000000 0.000001 1.000080 ) ( 1.000000 0.000001 0.000000 )

    "Bip01_Pelvis" 0 ( -0.000000 0.005021 0.944276 ) ( 0.707107 -0.000000 0.707107 )

    "Bip01_Spine" 2 ( -0.000000 0.005183 1.043023 ) ( -0.706685 -0.024397 -0.706686 )

    "Bip01_Spine1" 3 ( -0.000000 0.019417 1.246637 ) ( -0.707049 -0.008975 -0.707050

    I think the reason may lie in the fact that the root note (Bip01) has two progeny, both _Footsteps and _Pelvis (I think this idea is found in many character/skeletal based 3D games), and the importer must be doing something slightly different to the importers in MilkShape and Unwrap. I also notice that Bip01_Footsteps doesn't seem to be a parent of any other joint.

    I know that I could tinker with the data file, but you have to remember that in the other two programs I view the model in, it does appear at the origin/not embedded in the floor.

    Please could Neaktor or anyone who has come across this or related problems offer some help?

    Thank you very much indeed,


if remember correctly (long time no max 8) ) bips didn't work that well for md5 with any of the known exporters without a bit of tweaking with derton's exporter u need to link the bip(center) to a regular max bone and name that bone "origin"


Thanks for this but I don't find that very helpful - remember that the models appear 'normally' in both Milkshape and Unwrap 3D, so what I am getting at is a difference in the way that JME/MD5Importer reads these files compared to these programs:

Unlike in the former two applications (where the model appears with it's feet standing over 0, 0, 0 and animating correctly) the same model/s in JME appears translated downwards about 1 metre and the animation is subtly different, as if there is an additional/erroneous rotation going on about the centre of the model (i.e. through the umbilicus). I am therefore searching for the underlying reason, e.g. the way the importer algorithm handles the Bip/bone structure I pasted into my previous mail.

Thank you for any help.

Heres one concern

Not sure if it is related

Just to let you know that it appears that I managed to fix it with a few alterations in the MD5Importer source.

  1. Was to update the MeshImporter so that as well as the orientation multiplication by base (the 'correcting' transform), I also mult the translation as well. This corrected the model when it was static (i.e. without a corresponding animation)
  2. The next change was in the animations part of the MD5Importer but I can't remember off hand what I did! If anyone is genuinely interested please email me, but it seems like no-one has come across this problem before.

    I am happy because my models are no longer embedded in the floor and move like they aren't defying gravity (that reminds me - must get them to work with some physics now!)


Good job. "base" is exactly the quaternion I was talking in my post. It should not be needed, accordingly to MD5 format specificataion: MD5 format conforms to OpenGL coordinates system. But, based on my latest experience, "base" is probably a way used by the old MD5 Reader (and neakor's MD5Importer is inspired by old MD5 Reader) to correct some unknown problem with the underlying framework, i.e. jME in this case.

I AM interested!!!

could you post the code? please