Recently, I’ve been doing a lot of work with the Unity animation system (UI stuff with hand-made animations, rather than importing character animations from some 3D package), and I’ve noticed myself getting more and more used to the strange things it does, so much so that I only realise how strange they are when I explain them to others…
Let’s get some context here. I’ve written tools for a living, one of the reasons I got in to coding was to make it easier for other people to make stuff, I enjoy learning a lot about how something works so I can abstract that all away and make it something that most people don’t have to think about. In short, I care about good tools, bad tools annoy me.
One thing I’ve learned when making tools is that it’s really valuable to get feedback from users, but it’s so much more valuable to just watch them use the tool and see what happens, and any time a user pauses and goes ‘hmm’ that’s when you know something isn’t as clear as it should be. Something about your tool is strange to that user, and strange is usually bad (or at-least not-good).
So here’s a short list of things that are strange about the Unity Animation window.
Record Mode
When you’re making an animation by hand, Unity has this feature where you can press a record button, and from then on for any change you make to a property that is part of a Component that is on either the same GameObject as the Animation component, or that is a child of that GameObject, a new property and key-frame is added to the animation. This allows you to make animations just by changing properties, and this isn’t strange this is awesome. But it doesn’t really work if there’s nested Animation components.
If you’re in record mode and you select a GameObject that is under the Animator component you’re working with, but also underneath another Animator component, the Animation window will switch to showing an animation from that second component even though you’re still supposedly editing the first one. You can stop this behaviour by using the little padlock to lock the Animation window, but that seems like it should be the default when in record mode.
The other thing about record mode is that it implicitly turns on when you scrub through the animation, I’m not entirely sure if this is meant to be an optimization of a workflow (the user is scrubbing through the animation to edit it) or if it’s just a hack (we want to preview the animation when the user scrubs through it, the easiest way to do that is to turn on record mode) but it’s caught me out a few times.
Animations In The Project View
Unlike most files types in Unity you can’t find an animation in the Project view and edit it from there. You have have an Animator in the hierarchy with an AnimationController that contains the clip. This inconsistency is strange (though it may be debatable how much use it would be to edit an animation without being able to preview it, but it’s something I’ve wanted to do a couple of times).
Project-animations are also strange in that you can’t multi-edit them in the Project view, there’s a couple of settings on the Animation, but you can’t just select a load of them and modify them all at once like you can with say, Textures.
There’s also strange rules about creating Animations. If you get a UGUI button to generate an AnimationController and Animations for the button states, they appear in a tree-view with the AnimationController at the root, which is nice and tidy and makes sense (since animations tend to not be shared between controllers). But there doesn’t seem to be a way to do this through the editor (I assume you can do it in code) which leads me to creating a folder named after the AnimationController which contains the controller and all the animations. Messy.
Editing Animations
On the left of the Animation window there is a list of properties that the animation controls. The property has an icon which matches the icon of the component that the property belongs to, the name of the GameObject the component is on, and the path to the property being edited (e.g. MyUiGameObject: Size Delta.x), these properties are even indented to show how far from the root of the animation they are, and all this is very nice but you really need more.
Because only the name of the GameObject being animated is displayed, it’s easy to get duplicates. If for example, you have 4 GameObjects named A, B, C, and D, and each of those has a GameObject with the same name, say ‘Icon’, when you animate the ‘Icon’ GOs your Animation window will just have 4 properties with the name ‘Icon’ all at the same level of indentation. Blegh.
And this next one is probably the worst of all, the Animation window sorts these properties alphabetically, so if your Hierarchy has GameObjects in with the following names and order:
- Banana
- Apple
- Orange
They will appear in the Animation window like this:
- Apple
- Banana
- Orange
Which means if you’re trying to say, animate items that fade in from top to bottom, and the items are arranged in the Hierarchy in the obvious order, they will be completely different in the Animation window making working out which order they appear in much more awkward than it should be.
I can only assume that this one exists because the Animation window doesn’t know the order of things in the Hierarchy so they figured alphabetical order was better than nothing (they’re probably right on that one).
And finally, the references to the properties being animated are stored by name/path, so if you rename a GameObject (or add a new parent) it will loose the reference to the property, and the animation will be broken. This makes sense because it allows you to have the same Animation at different points in the Hierarchy and for it to ‘just work’ but it would be really nice if it listened for events from the rest of the editor so that if you say, re-named a GameObject, the name in the Animation was updated (or at-least if the user was given the option)
Okay Enough Now
That’s the major things I’ve noticed anyway. This rant has been quite therapeutic. Unity has gone on a bit of a spree recently of open-sourcing some of their code, but unfortunately the Animation stuff isn’t there yet, so the best I can do is document this strangeness for a future time.