Hi all

My animation system is almost complete but I've come across an issue that I haven't been able to get any guidance on from Google.

For synchronisation purposes, I keep my animation lengths normalized between 0 and 1 and have a normalized speed/factor per animation which effectively allows me take the correct frame. The normalized speed factor is 1/animation length in seconds.

This allows me to synchronise two animations with different lengths together by adjusting the 'speed' of one to match the other. For example, going from walk to run, I lerp between the speed of the walk animation and the speed of the run animation. Having foot positions in both animations at 0 and 50% means that they line up perfectly and my character can smoothly transition from walk to run as slowly or quickly as he likes. This is standard stuff I think.

My animation blend tree functionality works fine so far, I can setup an arbitrarily complex blend tree by having each blend node take in 2 or more inputs - an input can be an animation clip or another blend node. Using a blend parameter at each blend node to cover the range of thresholds (ala Unity mecanim), I can smoothly blend between the 2-n inputs.

My problem is that my synchronisation only works for transitions between states, so going from a non-blend tree walk animation state to a non-blend tree run animation and I'd now like to use it in my blend tree.

In order to compute the lerp between the normalized speed for clip1 and the normalized speed for clip2, you need to know both normalized speeds. How would this work if you had a blend node two inputs and both were blend nodes?

So I have the following:

Blend tree
\- input 1 Blend tree
\- input 1 clip walk left
\- input 2 clip walk forward
\- input 3 clip walk right
\- input 2 Blend tree
\- input 1 clip run left
\- input 2 clip run forward
\- input 3 clip run right

All 3 walk clips in input 1 are the same length and all 3 run clips in input 2 are the same length but the walk lengths are longer than the run lengths.

In order to calculate a pose using a blend tree with synchronisation, I need to know the normalized speeds of each side of the tree at each level. I've been going round in circles on this trying to visualise it in my head and on paper and the only way I can see to tackle it would be to do it in two passes. Once to compute the normalized speeds down through the tree and secondly to go through and use those speeds on the actual clips.

This could get even more confusing if at a level further down the tree, the inputs of a blend node have different normalized speeds (as per the root node of the earlier example).

Is there an easier way? It feels overly complex to me and like I might be missing a trick.

Thanks

I'm wondering whether to restrict synchronised blend tree children to only one level of blend tree nodes and for each of their children to only have clips (no nested blend tree nodes as inputs). That way I will already know what the normalized speed will be for each side of the main blend tree because they will all be clips of the same length.

I think I might be getting into territory where I'm trying to cater for use cases I'll probably not need.

Wow as you can`t see the solution i don`t see the problem ;)

Since your animations are aligned and you can play them at any speed you can play any blend-node at any speed. Only thing you have to know is the speed each walkcycle has, meaning, you have to know the distance the character would actually travel with each walkcycle. So if you blend a walk-cycle with a "speed" of 1m/s and a run cycle with 2m/s you know how far the character would travel if you mix them 0.5/0.5 so you know ...

I want to add:

I think I might be getting into territory where I'm trying to cater for use cases I'll probably not need.

That might also be true. I wrote one blend-tree implementation and in the end i only needed to blend between the walk, idle and run cycles + foot alignment. The rest where overrides like for the upper body wich didn`t complicate things.

Thanks for your post.

Since your animations are aligned and you can play them at any speed you can play any blend-node at any speed. Only thing you have to know is the speed each walkcycle has, meaning, you have to know the distance the character would actually travel with each walkcycle. So if you blend a walk-cycle with a "speed" of 1m/s and a run cycle with 2m/s you know how far the character would travel if you mix them 0.5/0.5 so you know ...

This is actually the issue, you can't really do that. In order to smoothly blend, you need to know both speeds. You can't blend one side from 0 - 1 because that would go from a stopped animation to the full speed. You need to blend between the normalized speed of the left side of blend tree to the normalized speed of the right side. This is the only way I've found to make it look natural (and for it to actually work correctly). For walk/run, this means the walk cycle starts at a normalized speed of 1 meaning normal speed, to a faster waking speed up to the speed of the run - because the bones are blended by the lerp, you never fully see the walk animation at the speed of the run.

I've decided to do what I mentioned and just go with one level of blend tree where clips are supposed to be synchronised and to enforce that all of either side of that blend tree's children are clips rather than other blend tree nodes.

I think this is a perfect example of trying to initially develop something that you'll probably never need. I looked over my diagram of my entire animation tree and I don't need the arbitrary functionality I was initially aiming at.

Thanks for reading.

This is actually the issue, you can't really do that. In order to smoothly blend, you need to know both speeds. You can't blend one side from 0 - 1 because that would go from a stopped animation to the full speed.

Ok i think i understand how you handle it.

In my solution it worked like this:

animation.play( normalized length of the clip from 0 - 1 )

And i knew the velocity of each motion and they were aligned so if one motion had the left-foot-hit-ground on 0.5 the other clips would also have left-foot-hit-ground on 0.5.

Now if i have a walk clip with 1m/s (if played from 0-1) and i needed 3m/s i would simply speed up the replay of this clip (*3), then if i say a run cycle fits better cause it has a original speed of 1.5m/s i would run this clip with *2 of the normal speed and crossblend the weights of both clips (the new clip with 0 at the beginning, _not_ the speed but the weight).

You are right thought that then your animations are not aligned any more. The best solution i saw for this problem was with Rune Johansens Locomotion solution for unity. Basically each leg is analyzed on it`s own for each walk-cycle. And the main states are stored (the positions in the cycle also normalized) for each leg, foot-hit, rest-position, foot-lift.. Then if your character has to walk 45° to the left a strafe-left and walk-forward motion are mixed and aligned based on the previous analyzed data.

You probably want to look into the source code and the thesis of this:

http://runevision.com/multimedia/unity/locomotion/

In order to calculate a pose using a blend tree with synchronisation, I need to know the normalized speeds of each side of the tree at each level. I've been going round in circles on this trying to visualise it in my head and on paper and the only way I can see to tackle it would be to do it in two passes. Once to compute the normalized speeds down through the tree and secondly to go through and use those speeds on the actual clips.

Consider the following preconditions:

1.) Animation tracks are time based. Animation clips lengths are given in time units.

2.) An animation like walking and running is marked as cyclic. Its clip shows an integer number of C cycles (1 would be fine). It starts with motion phase S and ends with phase E=S+C, both normalized values (S=0 and E=1 would be fine).

Now you have to guarantee that 2 such cyclic clips are blended when their motion phases both show the same fractional part. In other words, you transform the particular local playback time of the both animations so that they result in the same motion phase.

An example: From idle to running

The avatar is in "idle" state. The speed variable has value 0.

At time t0 the player triggers the avatar's forward motion. The animation system changes into state "start forward motion". Those state plays a pre-canned, non-cyclic animation. One of its animation tracks can be used to update the speed variable. At time t1 those animation notifies that it has reached the end. At this moment the speed variable is, say, 3 (meant e.g. as meters per second). This is the nominal speed for which the "walking" animation was crafted. (Let the "running" animation be crafted for the nominal speed of 6.)

Due to the notification from the animation, the animation state "start forward motion" is exited, and the state "forward motion" is entered. This state uses a blending between the "walking" and the "running" animation clips. This blending is configured to be controlled by the said speed variable. Fetching the nominal speed values 3 and 6 from the animation clips, the blend node can compute the weights as

wwalk = ( 6 - 3 ) / ( 6 - 3 ) = 1

wrun = ( 3 - 3 ) / ( 6 - 3 ) = 1 - wwalk = 0

The second control parameter is the motion phase. It was set at the end of the "start forward motion" animation state. The "forward animation" state takes it (its fractional part, to be precise) as the initial phase values for "walking" and "running".

Let's assume that the player does not increase the motion speed for a while. So for the next frame, happening at t1+T, the speed variable still show the value 3. Hence the weights are computed as before. The motion phase is to be increased by the fraction

T / Lwalk / Nwalk

and eventually wrapped (if the length of the clip is exceeded).

Let us now assume that the player increases the speed variable to a value of 4. The weights compute to

wwalk = ( 6 - 4 ) / ( 6 - 3 ) = 0.667

wrun = ( 4 - 3 ) / ( 6 - 3 ) = 1 - wwalk = 0.333

again using the current speed and the nominal speed values of the both clips. What happens to the motion phase? Well, the "walking" animation needs to be played back faster than nominal, and the "running" animation needs to be played back slower than nominal, or else their respective motion phases would be out of sync. In general, both clips need to be played back so that a full cycle takes the same time. Hence, if the own weight reaches zero, the playback speed must be adapted so that the own playback duration for one cycle is as long as the nominal playback duration of the other animation for one cycle, which means

Fwalk = ( Lwalk / Nwalk ) / ( Lrun / Nrun )

Frun = ( Lrun / Nrun ) / ( Lwalk / Nwalk )

For any speed value in-between, we get as playback acceleration factors

fwalk = 1 * wwalk + Fwalk * wrun

frun = 1 * wrun + Frun * wwalk

mrun = Trun / Lrun / Nrun = T * ( wrun * Nrun / Lrun + wwalk * Nwalk / Lwalk )

which, unsurprisingly, are the same values.

So, both animations are in sync, and can be blended continuously.

EDIT: Forgotten to say: To stay in sync regardless of numerical inaccuracies, I would compute the motion phase within the blend node, and use it to compute the current local times in the both animation clips directly, i.e. not accumulating local time deltas.

So, both animations are in sync, and can be blended continuously.

I may have not worded my post correctly because that's exactly how I'm currently doing it. Just to be clear, I can sync up animations nicely between walk and run with feet in the exact same place, etc, but my original issue was when you have blend trees within blend trees that need to be sync'd.

So consider this perhaps slightly better scenario:

The root of a blend tree has two inputs, input RootA is another blend tree and input RootB is another blend tree. RootA is a blend tree which has 3 inputs, all of them are animation clips of the same length and they deal with the walking animations. Walk left, walk straight and walk right. A parameter called "direction" is in place to blend between the nearest 2 of these animations meaning when the user is walking (speed=0 let's say) and presses the x stick, the avatar walks left, straight or right, blending nicely in between.

RootB also has 3 inputs, all animation clips and all of the same length but these are run clips and so are of a shorter length than the walk clips. The same principal applies, run left, run straight and run right using the same direction parameter.

Speed is the parameter of the root blend tree which blends between the current walk pose and the current run pose. As Haegarr described, you need to lerp between the speed of the walk and the speed of the run using the normalized speeds of each.

This works nicely (and I do have this working) because you know that when you blend the current walk pose with the current run pose (ie blending at the root level), regardless of what the walk pose blend looks like, it will be the same normalized speed and the same for the run pose (obviously these will ultimately be different at the root level).

The initial problem I tried to explain was where you replace one of the lower level animation clips, say for instance, walk right, with a further blend tree. This blend tree may blend between two styles of injured walk right perhaps or something like that but the point is that the normalized speeds of the clips under that new blend tree may not match those of the existing walk animations.

When you're at the root and you traverse either side of it to create your sync'd poses, you HAVE to know the normalized speed of the 'other' side of the root blend from that which you're traversing otherwise you won't be able to match them.

This is incredibly difficult to explain without a graphic and I don't currently have the facility to draw one so I'll try later.

Basically, I've had to change my code so that for a blend tree that requires pose syncing, animation clips on each side of the blend tree need to have the same or very similar normalized speeds. I mean all the walk anims need to be of the same length and all the run anims need to be of their same length.

Does that make sense? I'm talking about arbitrarily nested blend trees with different normalized speeds within the same input blend tree.

A blend node tree that blends between walking and running, for example, is for another purpose than a node that blends a sane walk and a limb walk cycle. You're right when you say that animation clips of the same intended purpose but just a different representation can be expected to be crafted with matching parameters (or at least the parameters can be statically equalized).

An animation clip is crafted and hence has a defined length and nominal playback speed. A blend node may have this, too, but that depends on the type of the node or perhaps its sibling nodes; a node that dynamically adapts durations counts not to them.

But ...

Basically, I've had to change my code so that for a blend tree that requires pose syncing, animation clips on each side of the blend tree need to have the same or very similar normalized speeds. I mean all the walk anims need to be of the same length and all the run anims need to be of their same length.

... isn't exactly what I would say, but on the other hand I donÄt understand it fully. What is the normalized speed you're talking about here?

... isn't exactly what I would say, but on the other hand I donÄt understand it fully. What is the normalized speed you're talking about here?

Normalized speed is simply 1 / animationLength (in seconds).

I do all my calcs using normalized speeds and then when I go to sample the animation, I adjust it at that point from 0-1 into the "animation time space" to get the correct frame.

To calculate the speed between run and walk, I use:

lerpedWalkSpeed = (walkSpeed + (runSpeed - walkSpeed) * lerp) / walkSpeed

lerpedRunSpeed = (walkSpeed + (runSpeed - walkSpeed) * lerp) / runSpeed

And where walkSpeed is faster than runSpeed:

lerpedWalkSpeed = (runSpeed + (walkSpeed - runSpeed) * lerp) / walkSpeed

lerpedRunSpeed = (runSpeed + (walkSpeed - runSpeed) * lerp) / runSpeed

Obviously for clarity I've named the variables relative to walk/run, in my code it's just input 1 and input 2.

I then take these two results from either side of the tree and blend them according to the blend tree's blend parameter, in this case, "speed".

I think it's too difficult to get my issue across without a diagram. But as you can see, to calculate one side of the tree, you need to know the normalized speed of the other side. That's all fine and well, but if the children and subchildren of one side of the blend tree have varying times, it's difficult if not impossible to do it all in one pass.

I think it's too difficult to get my issue across without a diagram...

I think I've understood it already; that is what I meant with nodes that dynamically adapt durations, which is equivalent to a variable normalized speed, when using your term :) Just the example of limping need not fall into this category, because the node that blends between limping and sane walking is of a type that need not adapt playback speed. As soon as you allow for an arbitrary blend node composition, and you seem to do so, then dynamic length nodes can be nested, and you approached the problematic case.