[Max] [unity] Compressing FBX animation data

We are heading into alpha and the leads have suddenly identified our skinned mesh animations as “too big”

Or pipeline is 3DS Max -> FBX ->unity. Animation data is baked into the deformation bones form Ik rigs.
Unity Rigs are Generic not Humanoid. Each character has Separate skinned mesh and animations combined by code into a single FBX

I’ve looked at unity’s compression settings and gotten a small win choosing “optimal” over “keyframe reduction” on the Import settings.
I’ve been asked to find approaches to optimize the FBX data before it gets to unity.

In Max Script, I’m using FBXExporterSetParam “FilterKeyReducer” True
but there are many key reduction options on the exporter dialog that have no parameter documented
Has anyone had success goingdeeper into FBX optimizing in MXS?

are there any 3rd party FBX animation compressing utilities out there?

and finally: I am intuitively rather skeptical that pre-optimizing an FBX before unity will gain anything over unity’s own internal compression. It’s likely to use the same approach as other methods.

Any thoughts or suggestions will be welcome

Animation compression is a big can of worms. The ‘right’ answer varies a lot by the kind of data too.

If you export your fbx’s in the text form you can actually see how oversampled the data is (it’s going to depend on a lot of things). if something like two linearly imported keys 30 frames apart is producing 30 keys you have a lot of room for savings: check to see if your FBX is stripping out constant keys (“Constant key reducer” in maya, don’t know the Max UI name) . If you have ‘bake animation’ (again, dunno the Max name) turned on you’ll be generating lots of redundant keys, that’s a good place to look for savings. If you need the baked keys you can try resampling at longer intervals: going from 1 key per frame to 1 key per 2 frames is a big savings – but if your source data is noisy (like mocap) you’ll have a tough time downsampling without artifacts.

If the models are split up you might see if you can use very aggressive sampling on the leaf nodes (fingers and toes, for example) and less aggressive on the root. Generally the closer a bone is to the root of the hierarchy the more sensitive it is to compression.

I tried baking every 2 ,every 3 (even every 10!) frames
And while the fbx files did shrink in filesize
Actually the end result in terms of the memory footprint in unity
was not drastic, about 1K per clip, even between baking every 3rd and every 10th.

I’m concluding that arbitrarily baking every nth key frame is not much improvement over unity’s own internal compression.
And the risk of compromising animation seems to make it not worth it.

I take the previous post back!

We scrutinized our animations in unity’s animation window and found that untiy fails to optimize linear position keys in several cases:

the neck is part of the hierarchy and needs no position keys, the curve is a straight line…but unity is not optimizing it!

Update: one of our programmers whipped up some C# code to eliminate the flat linear keys as part of our processing.
This yielded a ~50% drop in our key frame data.
It seems odd that unity would not optimize those position keys (like it does for similar scale keys)

But then again, how many sentences can YOU begin with “It seems odd that unity…”

Hi Mambo4:

On Never Alone, I concluded that baking down to every keyframe and automatically setting all tangents for animation to auto ensured the closest 1:1 appearance of animation in-game while having close to minimal performance impact. As far as compression went, we only turned keyframe reduction on for gameplay animations, and left cinematics untouched (completely baked every frame) for closest match to what we had originally animated and for other reasons related to how we anchor our characters in-game.

However, this is for Humanoid Rigs. When using Mechanim Generic, which we did for the fox, we noticed that the performance taken up by the Animator component was actually significantly less (which is probably because there is no need for retargeting to occur with the runtime Mechanim rig, and we weren’t using IK either).

I’m not an expert on this, and obviously every game is different (NA only has a maximum of maybe 3 characters on screen at any one time so we could afford a lot more joints as well per character), but I hope that information is useful.

As far as documentation of the FBXExport commands go, you can refer here for a more detailed explanation of the params. This is for Maya, but they all use the same FBX SDK for exporting and essentially the commands are all the same.

I hope that helps!