I’m looking for documentation (videos, articles, whatever) on animation best practices with regard to the use of actions, scenes, etc. Essentially; I’m fine with the basics of animation, kinematics, curves, etc. I do however run into a lot of problems such as accidentally breaking animations that occurred earlier in a scene by animating a parameter on an object later in a scene that didn’t have a keyframe earlier.
To illustrate what I mean:
At time 0, I translate and rotate an object A.
At time 100, I do some other animation with other objects.
At time 200, I scale the object A.
Because A didn’t have any keyframes relating to scale at time 0, the changes in step 3 will break the animation prior to time 200 as Blender will start interpolating from the default scale value to the scale value set at 200.
This is just a single trivial example. Obviously keying sets help with this somewhat as you can then ensure that keyframes are created for large sets of parameters, but there are other issues that don’t have such simple solutions. One fairly brute-force “solution” is to create a new scene for each camera shot. This eliminates the possibility for timeline-related mistakes at the cost of possibly having a huge number of scenes (which might start to get unmanageable).
I’m curious how people who are making longer animations manage their scenes, timelines, actions, etc. There appears to be very little information on this online. Youtube videos only tend to cover the basics of animating objects, and don’t provide any insight into structuring larger projects to make them manageable.
The solution to the issue described is simple : keyframe as much as possible of whatever is relevant to your shot. Typically character animators will key the full character on each keyframe during block-in, to ensure no property is left dangling.
By “timeline-related mistakes”, do you mean changing a value that you forgot wasn’t already keyframed? I don’t see how creating multiple scenes alleviates that.
Creating multiple scenes can be helpful, but I personally work with single .blend files, one for each shot.
A given object can only be linked to a single action at any given time, so if that object is shared between scenes (through a linked copy), you won’t be able to animate it differently on a per-scene basis.
What’s the least error-prone way to, for example, ensure that every single joint in a rig is keyframed? It seems too easy to miss something with effort alone.
When I’ve done that, I’ve normally worked with copies such that mesh data and materials are shared, but everything else is “new”. The objects in different scenes are different objects, but the heavy part of the data (mesh data, UV maps, all that) are shared.
Auto key just creates a keyframe for each joint that you actually manipulate, unless I’m mistaken. It doesn’t ensure that all of the joints in the current frame have the keyframes that they should (and it probably shouldn’t, unless you want a 1:1 correspondence between frames and keyframes ).
AFAIK it makes a keyframe for the frame you change some property and for the frame before or the first (not sure about that) when you do not have any keyframe before that…
…otherwise auto keyframe does not make any sense at all… right ?
Most rigs are organized in armature layers (now bone collections), to make it manageable for the rigger and for the animator. The animator can choose to show every bone collection that’s meant for controllers, select everything in there and key the “available” keying set for instance. Or perhaps the rigger has made a bone selection set meant for that same purpose.
If that works for you then it’s fine. But you’re still duplicating objects for little reason. Any modifier or constraint isn’t linked to the original object when you make a duplicate, so those can get out of sync. My advice is to link in most of your content (characters, environments), use overrides on top of them, and keep one animation shot per file.
In 4.2 things have changed a bit. It can now work like in Maya, and it’s super cool (manual keying vs auto keying can behave differently now). But autokey will never create a key on a frame that’s not the current frame, as far as I know.
Oh yes… you are right… so one has to insert a keyframe before the actual wanted frame (or at the first frame) maybe by enableing autokey, doing some simple “stepped” transformation and back (to nulify it but having the key…)
Never really used auto key because it simply “keyed” too much … or it was too overwhelming… IDK… animation is hard…
So, anyway… I guess the answer is “no, there isn’t any documentation on this”. I imagine these are processes people pick up through a ton of trial and error.
I was hoping one of the various Blender “Open Movies” would have sources (blend files) available, but I’ve not found any yet. That would give some insight as to how these large projects are structured.
Well for a type writer there is also only simple instructions… writing a story is up to the writer… writng a good one also… dito for bycyles, coffemachines cars, viedo camera…
And the files are on BlendersStudio…
…but there are a lot of general tutorials how to animate… the principle of motion flow, spee, acceslartion and “overdoing” some movement are already known from 2D or stop motion animations…
Interesting thread, as I’ve somewhat been wondering the same stuff lately. Finding the very basic info on animating is easy, but finding out how exactly the pro’s animate a shot and why they do all the things they do, is another matter.
Now this has me concerned. For example, if I take my current base model and I fully key every control for position,rotation,scale and custom property (this can matter I assume, as it it can be things like stretch control or object constraint switching), then I get around 3000 keys.
Now that is a lot of animation data, which likely for any given shot, over half of it will never actually change. I mean even if most controls are used, for many one may only move or rotate, but never scale.
So is that what Disney/Pixar, etc really do? As that must make for a nightmare when dealing with the graph editor for example.
True, but that is the principles of animation, not so much the really technical aspects of how best to do it within a 3D software environment and more important, why it can or should be done in such a way.
I’ve seen some docu on “How to train you dragon.”… the do use “direct” manipulators in the 3D camera view to get the key frames… but this alone will not make a good animation… the “inbetweens” computed by the computer are linear or more curve like, but ever motion has it’s own starting and stop accelaration… for exagerating there is also some overshot… and this has to be tweaked for every inbetween for several times to look good…
So it’s all about refineing curves…
I don’t know about the big houses like Pixar, since they use their own animation solutions (Presto, and I forget the other names). But typically you would key only the relevant transforms. A “fist” control usually works with a single scale channel, the rest is locked. IK hands have all transforms unlocked. A foot roll has only its rotation channels unlocked. etc. still, yes you end up with a lot of animation data. It’s the job of the animation editors to present you with a manageable subset of them (filters, “only selected”…).
This kind of thing is pretty much always exposed by the rigger to an interface of sorts, as custom poperties, etc. so in practice it’s no different than keying unlocked transforms+custom properties. As an animator, it’s generally assumed you won’t touch the inner workings of the rig, and the programs I know (Maya, Blender) have systems in place to make sure it doesn’t happen by accident (attribute locking, overrides).
Yes, in short… Blender (imho) is only now being effectively designed with artist workflows in mind, but some of these oldest features, like having several scenes in a single file, lack real integration with the rest of Blender. You’d certainly want it to handle creating “takes” or “variants” of a scene at the click of a button.
I don’t think the Blender Studio, despite being the place where you’d expect to see the best practices, is any more “standardized” in this respect than either one of us. It’s a design limitation in Blender. Which isn’t to say there isn’t a better way yet, I’ll let others chime in with their habits
have you looked at the alive course on blender market or the TOanimate course (This one is expensive) but they both look like they go beyond the scope of most youtube tutorials
But regardless I want to stress that any animation shot will have massive amounts of fcurves. It’s normal, it’s expected. Still it’s absolutely a good thing to key only the necessary channels, not just for the file size, but for your own sanity. Like you said, just one character already represents several hundreds of fcurves. But Blender remembers the selection state of those channels, so you can go in the graph editor knowing you’ll only ever see what you’ve selected. And it’s getting better in 4.2 and 4.3 so no fear to be had regarding the amount of data. Now for the animator’s sake, as a rigger you want to reduce the amount of controllers to a minimum because that will massively simplify their task.
I guess that would somewhat depend on how its ‘done’. I mean in theory, a single ‘fist’ control for a hand, would likely be the result of a whole lot of bones and controls that have been animated to move the fingers into a fist.
So in theory even if you only manually keyframe the fist control, all the finger, etc controls are being keyframed in the background. So still a mass of data, just more hidden.
I may just have to somewhat get over my usual inclination of wanting things to be as lean and clean as possible. This no doubt goes back to my very early days of computers, where every byte counted or one had custom boot up floppies in order to just load what you needed for the game to run, thus maximising that 640KB of RAM one had.
Even today, with gigabytes of RAM and terabytes of storage, I still somewhat do that.
Just need to accept that, yeah, any animation with more then a bouncing ball is going to have a lot of keyframe data.
Sure but as an animator you never have to care about that. This is controlled through constraints and drivers, and the animator only sees a “fist” property, or a “scaleY” property. It’s about exposing the right stuff
As far as I’m concerned this is still valid today… but I never was restricted by computing power or storage like you were, perhaps I don’t share that reflex of always keeping things lean. Anyway the simpler you make things for the animators, the better the final shot you’re going to get. If your concern is seeing the right data, then the graph & dopesheet should be all you need. If you’re worrying about creating too much data, bahhh…, I say it’s never a real problem.
).
because it simply “keyed” too much … or it was too overwhelming… IDK… animation is hard… 