Sign in to follow this  

Unity Synchronising animations within a blend tree

This topic is 1110 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Edited by avision

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

 

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/
 

Share this post


Link to post
Share on other sites
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

using the the current speed and the nominal speed values of the both clips.

 

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

So the elapsed local times are
    Twalk = T * fwalk
    Trun = T * frun
which can be used to access the correct key-frames when being used as time delta. Furthermore, the relative motion phase deltas are
    mwalk = Twalk / Lwalk / Nwalk = T * ( wwalk * Nwalk / Lwalk + wrun * Nrun / Lrun )

    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. smile.png

 

 

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.

Edited by haegarr

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

... 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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

This topic is 1110 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628659
    • Total Posts
      2984079
  • Similar Content

    • By arash khalaqhdoust
      hey guys i hope you doing all well. last night i released my first game in google app store, i really appreciate you guys  to download it. and share your reviews about it
      the idea of game comes from mini hackgame of Bioshock.
       link of download:
      https://play.google.com/store/apps/details?id=com.RVBinary.piperist
      many thanks
    • By ForgedInteractive
      Who We Are
      We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! Currently, we're progressing very quickly with our first project and there are plenty of opportunities and work for new interested programmers. With this project, our development platform is Unity 5.5.2 and C# as our behavioral language. Since this project is our first release, the game itself is a smaller project though progress is moving quickly. We are looking to finalize the current project and get started on future projects in the near future and are expanding our team to do so.
       
      Who We Are Looking For:
      Programmer Level Designer  
      About the Game
      Ours is the tale of two siblings, thrown into a world of chaos. Living in the shadow of their parents' heroic deeds and their Uncle's colorful military career, Finn and Atia are about to become the next force to shape our world. How will you rise through the ranks of Hereilla and what will be your legacy? Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.
       
      Previous Work by Team
      Although we are working towards our first game as Forged Interactive, our team members themselves have worked on titles including and not limited to:
      Final Fantasy Kingsglaive FIFA 2017 Xcom 2 Civilization  
      What do we expect?
      Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques
       
      What can we offer?
      Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.
       
      Contact
      If you are interested in knowing more or joining, please email or PM us on Skype. A member of our management team will reply to you within 48 hours.
       
      E-mail: Recruitment@ForgedInteractive.com
      Skype: ForgedInteractive
       
      Regards,
      David, Colin and Joseph
       
      Follow us on:
      Facebook: https://www.facebook.com/ForgedInteractive/
      Twitter: @ForgedInteract
      Youtube: https://www.youtube.com/channel/UCpK3zhq5ToOeDpdI0Eik-Ug?view_as=subscriber
      Reddit: www.reddit.com/user/Forged_Interactive

    • By dell96
      I'm trying to make my first project but I'm stuck i don't know how to make my crate to start to spawn again when i hit the start button after i die.
      hoping someone can help!!!
      Crate.cs
      CrateSpawn.cs
      Cratework.cs
      GameController.cs
      GameManager.cs
  • Popular Now