Question Editing legacy animation extracted from FBX balloons file size

I have an FBX that includes animation. I must use the Legacy Rig type (this requirement is beyond my control). I need to edit animation curves, which legacy animation doesn't support (as far as I know). To do this, I have to roll out my FBX in the Project view, select the animation, and duplicate it, to create a write-able copy of the animation in my Unity project, in the form of a *.anim file.

If I make any edit to the extracted .anim file, even if it's something very small like moving a single keyframe, the .anim file size balloons, like 4x - 20x the size of the un-edited .anim file. Does anyone know if there's a way to prevent this?

An acceptable workaround would be if there's a way to edit curves of an animation within an FBX, with Rig type set to Legacy, but as far as I know that's not possible. I suppose this huge file size would also be acceptable if anyone can guarantee that it does not impact the file size of a build for the end user.

I have used various mesh compression settings and animation compression settings in the FBX import settings. Higher compression does result in smaller file size when I extract the .anim file. But the file size still balloon once I make any edits. What I edit or how much I edit doesn't seem to matter - the file size always jumps to (nearly) the same size (within maybe 0.1%).

In case anyone is trying to reproduce this, the reported file size in Windows does not actually update until/unless I close the Animation window in Unity AND click "Save project." (Or quit Unity, presumably).

Thank you!

 

Someone suggested diffing the before-edits vs after-edits versions. Looking at the text, there are many additional entries in the after-edits version, even if only one small change has been made. I'm testing on an example super simple animation but that was not actually showing the file size difference. Will look into more to determine what is causing it and post more.

 

In case anyone finds this in the future, I was not able to determine exactly what gets added to the separate .anim file or why, but I'm not going to continue looking into it. I am using asset bundles and the file size of the .anim file seems not to affect the size of the asset bundle. For example if I extract an anim file from an FBX and edit some of the curves, this makes the anim file many times bigger, but the file size of the asset bundle is only very slightly larger than the size using the animation embedded in the FBX.

 

Unity is able to compress animations only if they come in fbx form. .anim files always remain uncompressed.

It’s pretty stupid, but hey, that’s just Unity.

 

Good to know, thank you!

 

I've noticed that some fbx's come in with key frames applied to every single frame of the animation (probably due to bad animation practice, or export options in max/maya etc...) ... if unity compression or optimization is on... it can probably compress/optimize or remove these extra redundant keys... but if you strip it from the fbx, unity then does not optimize it and you are left with keys on every single frame. Possible solution here is to look at your source animation and make sure the key frames make sense, and are not keyed on every frame, only where they need to be, then they won't bloat too much. certainly not 20x

 

I wonder if unity compresses or optimizes them automatically at build time... would be good to know.

 

It doesn’t.

Keys every frame are required some times if you use any form of more advanced curves or any convenience your DCC affords you (as you should). It’s baking down any advanced stuff you might have done, to dumb keyframe every frame so Unity doesn’t have to do anything complicated.

The workflow of baking to every frame and then compressing in the engine is fine (although Unity’s compression is pretty meh), I have no idea why compressing .anim animations is not an option, because that’s pretty silly.

But as I said, that’s Unity.

 

yep, I'm trying to figure out why a simple animation is >1mb when it should be in the few KB range... this is why. there is way to much curve information stored in the .anm file. I don't need it... but can't get rid of it.