Finally getting down to brass tacks...
I'm finally starting to get some real scenes to work with. And my animation tools are getting a trial by fire.
What I found out: Reality is always different from the test cases.
First, the skeleton fbx files that I'm getting have joints differently named from the standard, with two characters in the scene. One character will have joints named with a suffix like ...J_1 instead of ...J. The tools were set up to look for _J, and when they're differently named, that a problem.
Second, those suffixes weren't always consistent within the character. The ball of the foot and toe would sometimes be just _J where the rest of the character had J_1. So with two characters in the scene, one would have J_1 for everything and one would have J_2, but their toes and balls of the feet would be _J and J_1 respectively. Pain in the butt.
Third, my method for loading a saved animation file saved under one character name or reference to another that might be referenced or not, or dissimilarly named joints or controls, required hand matching from the name used in the file to each joint or control in a character. There are a lot of controls and joints in characters. This would take a long time in practice even though I'd only have to do it once. It turns out that there is no luxury of time unless I want to put in a lot of OT to get things done, and I sometimes have minutes instead of hours to do things.
Fourth, one method I had for handling conversion of mocap data to a fully rigged IK character worked, but when I'd try to save the referenced file would crash Maya as soon as I'd go to save the scene.
Fifth, that method required separating the characters from the converted fbx scene into individual characters. This turned out to be time consuming also.
So I needed to make tools a one stop affair.
I created a new tool which would save the exact spacial location, regardless of hierarchy, of the IK character's driver transforms and rotation order. This could be used to convert the data from the mocap characters, even if they were based on a different skeletal setup and hierarchy. This file fits into my .sganm file format (which currently has three different versions that are automatically detected: ANIMATION which saves all of the keyframe data including tangents, tanget type, tangent weight, and infinity and is hierarchy dependent; MOCAP, which is just the raw keyframe number, and keyframe value for each channel and is still hierarchical; and a spatial location format that just puts everthing exactly where it is in the animation file in world space, which is non hierarchical but has to be implemented in hierarchical order or it results in a transporter accident. In otherwords, I already had a tool that could be deployed to store the data from the new rig. I save this in the master folder that contains the character's old mocap rig, new mocap rig and the IK character that has all the controls installed.
In order for all this to work, the two skeletons have to be aligned on frame zero in the hero pose. The same code that's used for the translation from one older state to a newer one, or joint based animation to control based IK animation, is also used to create a master "zero frame" hero pose file. This is also stored in the master directory.
I wrote a tool for automatic creation of a "map" file. This would use TD defined wildcards to match similarly named joints and controls to the one used in the animation file. Whether that file is a "zero frame" hero file, or a control location file. This worked great until I found the joint naming inconsistency.
So I need to create a "descendants" based system that looks for matches regardless of the added delimiters and indexing based on the selected character name. I have bits and pieces of the code in use for other purposes, so it should be too difficult to implement.
On top of all that, even if I get it all working smoothly, there's still the problem of the manual handling of the various steps in the conversion process. What's needed is yet another file format, this one being a "Rosetta Stone" so to speak, for all the characters that have that control space file and "zero frame" file already saved in the master directory. That way, I could load an fbx scene, select the characters in that scene from a list, and it would automatically set a zero frame, load the appropriate reference file for each character, and map the animation to the character with controls with a "one button push" and could be used by anyone, rather than having to have it done by a TD.
There are a lot of details to making a system like that work. But I figure it could take a half hour of hand messaging and turn it into maybe five minutes. Which would be good since there are 1400 shots.
The reason all this is necessary, is that Motion Builder doesn't handle the complex rigs with all their constraints and esoteric expressions, at least not the versions we're using in production. The rigs also can overload hand animation over the mocap, and have space switching capabilities, and MB can't handle those either, and you can't apply the motion directly to the joints because of the IK, so conversion is an absolute necessity.
What I found out: Reality is always different from the test cases.
First, the skeleton fbx files that I'm getting have joints differently named from the standard, with two characters in the scene. One character will have joints named with a suffix like ...J_1 instead of ...J. The tools were set up to look for _J, and when they're differently named, that a problem.
Second, those suffixes weren't always consistent within the character. The ball of the foot and toe would sometimes be just _J where the rest of the character had J_1. So with two characters in the scene, one would have J_1 for everything and one would have J_2, but their toes and balls of the feet would be _J and J_1 respectively. Pain in the butt.
Third, my method for loading a saved animation file saved under one character name or reference to another that might be referenced or not, or dissimilarly named joints or controls, required hand matching from the name used in the file to each joint or control in a character. There are a lot of controls and joints in characters. This would take a long time in practice even though I'd only have to do it once. It turns out that there is no luxury of time unless I want to put in a lot of OT to get things done, and I sometimes have minutes instead of hours to do things.
Fourth, one method I had for handling conversion of mocap data to a fully rigged IK character worked, but when I'd try to save the referenced file would crash Maya as soon as I'd go to save the scene.
Fifth, that method required separating the characters from the converted fbx scene into individual characters. This turned out to be time consuming also.
So I needed to make tools a one stop affair.
I created a new tool which would save the exact spacial location, regardless of hierarchy, of the IK character's driver transforms and rotation order. This could be used to convert the data from the mocap characters, even if they were based on a different skeletal setup and hierarchy. This file fits into my .sganm file format (which currently has three different versions that are automatically detected: ANIMATION which saves all of the keyframe data including tangents, tanget type, tangent weight, and infinity and is hierarchy dependent; MOCAP, which is just the raw keyframe number, and keyframe value for each channel and is still hierarchical; and a spatial location format that just puts everthing exactly where it is in the animation file in world space, which is non hierarchical but has to be implemented in hierarchical order or it results in a transporter accident. In otherwords, I already had a tool that could be deployed to store the data from the new rig. I save this in the master folder that contains the character's old mocap rig, new mocap rig and the IK character that has all the controls installed.
In order for all this to work, the two skeletons have to be aligned on frame zero in the hero pose. The same code that's used for the translation from one older state to a newer one, or joint based animation to control based IK animation, is also used to create a master "zero frame" hero pose file. This is also stored in the master directory.
I wrote a tool for automatic creation of a "map" file. This would use TD defined wildcards to match similarly named joints and controls to the one used in the animation file. Whether that file is a "zero frame" hero file, or a control location file. This worked great until I found the joint naming inconsistency.
So I need to create a "descendants" based system that looks for matches regardless of the added delimiters and indexing based on the selected character name. I have bits and pieces of the code in use for other purposes, so it should be too difficult to implement.
On top of all that, even if I get it all working smoothly, there's still the problem of the manual handling of the various steps in the conversion process. What's needed is yet another file format, this one being a "Rosetta Stone" so to speak, for all the characters that have that control space file and "zero frame" file already saved in the master directory. That way, I could load an fbx scene, select the characters in that scene from a list, and it would automatically set a zero frame, load the appropriate reference file for each character, and map the animation to the character with controls with a "one button push" and could be used by anyone, rather than having to have it done by a TD.
There are a lot of details to making a system like that work. But I figure it could take a half hour of hand messaging and turn it into maybe five minutes. Which would be good since there are 1400 shots.
The reason all this is necessary, is that Motion Builder doesn't handle the complex rigs with all their constraints and esoteric expressions, at least not the versions we're using in production. The rigs also can overload hand animation over the mocap, and have space switching capabilities, and MB can't handle those either, and you can't apply the motion directly to the joints because of the IK, so conversion is an absolute necessity.
posted by Stephen Greenberg at 10:32 AM
0 Comments:
Post a Comment
<< Home