has anyone had success with getting a skinned animation out with proper clip lengths? There was a solution a while ago on this thread, but I have found the results to be inconsistent, and animating using character key sets has some limitations when animating with an IK rig. My animations export and play fine, but the clip length runs into infinity. I know you can hard code the duration in, but both of these options are far from ideal. Any ideas? Alexandre Jean Claude?

Sorry for reviving an old thread but this was really bugging me and I might have found something.

I think the only thing driving the clip duration is the "duration" of the animation of the last null under DeformerRoot in the .xsi file. In my example, skel_neck was the last null so I was able to remove/modify all other params in the clip (editing the file manually) without affecting the duration. Any modification to skel_neck would change the clip duration.

Now I'm stuck in a situation similar to Hiro's. I want to do separate lower/upper body animations, but the only way to be certain the clip duration will be accurate is animating the entire rig in all clips...

I know it's not ideal, but it has worked very well for me. I basically have set up a naming convention. So Run_Loop_60 means the animation's name is Run, it is looping, and it is 60 frames. I just parse out the values of the animation's name when I load content. The largest "hack" is that I know my XSI workspace is running at 29.97 fps, or every 1 second is made of 29.97 frames. Given this information a little math against the frame count that I got from the parse gives me the duration in seconds and milliseconds. Below is my loader code. Hope this helps.

 

 

Using an fps to gauge seconds is really not that useful. You should use something like gameTime.TotalRealTime.TotalMilliseconds and just subtract your time from last update to find your current offset. Best practice is to never even think about frames per second when you are coding otherwise your game isn't going to be consistent across different hardware.

script kiddie:

Using an fps to gauge seconds is really not that useful. You should use something like gameTime.TotalRealTime.TotalMilliseconds and just subtract your time from last update to find your current offset. Best practice is to never even think about frames per second when you are coding otherwise your game isn't going to be consistent across different hardware.

You are correct when it comes down to actually animating your model within XNA, what I am talking about is calculating the correct duration value for the animation at load time. "gameTime.TotalRealTime.TotalMilliseconds" is not available to you durring the content loading period. The 29.97 that I got was based on the fixed fps that ModTool used to play back my animations internally. This method still provides consitent animations at different framerates since that is all handled in the update phase, all my code does is set the duration value for the animation so looping works properly and you can tell if an animation has completed by checking the animation's play time against the animation's duration.

Oh I get it. That seems pretty useful after all. Good job then.