I am writing an importer for the assets of a game I once wrote in Leadworks (e.g. the gmf file format). For static meshes everything works fine, however for animated meshes I have some problems.
The biggest problem is that I cannot find what the definition is for the bind transform of a bone and the transform that defines an animation key.
I can see two possibilities for these transforms, but maybe there are more, so any help would be appreciated :
The transform is a rotation (the quaternion) followed by a translation.
The transform is a translation back to the origin, then a rotation (quaternion), followed by the negative of the translation to place the vertex back at the required position. In other words the rotation uses the translation component as origin.
If I’m succesful in porting this format, I might add additional formats that import animation.
I don’t quite understand on which side you have the problems, on the jme3 side or on the gmf format side? For the jme3 side, you can look at the Ogre importer for some hints on how animation import works. Theres also tests for manual animation that give you an idea about the relations of bones etc.
The gmf format gives me a bone transform (that I read into a matrix4f) that positions the bone into model space. So, in principle this should correspond with the way jmonkey-engine does it, but I get distorted animations. So I want to verify that my understanding of the Quaternion + Translation definition in jmonkey is correct.
I used the CustomAnimation and ogre MeshLoader class as a guide to create a correct hierararchy, and I looked at the animation keys in the ogre skeleton file. However i think this code in Bone.java is where lies the rub :
Thanks for the answers so far. An other implicit assumption that I need to verify is that most character animation frameworks initially places a bone on the X-axis (gmf format does this too). Maybe this could be another cause of distortion?
By the way, I fully plan to share the source code of the importers I wrote, I also like the class design & architecture of JMonkeyEngine.
When you create the skeleton in an editor like blender its going to be in bind pose or T-pose. In jME3 the transforms you set via Bone.setBindTransform() are actually relative to that bone’s parent bone. When you create a Skeleton() from it, it automatically recomputes all the other needed data automatically.
@daenim said:
Yes, but the problem I have is that there are a lot of possibilities to define the Quaternion.
Is it a tangent frame with the Z-axis aligned with the bone ?
Is it the rotation that is needed to align a vector on the X-axis with the bone ?
Other possibilities ?
I don't think there's any requirements like that. As long as the animation keys and the bind transforms are handled in the same way.
You are quite right, the transforms just need to be consistent.
Thanks for all the help. In the meantime I implemented my own skinning solution inside JMonkeyEngine based on Matrix4f matrices instead of Quaternion + Translation, to ensure that there was not a problem in my rig + animation files.
I got my solution to work, now I just have to track down where my mistake is in the standard JMonkeyEngine animation framework.
@daenim said:
You are quite right, the transforms just need to be consistent.
Thanks for all the help. In the meantime I implemented my own skinning solution inside JMonkeyEngine based on Matrix4f matrices instead of Quaternion + Translation, to ensure that there was not a problem in my rig + animation files.
I got my solution to work, now I just have to track down where my mistake is in the standard JMonkeyEngine animation framework.
Just a small note, if you're planning on adding your importers as an official jMonkeyEngine SDK plugin, you have to use the official jME3 animation system. We cannot support any 3rd party animation systems due to fragmentation of the animation API.
@Momoko_Fan said:
Just a small note, if you're planning on adding your importers as an official jMonkeyEngine SDK plugin, you have to use the official jME3 animation system. We cannot support any 3rd party animation systems due to fragmentation of the animation API.
That is a sound strategy, I just needed to test if I did not make in mistake in the code that loads the bone-indices and boneweights. I hope to find the problem soon :)