Support for looping animations

I’m trying to animate a run cycle for a game character, and I’m just wondering if there’s an easier way to get it to behave nicely when looping than just duplicating all the keys and sticking them before and after the animation. I’m finding that easing in and out of keys is inaccurate since it’s not interpolating across the loop boundary, if you see what I mean. And it’s also a bit of a pain having to remember to copy the pose from the first to the last frame of the anim every time I update it. Is there some way to tell Blender that the first frame should be identical to the last frame, and have it handle this nicely?

I’m not quite sure what you mean…you should be able to just make one cycle of your game character running, and it should be able to loop on it’s own in the game engine

If you’re having trouble with making the run cycle, try googling “cg cookie walk cycle tutorial game engine”, which should bring up (hopefully) a tutorial I found a while back about run cycles and implementing them into the game engine, focused on a sackboy character.

I would post the link myself, but I’m unable to atm :confused:

That is what the NLA is for. You can make action strips out of your standing still walk cycle. Once it is a strip you can loop it and time stretch it and mix it with other strips.

When setting the keyframes for your loop, there is no method in Blender to automatically dupe the start loop keys to the end, but it’s a simple matter to select the keys in the Action Editor and dupe them any number of frames ahead, using selection shortcuts and numeric keypad parameter input. Example:

  1. select any single key at loop start
  2. use K-KEY to select all keys on that frame
  3. Shift+D-KEY to duplicate, followed by the frame-advance parameter on the numpad, e.g. “Shift+D, 30” (don’t type the comma!) will advance the dupes 30 frames. Negative numbers retard the frames.

Keep in mind that for the keys to interpolate properly from loop end to start, the orientation of the key handles (in the Graph Editor) should be identical, and for some handle types, this means that the preceding and following keys for the start and end frames, respectively, must also be identical, otherwise the handles may not have the proper orientation, causing interpolation glitches across the “loop boundary” as you put it.

Also, though you probably already know this, if viewing a loop in the Timeline, it’s often best to set the frame range of the loop to “End” minus 1, so the identical Start and End frames are not both used, which can cause a visible pause in looping motion flow, particularly in rapid motion like a run cycle.

In the Graph Editor, if any sequence of keys in an F-curve needs to repeat exactly, you can use the F-Curve Modifier “Cycles” to set it to repeat without actually duping frames. The Modifier has some parameters you can set to modulate how it works, but by default it simply creates an infinite repetition of the selected F-curve. Any edits made to the “template” keys will be reflected in the “Cycles dupes” as well.

For NLA use, it’s often helpful to have a full set of keyframes for all animation channels at the start and end of the loop, but for some kinds of animation this isn’t always desirable, so you can use the NLA Strip editing tools (N-KEY in the NLA window) to set the start and end frames for the strip, and also to modulate its overall timing. Very handy when fine tuning such motions as walk cycles, though the method of switching back and forth from Action keyframes to NLA strip is not that intuitive.

That’s precisely it, chipmasque. I’m finding that the only way to get it to look right is to duplicate all the keys twice, once for before and once for after the animation, so the handles are pointing in the right direction. Otherwise, everything ‘neatly comes to rest’ at the beginning and end of the animation, when really I want it to move smoothly the whole time.

Here are some examples of what I’m talking about. I want to just move a bone left and right smoothly (using the bezier interpolation mode), but I want the first and last frame to be the frame half way through the motion rather than at the turning point. That’s a bit contrived for just one bone but if you consider a character animation, it’s unlikely that there are going to be no parts of the cycle that are part-way through their motion.

So, I start by sticking a position key at frame 10 at -1, and one at frame 30 at position 1, and set the length of the animation to be 40 frames. This is what I would want to work; I would want Blender to know that the next key on from the second one, is the first one, so the position would be 0 in frames 1 and 40, but of course Blender doesn’t do that and it just leaves the position at 1 until it gets back to frame 1, where it snaps back. The orientations of the handles are correct, it’s just that Blender doesn’t know it’s meant to loop:

Naively, I might try to fix it like this; place a key half way between the extremes at the frame boundary. That will fix the jump in position, but of course it will come to rest on the first and last frames, which isn’t the motion I want:

What does fix it is duplicating all the keys, once for before the animation starts and once for after it finishes, so the handles are pointing in the right directions, like this:

(well, I should only need 2 keys per channel to give the bezier curves enough to work themselves out within the frames I care about, but duplicating all of them is easier)

I was just hoping that there was some way to tell Blender that the animation should loop nicely so it can work out the handle directions by looking for keys across the frame boundary, but it’s looking like that’s not the case! It does seem like something that would be genuinely useful and dead easy to implement, unless I’m missing something. Perhaps I should write some addon to do the duplication automatically, as it’s getting to be a pain duplicating keys every time I make a change to the 1st, 2nd, 2nd to last or last key in a channel!

Thanks for all the responses so far!

You can fix this manually (and simply) by editing the key handles at either the start and end frame, and then duplicating that edited handle to the other end of the loop. You’ll find that for start frames, the trailing handle orientation is preserved, and for the end key the leading orientation is preserved, even without additional leading or trailing keys:

To create loops within larger-period F-curves (like your last image post), you can insert keyframes at one of those points, edit the handle orientation if needed, and then dupe to the other loop end.

If you’re using these animations as NLA strips, you need not create start and end keyframes (as long as the curves at these points are identical), but instead can edit the NLA strip to start and end at appropriate frames. These single-cycle strips can then be duplicated to create continuing loops.

I realize that managing loops can involve a fair amount of manual work, but keep in mind that loops are only one kind among many different types of animation, so coding an auto-loop capability adds a lot of work for something that may not be used all that often, and can be done manually without a lot of hassles anyway. There are also a lot of choices that need be made when creating loops that would make a function more than a little complex to code for full automation – for example, do the handles at the loop boundaries need some adjustment to perfectly preserve the motion flow through the loop? They often do, and it’s best done by the animator, not an algorithm.


Ah, well I’m actually a programmer rather than an animator, so that’s probably why I’m looking for an algorithmic solution rather than an artistic one :slight_smile: I trust my ability to code smooth motion far more than my ability to manually create it!

So are you saying you hand-edited the keys on the first and last frames in your example? I see how that makes sure there isn’t a jump in position, or in velocity if you also duplicate the handles, but isn’t that effectively putting a control point in between two other control points needlessly? I mean, you wouldn’t put one between the 2nd and 3rd control points in your example because that would make it harder to edit them, the same way putting keys on every frame would. I don’t understand why the first and last frames are done differently. Also would you ever edit one of them and not the other, or would you always just copy and paste one over the other? I’m not criticising your answer at all, I’m just genuinely curious as to why looping animations are done this way. If having some “auto loop” addon would benefit more people than just myself, I could certainly look into writing one.

The image posted illustrates what might be called a “hard-keyed” loop, since you were commenting on needing leading & trailing keys in some cases where the loop boundaries fall where no keys normally exist. It’s mainly to show how the handle orientation can be duplicated with the key, to avoid the issues you mentioned earlier. This limits the need for keys to only the loop frames, but isn’t the only way to do it.

Much depends on how your loop will be used. If for example you have a need for a fully keyframe-defined loop, then you can use the method in the example. In other circumstances, editing an NLA strip might be better, and start/end keys might not be needed. Other “looping” animations might be able to use the Cycles F-curve modifier.

My “formal” conception of a loop is a sequence that has a discrete keyframe structure with start & end keys, like that shown. It’s used in situations like game tech where the animation is best defined in a number of discrete and well-defined keys. But it’s by no means the only way to create looping or cycling animation.

Ok, I see what you’re saying. Thanks for the pointers to NLA strips and cycles modifiers; I had a quick look and they definitely seem like useful tools. I think an addon like I described would also be useful though so I think I’m going to investigate that, even if nobody else would use it :slight_smile:

Thanks for all the advice!

An add-on would be useful no doubt, and that’s a better avenue to such a tool, as most add-ons are rather special-purpose thingamajigs. One of the great things about Bender is its open architecture that allows development of such niche capabilities by enthusiastic users. I did the same with BLenses way back in 2.4x.