Unity 3.5 to 4.0 - Animations are no longer importing.

Unity Engine
1

I have a project in 3.5, I’ve recently upgraded to 4.0.

Everything in the animations data of the FBX files is no longer importing into Unity, no matter what settings I use. Unity is refusing to “see” the animation data in the model files.

My main character’s animations, which I converted over to a set of Unity Animations to allow attaching script events to the animation timelines, is working. These were originally imported and then converted using 3.5 before my upgrade, so the main character works fine. I’m going to have trouble if we need to add a new animation to him however.

Everything else in the game project has been using imported animations, because we are still at a stage where many new animations get added into the game later as the modelers finish them. None of these are working anymore. For example, my switch objects (which simply have two animations for being ON or OFF), will no longer play any animations.

After some poking around, I have determined the problem is with importing the animations. The list of animations in my game project(the list that shows up when assigning an animation in the inspector) only contains the main character’s animations. Everything else is gone!

I’ve tried Legacy animation mode, I’ve tried wiping the import settings and redoing all of them, and the result is all the same. Unity 4 is no longer seeing the FBX animations that version 3.5 reads in just fine.

For info, our asset pipeline is the following:

Blender > Make Armature Rigging in Blender > Export as FBX > Import FBX into Unity > Convert imported model into Prefab for the level editors to use

As I said above, this pipeline was working perfectly with 3.5, and is now broken in 4 because animations are not importing.

Here is the errors I’m getting when importing anything with animations:

In summary, it seems like something broke in the importing code of Unity 4 itself.

EDIT: Something DID break, but it’s not the importing code, it’s the project settings for every animated fbx object. See 2 posts below this one for the solution to getting everything working again.

2

EDIT: This error is happening because of a reason further down in my later post. Ignore this post.

Further trying to get it to work, if I double click the error to try to open the script involved, I get this error instead:

Right below it is this red fatal error:

Of course, the script itself doesn’t appear to exist anywhere for me to fix, because it’s in the temporary “BuildAgent/work/randomNumbersHere/Editor/Mono/ConsoleWindow.cs” path. The error is on line 482.

Without knowledge where the original file is I can’t fix this.

3

Found a way to get them working again…though it’s a long process and horridly time consuming.

The issue is that the importing animations settings on the fbx files do not have a “Source Take” setup for them.

In my case, since the FBX comes from blender, the files have two timelines to select from: “Default Take” and “ArmatureAction”.

The issue is that when Unity 4 converted the project, the Source Take drop down setting was set to nothing.

The “fix” is to set it to a proper animation take, in this case, “Default Take”, so that Unity can read the animation data instead of blowing up. I also needed to redefine the animation frames, so take notes of what the animation frame numbers are before selecting anything, as Unity will default the timeline reading to the entire timeline of the take once you select it.

The problem now is that I have to do this for every animation in the entire project. What makes it more annoying is that the animations will auto name themselves when the drop box is selected. Since a lot of my code relies on animations having certain names(to allow multiple enemies to use the same animation script, for example), this means a TON of work.

Furthermore, for every prefab that used to have the animations associated in their own settings, I now need to set their animations arrays up again. That means digging through all the animations that have been imported, and reconnecting them to every prefab.

This is quite a mess when multiple levels have some custom settings for scripts on the prefabs that need to be preserved for the levels to work, because I can’t just use the “revert to prefab” option to restore the animation arrays.

Nonetheless, so far this has managed to fix the problem. The rest of my afternoon is going to be spent doing this with all the models we’ve ever made for the project.

For future reference, it would be really nice if Unity defaulted to the first “Source Take” when converting old files, and then automatically reconnected the settings for animated prefabs using the old data of what animation was connected to it in 3.5. It instead currently wipes the animation array to null values(but remembers the length, which makes me question why it can’t just use that old data to recreate the animation setup in the first place).

If I didn’t have the importing inspector animation list for reference, I would have no way of recreating the animation clip arrays on the prefabs since I wouldn’t know the order nor the tags of the animation names without opening a bunch of script files.

Anyway, I hope this information helps anyone who has similar problems with animations not working after upgrading their project. Onward and upwards!

Edit: It appears in some cases that Unity 4 does update the prefab link assuming the new imported animation has the same exact name as the old one. I’m still not entirely clear why it doesn’t always work, but it seems Unity is at least trying to remember the links so long as you don’t mess with the prefabs and “reimport” the animations as described above.

4

Wait wait! If you can change it in script, don’t do that manually! Run a script to find all Animations in the project and set their take if it’s invalid. It’s a quick little for-loop! Here’s a snippet of my function to iterate over all assets of type T:

	private delegate void Callback<T>( T object );
public static T ProjectPicker<T>( T cur, Callback<T> callback ) where T : MonoBehaviour {
			string[] files = System.IO.Directory.GetFiles(Application.dataPath,"*.prefab", System.IO.SearchOption.AllDirectories);
			int pathlen = Application.dataPath.Length+1;
			int ix, pix, fix;
			GameObject go;
			string checkFile;
			
			for ( ix = files.Length; ix > 0; ix-- ) {
				if ( ix % 50 == 0 ) EditorUtility.DisplayProgressBar("GUI Utilities", "Finding objects...", (float)ix / (float)files.Length);
				checkFile = "Assets\\" + files[ix-1].Substring(pathlen);
				go = (GameObject)UnityEditor.AssetDatabase.LoadAssetAtPath( checkFile, typeof(GameObject) );
				if ( go.GetComponent(typeof(T)) ) {
					callback( go.GetComponent(typeof(T)) );

You’d make your Callback something like “if (anim.take == null) anim.take = default;”

You might need to drop the “where T : MonoBehaviour”; it was necessary for my specific use.

5

Too late. :stuck_out_tongue: Already zoned out and did them all by hand.

Thanks for sharing the script though. It should help others who have this import problem. :slight_smile:

It turns out that the setting “Default Take” doesn’t exist in the old version of Unity. As a result, when it converted the files to need that field, it lost the animation lists to all our character prefabs.

In addition, all our bone armature animations were titled different things, so while most animations existed under “Default Take”, a few times I had to set it to their individual armatures instead, which were usually titled random things. We didn’t have this setting or feature before, so our animators don’t have a set standard for what they name the root armature object in blender. I think what happened is that Default Take is whatever was highlighted to play in Blender when they saved out all the animations, while the armature named one(named after the model’s own object) is the full set of animation key frames.

Unity must have saved the data for the prefabs somewhere, because once the animations existed again, most of the prefabs found them and linked to them just fine without needing any further work. A few needed to be manually reconnected to their animations, but it wasn’t too bad. Thus two hours later, here I am with all 28 objects(most of which had 4-12 animations) reanimated and working.

6

This upgrade was not tested enough to create such problems to us, the users. A new version MUST recognize everything of the previous one and add new functions.