State machine transition between blendspace and stop animation

Hi Guys,
I have difficulties with the blending between two states in the state machine. The problem is that between to states it seems that the character gets in a idle position for a very short time before executing the RunToIdle anim. I will explain the problem in more detail a bit further down.
So first let me explain what I want to do. I wanted to implement a RunToStop Animation, so the Character smothly transitions between Idle and Run. This transition depends on which leg is currently up in air. So therefore I started with two animation notifies which indicate in which intervalls I want to do the transition with left or right leg.

Then I created a bool in the AnimBP and assigned a value based on those notifies.

And now to my problem. Here is the state machine I use. The transition rule between RUn and RunToIdle is that Speed <= 5 and from RunToIdle to Idle it is that the remaining anim time should be smaller than 0.5.
Here is how I created the State:

The right animation (right or left foot) is chosen correctly. But the problem is that in the transition it seems that the Character gets from running to an idle position and then to the RunToIdle anim.
Maybe this video can show you what I mean.

What I’ve tried:

  • cutting the animation or using an other animation, this effect still is visible
  • changing the positions of the notifies
  • deleting all other out-transitions of the Run-State

For now I am out of ideas, hopefully someone can help me :slight_smile:

1 Like

Typical problem of using state machines to switch states :slight_smile:
The problem is creating wait states to match up left and right foot states as to blends has never worked with any level of consistency and only compounds the latency problems of using inplace animations.

The requirement is the animation state “has” to change the moment the game state changes and not told toe “wait” until the point in the animation state matches the blend requirements.

The good news is Epic understands the problem and continue to offer better solutions to the problems and there is a lot of hope for the game play and function plugin but to solve left right blending the fix was the addition of sync markers and sync group.

To put it together consider using context based animation construction by using a tree over state machine so the blends will occur on the state change.

1 Like

Hi! Thanks a lot for your answer! I didn’t know about Synch Groups and I already used it in other transitions but for this one it didn’t solve the problem. I need to say that I didn’t really understand your last sentence.

So what I’ve done is that I created those Synch Markers on the Run Anim and the two RunToStop Anims. And Then put them in a Synch Group. Maybe I should have told you that the Run State is actually a Blendspace. Because it seems that the devil sits in there. I figured out that when using a normal forward run anim in this Run state, then every thing works smooth with the Synch Groups. But the Blendspace somehow ruins it.

Well the idea of context based animations is a buzz word that has been kind of lost as to ways and means under Unreal 4.

This is the base theory used in a different engine.

The theory is the animation migration should be switched in the locomotion state is away that only the relevant animation states are used as to the needed state changes and eliminate states that are not needed with in the state machine that are switched to using an inline argument which may or may not be true at any given time as to state change rules.
This is where the idea of context based animations comes in, this case locomotion, as in any give state the animations can only be in a single relevant state at any given time.

Your player can not be in running state at the same time that it’s in a walking state so unifying the two under the same state machine will limit blending options between states as in most cases, using inplace, the state change has already changed and wait states are created to allow left and right foot placement to catch up.

How a tree works, instead of a state machine, is to break up the required relevant states into blocks based on the context of the required movement and use a nod like blend on int, or any other value based switch, so that the switch occurs based on the current state relevant to the desired animations. The benefit is the animation state switches the moment the event occurs with out exit arguments typical of a state machine migration path. The other benefit is you can also make use of the blending options of the weights into and out of the different blocks with out including them as part of the state machine.

I found this pathway to work well with sync markers and groups as it allows UE4 to do it’s thing with out the need for arguments to switch messing up the sync as the switch is an absolute with zero lantancy introduced by inline arguments.

Sync markers are easy to figure out as they only tag the position of the animation as to an absolute once again but the second part required to make it work as to letting UE4 perform the sync for you is to place the relevant animations into a group so the UE4 “knows” that the markers are related based on the context in which the animations is to be used. You could for example create a group called running and that group could be added to your tree.

How groups work.

OK so once in a group Unreal 4 will determine the the easy in and easy out points of the blend by default and as to the current rate so the trimming stays the same with out having to correct using inline hacks that once again adds lantancy. To be able to do this a leader is selected and all takes added to the group will have their frames adjusted to the same length as the leader. If the leader is 20 frames the all takes as part of the group will be length to 20. This makes it easier for UE4 to find the ease in point when say of the right foot and needs to blend to the left with out sliding or funky crossovers usually corrected by forcing the animation to wait until the animation is a position.

This is a free lunch on the part of UE4 as the requirements to make it work is provided by the engine so as long as the relevant animations are part of the group, be it in a blend space or not, then the engine will preform the proper foot blending for you.

Sorry for being a bit wordy but sync markers and groups is one of those things that hard to understand at first but becomes easy the more you use it and using context animations along with switching trees increases the number of blending options that is made difficult trying to shoe horn everything into a single state machine that may or may not work as to expectations.

Thanks a lot again for taking the time to answer in so much detail. I really appreciated it :). I actually found a solution for my problem. As I said it looked like the Blendspace was the problem. I found out when setting the Target Weight Interpolation from 0 to 2 it works quite nicely. But it feels like a temporary solution since there is a lot going on in the background that I dont understand. So I will definitely come back to your post and try to optimize this :). Thanks again!