• Advertisement
Sign in to follow this  

Unity Synchronising animations within a blend tree

This topic is 1184 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
Advertisement
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
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Manuel Berger
      Hello fellow devs!
      Once again I started working on an 2D adventure game and right now I'm doing the character-movement/animation. I'm not a big math guy and I was happy about my solution, but soon I realized that it's flawed.
      My player has 5 walking-animations, mirrored for the left side: up, upright, right, downright, down. With the atan2 function I get the angle between player and destination. To get an index from 0 to 4, I divide PI by 5 and see how many times it goes into the player-destination angle.

      In Pseudo-Code:
      angle = atan2(destination.x - player.x, destination.y - player.y) //swapped y and x to get mirrored angle around the y axis
      index = (int) (angle / (PI / 5));
      PlayAnimation(index); //0 = up, 1 = up_right, 2 = right, 3 = down_right, 4 = down

      Besides the fact that when angle is equal to PI it produces an index of 5, this works like a charm. Or at least I thought so at first. When I tested it, I realized that the up and down animation is playing more often than the others, which is pretty logical, since they have double the angle.

      What I'm trying to achieve is something like this, but with equal angles, so that up and down has the same range as all other directions.

      I can't get my head around it. Any suggestions? Is the whole approach doomed?

      Thank you in advance for any input!
       
    • By devbyskc
      Hi Everyone,
      Like most here, I'm a newbie but have been dabbling with game development for a few years. I am currently working full-time overseas and learning the craft in my spare time. It's been a long but highly rewarding adventure. Much of my time has been spent working through tutorials. In all of them, as well as my own attempts at development, I used the audio files supplied by the tutorial author, or obtained from one of the numerous sites online. I am working solo, and will be for a while, so I don't want to get too wrapped up with any one skill set. Regarding audio, the files I've found and used are good for what I was doing at the time. However I would now like to try my hand at customizing the audio more. My game engine of choice is Unity and it has an audio mixer built in that I have experimented with following their tutorials. I have obtained a great book called Game Audio Development with Unity 5.x that I am working through. Half way through the book it introduces using FMOD to supplement the Unity Audio Mixer. Later in the book, the author introduces Reaper (a very popular DAW) as an external program to compose and mix music to be integrated with Unity. I did some research on DAWs and quickly became overwhelmed. Much of what I found was geared toward professional sound engineers and sound designers. I am in no way trying or even thinking about getting to that level. All I want to be able to do is take a music file, and tweak it some to get the sound I want for my game. I've played with Audacity as well, but it didn't seem to fit the bill. So that is why I am looking at a better quality DAW. Since being solo, I am also under a budget contraint. So of all the DAW software out there, I am considering Reaper or Presonus Studio One due to their pricing. My question is, is investing the time to learn about using a DAW to tweak a sound file worth it? Are there any solo developers currently using a DAW as part of their overall workflow? If so, which one? I've also come across Fabric which is a Unity plug-in that enhances the built-in audio mixer. Would that be a better alternative?
      I know this is long, and maybe I haven't communicated well in trying to be brief. But any advice from the gurus/vets would be greatly appreciated. I've leaned so much and had a lot of fun in the process. BTW, I am also a senior citizen (I cut my programming teeth back using punch cards and Structured Basic when it first came out). If anyone needs more clarification of what I am trying to accomplish please let me know.  Thanks in advance for any assistance/advice.
    • By Yosef BenSadon
      Hi , I was considering this start up http://adshir.com/, for investment and i would like a little bit of feedback on what the developers community think about the technology.
      So far what they have is a demo that runs in real time on a Tablet at over 60FPS, it runs locally on the  integrated GPU of the i7 . They have a 20 000 triangles  dinosaur that looks impressive,  better than anything i saw on a mobile device, with reflections and shadows looking very close to what they would look in the real world. They achieved this thanks to a  new algorithm of a rendering technique called Path tracing/Ray tracing, that  is very demanding and so far it is done mostly for static images.
      From what i checked around there is no real option for real time ray tracing (60 FPS on consumer devices). There was imagination technologies that were supposed to release a chip that supports real time ray tracing, but i did not found they had a product in the market or even if the technology is finished as their last demo  i found was with a PC.  The other one is OTOY with their brigade engine that is still not released and if i understand well is more a cloud solution than in hardware solution .
      Would there  be a sizable  interest in the developers community in having such a product as a plug-in for existing game engines?  How important  is Ray tracing to the  future of high end real time graphics?
    • By bryandalo
      Good day,

      I just wanted to share our casual game that is available for android.

      Description: Fight your way from the ravenous plant monster for survival through flips. The rules are simple, drag and release your phone screen. Improve your skills and show it to your friends with the games quirky ranks. Select an array of characters using the orb you acquire throughout the game.

      Download: https://play.google.com/store/apps/details?id=com.HellmodeGames.FlipEscape&hl=en
       
      Trailer: 
       
    • By khawk
      Watch the latest from Unity.
       
  • Advertisement