Skip to main content
GameDev.net gamedev.net
🔒 Locked

Maya exporter problem

Started by eirland Feb 24, 2007 at 2:23 PM 5 replies 1.3k views
Original Post
eirland
eirland
I've recently been given a new model/animation from my artist. I've been wrestling with my exporter for about a day now trying to figure out why he won't animate correctly in-game. My animation system uses soft-skinned animation on the GPU and works totally fine for the first character that was given to me. Everything about this one looks right too - his joints display and animate correctly. His bind pose mesh/matrices look right. But as soon as I try to apply an animation to him he goes bonkers. This leads me to believe that my influences/weights are wrong. I'm pretty much out of ideas to try - does anyone know what could cause my influences/weights to be messed up?? thanks -erik
eirland
eirland
I noticed that above my skin I had a scale transform (in maya). Would this cause my animation to look messed up?
Hatori
Hatori
My advice is to look at the Ogre Maya exporter to see some examples of what they do. It is fairly stable and reliable. And no you won't of course be able to use their code as is... But by looking through the source you can learn about the process of extracting Maya animation data.

Anyways that is what I did and it saved me a big headache....
Hope this helps...
RobTheBloke
RobTheBloke
It's always good to add lots of validation to maya exporters since an awful lot can go wrong. In no certain order, things that can cause things to break are :

* The use of clusters and/or joint clusters (rigid skinning) to pull verts around
* modelling operations applied to meshes after they have been skinned (ie, subdivide, smooth, split polys etc). This would lead to skin weights for a mesh contained within the construction history, and not the final mesh.
* The use of scale within any of the bones (since you need to apply the inverse scale matrix to the character - see the docs for MFnTransform and MFnIkJoint to get descriptions of the maths required). You can bake this out during export, though it's easier to simply tell the animator/modeller/rigger off for doing it.
* Have you tried deleting non-deformer history from the model before export?
* Check the transform of the mesh as well. I take it you are applying the matrix to the skin?

Other than that, i can't be of any real use unless you actually give a lot more information on the problem (screenshots of the DG and your app would be good).
eirland
eirland
Quote:
Original post by RobTheBloked
* modelling operations applied to meshes after they have been skinned (ie, subdivide, smooth, split polys etc). This would lead to skin weights for a mesh contained within the construction history, and not the final mesh.

Does this include triangulate?

Quote:

* The use of scale within any of the bones (since you need to apply the inverse scale matrix to the character - see the docs for MFnTransform and MFnIkJoint to get descriptions of the maths required). You can bake this out during export, though it's easier to simply tell the animator/modeller/rigger off for doing it.

This might be my problem. I'm exporting the keyframe transforms using the technique described in the docs. I get all the scale, rotation, translation, joint orient matrices as well as the inverse of the parent's scale matrix and I'm multiplying them in the order specified in the docs... Do I need to do this for the bind pose transforms as well??

Quote:
* Have you tried deleting non-deformer history from the model before export?

I tried putting the character in the bind pose and going to skin->Edit Smooth Skin->Delete non-skin history. It didn't work. Also, I just tried this again and it seriously messed up my character. Even Maya can't animate him correctly after doing that.


Quote:

* Check the transform of the mesh as well. I take it you are applying the matrix to the skin?

The artist put a scale transform above the mesh. I tried taking it out and exporting but it didn't help. Should I be getting the transform and applying it to each vert on export?

Quote:

Other than that, i can't be of any real use unless you actually give a lot more information on the problem (screenshots of the DG and your app would be good).

There's nothing in the DG but the joints and the mesh. As for the SS's I'll see what I can do. Thank you for your help, this is the first time I've written an exporter/animation system and I really appreciate the help.
RobTheBloke
RobTheBloke
Quote:
Original post by eirland
Quote:
Original post by RobTheBloked
* modelling operations applied to meshes after they have been skinned (ie, subdivide, smooth, split polys etc). This would lead to skin weights for a mesh contained within the construction history, and not the final mesh.

Does this include triangulate?


nope - that only affects the indices, not the actual number of vertices in the mesh. You can grab a triangulated version though if you use MItMeshFace::getTriangle and MItMeshFace::numTriangles. The advantage of that is that it doesn't mess up your face normals (try creating a polyCube then triangulating - you should see what i mean about the normals). (by the way, you can ignore the returned MPointArray since it's the indices you really want. A bit of messing around should get it to work fairly reliably).

Quote:
Original post by eirland
This might be my problem. I'm exporting the keyframe transforms using the technique described in the docs. I get all the scale, rotation, translation, joint orient matrices as well as the inverse of the parent's scale matrix and I'm multiplying them in the order specified in the docs... Do I need to do this for the bind pose transforms as well??


The bind pose can be a pain to locate in an exporter if you have IK, constraints or expressions driving the transforms. In your exporter, make sure you disable those prior to exporting the bind pose. Also, you can query the bindPose matrix attribute of joints if needed (doesn't work if you have added an influence object into the mesh though since that attr does not exist on the transform node types). Make sure you get the attribute value as an MObject, then pass it into MFnMatrixAttribute to actually grab that attribute as an MMatrix.

As for extracting anim data, the easiest (and most reliable way) is to simply use the MDagPath::inclusiveMatrix funcs, ie :

MDagPath path = someJoint;MDagPath parent = path;parent.pop();MMatrix local_space = path.inclusiveMatrix() * parent.inclusiveMatrixInverse();MVector xAxis( local_space[0][0],local_space[0][1],local_space[0][2]);MVector yAxis( local_space[1][0],local_space[1][1],local_space[1][2]);MVector zAxis( local_space[2][0],local_space[2][1],local_space[2][2]);MVector translate( local_space[3][0],local_space[3][1],local_space[3][2]);MVector scale( xAxis.length(), yAxis.length(), zAxis.length() );MQuaternion rotate = local_space;


That will handily remove all of the orients for you, though you'll still need to worry about the scale (unless you bake it out). And in general, it's also a very good idea to export the main model (in it's bind pose) seperatly from all of the anim cycles.

Quote:

The artist put a scale transform above the mesh. I tried taking it out and exporting but it didn't help. Should I be getting the transform and applying it to each vert on export?


It's certainly a fairly good idea to do that yes. (or at least, it makes life slightly simpler). Grab the matrix from the meshes MDagPath::inclusiveMatrix() func. The problem with scale though comes when the entire character is grouped (bone's 'n' all).

In general a few rules for the animators is a damn good idea (ie, freeze xforms on the mesh before skinning. Freeze scale from the joints before skinning - using the freeze transforms options box). Then in general the scale problem vanishes and then you can just grab the rotation and translation from the MDagPaths and it all becomes trivial.
eirland
eirland
Thank you very much for your help. The problem was the scale transform above the mesh. The artist took it out (through some crazy process) and the character works fine now.

Thanks,
erik

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.