FBX file animation problem
Hi there,
As a noob I'm struggling to find a way for correctly setting the animation with the exporting of a fbx fila from 3ds max.
Lets start from the beginning. I have made a gun model and animate it. The animation sequence starts from frame 1 and finishes at frame 62 with a custom FPS of 10. I have to maintain this numbers with the exportation of the FBX if not the model in game doesn't work write at list not the animation.
In the exportation FBX plugin version 2013.1 I have set animation on with the baking option to start at 1 end 62 step 1. But after the exportation the animation gets elongated from 0 to 100.
Hope that I made myself clear enough, so somebody kind enough can help me.
Thanks in advance
As a noob I'm struggling to find a way for correctly setting the animation with the exporting of a fbx fila from 3ds max.
Lets start from the beginning. I have made a gun model and animate it. The animation sequence starts from frame 1 and finishes at frame 62 with a custom FPS of 10. I have to maintain this numbers with the exportation of the FBX if not the model in game doesn't work write at list not the animation.
In the exportation FBX plugin version 2013.1 I have set animation on with the baking option to start at 1 end 62 step 1. But after the exportation the animation gets elongated from 0 to 100.
Hope that I made myself clear enough, so somebody kind enough can help me.
Thanks in advance
Replies
1. Start your animation at frame 0.
2. Select all your objects and remove any keys set outside of your desired frame range.
3. Change your active time range to match your frame range as well.
4. Make sure objects you want to export are unhidden.
BTW, the bake option doesn't clip the sequence. For example if you have keys set from frames 0-100, and you bake frames 20-70. It will still export frames 0-100, but the frames between 20-70 will be resampled with your bake options. It's dumb, but that's how it works for me.
The framerate should be taken from your scene automatically.
I don't remember having to do all these steps in older versions of the FBX plugin, but it's what I do now and it works.
Solved the issiew with correcting the time space in blender after importing the animated file from 3DS max.
I'm exporting a camera via script to different files with different frame ranges (for example, camera01.fbx is frame 0-10, camera02.fbx is frame 10-30 etc.).
However since the animation is not necessarily keyed on these precise frames (I have a key on frame 8 and a key on frame 12), if I delete the frames outside the export range then I will actually lose animation data.
Obviously I can bake these keys per-frame internally before deleting keys outside the frame range, but this seems insane and pointless, especially since it's meant to handle that inside the FBX exporter...
I did some investigation into this issue in the past and I think it might be workaroundable by using a different controller type on the rotation controller of the animated objects, but I guess this is a bug/oversight in the FBX exporter itself.
I haven't seen any threads around the Area or FBX forums indicating this issue so I guess I will have to talk to Autodesk to try and get a fix for it. I shouldn't have to work around their broken implementation with my own time-consuming hacks
Basically necro-posting here in the hopes that someone else has managed to solve this issue in secret...? :P
It also saves all animation even when specifying a range, even with keys at the start/end of the range, its like it completely ignores the range specification and exports whatever is there. We have to set bookend keys, and delete any animation that is outside the specified range in order to get the actual range. This happens when saving out .bip files from biped also, so I'm not sure if its actually FBX or if max is just broken.
We also run into all kinds of FBX preset saving and loading issues. It seems to save and load preferences in slightly different places from version to version and will even reference preferences for older versions OVER newer, and it tends to just go with whatever was saved last. Forget about defining preferences while exporting, that seems completely broken. It's a weird delicate balance that is really hard to maintain.
As a result we've stopped using FBX until they get their act together.
I think they've forgotten about it or let its development lapse and they've focused on their "Send to..." buttons but aren't those based on FBX? I don't have a need to send to software we don't have but I do have a need for a functioning FBX imp/exp.
I have our animation exporter automatically create a dummy skeleton and constrain to the bones that are selected, exports only the dummies, then deletes itself after export. That way I don't have to worry about rigging every little bone. I can share parts of the code if you like.
In your case I would create another camera, constrain it to the original, and then rename the original to "Controller Camera". Then export. If you are exporting to Unreal, in the Editor you'll still need to crop the beginning of the time for the animations that don't start on frame 0.
Yeah we stopped using presets and I explicitly set every option with MaxScript before each export. That and the dummy skeleton mention above all happens when hitting the "Export" button. So it's pretty painless for me now.
@McGreed,
I know it's an old question, but it's good to bake and resample animation because many games engines will simply read the key frame time and value but ignore the tangents. Terrible game engines only support linear interpolation. It's best to bake and resample and then use compression and/or key reduction in game. You'll get more fidelity in your animation, with the minor cost of using a little more memory. I don't recommend baking if your game engine doesn't have compression or reduction features.
Yep, that's exactly what we're doing here now too (presumably for the same reasons).
I was actually using hold/fetch to reset the scene state after export instead of just deleting, but doing that uncovered a whole host of bugs in Max 2012 (e.g. a 100% crash if you have a textured dx shader active during hold/fetch), so we're probably going to go for something more like you describe in the end anyway.
Cheers for the offer of code, we're mostly done with our implementation though so I think it'll be ok for now
Seems so silly that we still have to resort to these steps though, from my searching today it's clear that this bug ("feature"?) has been around for at least 4 years, which is pretty poor IMHO.