State Machine / Blendspace Philosophy

Development Programming & Scripting Blueprint
1

So loved the persona blueprint tutorial and yes like he stated in the vid I already have a game in mind and want to apply what I have learned. I also want to make wise decisions to begin with, thus I am hoping for a little philosophical guidance as to which type of setup to “Pursue”. I am sure there are some little tricks that would make one way better over another and or just little tid bits that are good to know in advance. I would love to not spend weeks just testing out different setups and more likely spend those weeks tinkering one type of setup to get it right.

Lets outline the complete tree: Idle → Crippled → Walking → Running
Take into consideration Strafing on either side and Momentum

My concerns

  1. If I make the above all one blend then with momentum considered every time the pawn goes from idle to any direction before it gets up to speed its going to try and fire that cripple animation which imho would make it sort of gimpy looking. Per testing thus far it doesn’t appear to have momentum really it just goes from straight to walking but the blend in and out speed of that is ugly and jumpy to say the least.

  2. If I take out the Crippled from the above blend space, make it its own blend and state machine then I am concerned about the state machine flow for when I integrate other state machines. Forgive me if this is a simple question but can I create my state machines like the below attached screenshot on the left. Each in its own individual loops or must they be linear like on the right.

a7c3b9c5aa17f17b4fb8e90406127c452cf8ebe1.jpeg

  1. If left image is possible can I break out of any of those states and override it to another or once you set down that path you have to wait till it comes back? If linear I would imagine still same issue.

Example: One of those loops is a crippled state machine loop. The other is a Knocked Down flat on your back loop. Your walking around, whoa wait nope now I am crippled oh no here comes a bus because I crippled I can not get out of the way in time and bus runs me over knocking me down. Can the knocked down state machine loop break in and override the crippled state machine loop.

So Inputs, Recommendations & Explanations all are welcome and thanks in advance

2

Hi OSIAS,

  1. Animation state machines don’t have any ‘built-in’ behavior, the appearance of momentum is entirely up to how the states (and their inner blend graphs) and transitions are defined.

  2. You can build either kind of graph. State machines can have arbitrary topology (The only thing not currently supported is a transition from to the same node immediately back to itself).

  3. You control all transition logic and can have multiple transitions connecting the same nodes, so if necessary you could have a long blend and a short or instant ‘emergency’ blend that has a higher priority than the long blend but only fires if an additional condition was required, etc… We also support conduit nodes, which are basically a way to make transition groups / share logic when you need to do one to many or many to one transitions from multiple nodes. For example, you might have a ‘dying’ conduit with an input from every state, and an output to two or three death states, depending on how you got killed. This saves you from having to link to all three dying nodes from each other node in the graph.

Cheers,
Michael Noland

3

I run into this issue yesterday with walking, so here are things you can consider.
If you use state machine, use it for abrupt changes(jump), but if you want anything that blends smoothly between animations, use blendspace(idle/walk/run).

In your case, cripple should be a different axis( 2D blend) and preferred method, or entirely different system like your left image(not as good unless you have montage animation to help the transition).
The biggest draw back of state machine is one the condition matches, it swap to the desire animation loop or cycle immediately.
I found it when I add a toggle to force my character to walk with state machine, but the animation jitters when you switch state, really ugly and stupid looking.

So if you have a “damage” animation to help you transition from healthy to cripple status, then maybe state machine can have a go,
but if you have things affecting your crippling in a no transition fashion( ie walk by a health pick up and suddenly not crippling), blendspace is your best friend.

4

So I guess my next question revolves around momentum ?
Is there really any by default?

If I have the following with the following speeds set to it.

Idle → Crippled → Walking → Running
0 – 10 – 20 – 30

  1. So when I am idle and push forward do I technically immediately jump from 0 to 20 or does it gear up like 1-2-3-4-5.
  2. If you do just jump to 20 does it not try to blend the cripple in and will it just ignore it? Will this look ugly?
  3. Should I use animontages to make a better transition from idle to walk then?

Thanks the the responses I am getting what your laying down just still trying to hone the approach. I need to think about this some more before I ask anything else. I am absorbing the animontage / state machine approach.

5

Hi Osias,

The behavior of Speed depends on how you are deriving your speed into the anim graph and how your gameplay code drives the character’s position. The blend space tries to go where it is instantly by default, although it has some axis blending options you can enable (check out InterpolationParam in the blend space editor).

There are multiple approaches you can take, depending on exactly how you want to do it, and how responsive you want the animations to be to game state.

Do you want the character to go thru Cripple, or should cripple only happen when wounded? If you place it all in the same blendspace, then it’s going to go thru it if the speed is ever in that range near a sample point that is cripple. However, if crippled is a game mode that is only active some of the time, you probably either want to keep cripple out of the regular locomotion blend space or deny that range of speeds (e.g., animation Speed input to blendspace is driven like so if !crippled && (speed > 0) && (speed < 20) then speed = 20). If you split it out, then you’d probably have an Idle state (some logic to pick different random idles), a Locomotion state (all your walking and running animations in a blendspace), and a CrippledWalking state (just your crippled walk animations in a blendspace).

Things like locomotion aren’t a great fit for anim montages since you want to continuously vary the angle/etc… (unless you are playing on a grid). They work a lot better for ‘special moves’ or attacks/hit reacts that aren’t parametrized.

Cheers,
Michael Noland

6

blendspace does noy have to be 1D interpolation.

7

Hey thanks I think we are getting it quite well now and its starting to shape up nicely. I really only have one issue and it may be more of an artistic one then really a tool one.

So I think we have planned out and through some testing have our controller pawn in place with its various state and blends. Having the animations fire at the correct rate of speed to make the pawn appear not to have skate etc. The only problem we are having is the blendspace of two locations across from each other and it doesn’t matter the speed and the primary animation looks great, in fact the primaries even blend well with the other sides.

edaf018937a048e4e240c7c77d9f3debfddf74ea.jpeg

If you just take a look at the above image its a 360 movement of a blend space. 4 Primary Anims with the in between arrows as the blends. The problem is the directions in red just do not blend worth anything. I could speed up or slow down and its never going to look right, in fact it the feet movement is just not much. However again everything else looks great just these two angles and even the stand-alone animation around them are nice.

All our anims was captured in Mocap, So I am guessing if any kind of natural motion is taken into account this has to somewhat be a common occurrence. Does anyone have any suggestions artistically or tool wise in which you cope with the issue? Or Ideas?

8

Hi OSIAS,

RE: ‘fire at the correct rate of speed’: Within a blend space, each animation is time-warped to match the highest weight sample, but you can also assign other player nodes to sync groups to get similar behavior across multiple animation player nodes.

Without seeing exactly what you are talking about, my guess is that it’s probably a gameplay versus physics issue. You want responsive gameplay, so your player can probably switch directions instantly, but a real human would have to slow down, stop, and then start going again in the opposite direction to change 180 degrees. You could potentially do custom transition animations when a case like this was detected, blending into a brief custom animation or something to handle large changes in heading, or just accept that when a player is strafing around in the middle of the action they might not notice the bad blend :slight_smile:

You can always make a very realistic looking animation by piecing together only physically plausible sections of animation, but it’d make for mushy controls / ‘bad feeling’ character control if you wanted to change movement in a non-plausible (or non-sampled) way and couldn’t.

Cheers,
Michael Noland

9

Hay Osias

Our team is planing on doing a old school FPS where perfect blending is not really necessary as compared to the amount of different sequences we want to add as well as a need to maintain a logical progression that uses 8 way direction control. In other words how movement would be controlled if a joystick was being used.

For us the use of 2d blend spaces fit the bill perfect as the speed of the player will be a fixed value as to velocity so we would not want the blend space to control speed but rather as a collection of direction changes based on controller input and the actual movement layer normalized before entering the blend space.

The logic is as long as the blend grid is based on even numbers you will always have a center that is 50-50 as a fixed value and moving out from the center you can normalize what primary motions will be triggered by the current fix speed and event going in to the blend space.

Starting from the center 8 way matching animations could be set up in the following order moving out from the center adding grid divisions as needed.

  1. Crouch
  2. Walk
  3. Run
  4. Sprint
  5. Swim

Going into the blend space in a crouch then only 1 is used and if walking 2 and if 3 the run and so on and so on.

Now to make it work so it does not look goofy we are going to use an additive blend space to manage the aiming requirements that matches the same design that is appropriate for the applied lower movement. An aim for a crouch for example will need to look different from a walk and different for a run else everything will tend to look like a puppet on a string.

To set things up so it all at least works in a predictable manner there is a need for a fixed key pose that needs to be used as the center of the blend space when entering and then use that fixed pose as the starting point of the additive aiming to be added later.

Since 99% of the time the player will be aiming anyways in our game the key pose for the idle state will be an idle which will always be 50% 50% going into the blend space when not moving so that the upper part of the player model is always aiming forward no matter the horizontal direction the player is moving.

So in this design you will need 8 sets of animation all moving in the direction chosen but with the upper torso always facing forward center to that direction.

Forward
Forward45left
Left
Backwards45left
Backwards
Backwards45Right
Right
Forwards45Right

In this manner you are more or less using the blend space as a collection and since we will be controlling game speed we can control what part of the web the animations will be locked into.

Now I’m sure there are probably better ways of doing it but as to our design requirements this approach will work best for us as to maintain 8 directions be it vertical or horizontal that the animators could easily create a web and our coders would only need to copy and paste the code and change the entry state and rule set.

The bottom line here though is the blend space is a beautiful thing that can do a lot more than just control a player model and I’m sure it can blend a lot of different things…except an Ipod. :wink:

10

Michael,

Can you please elaborate on your first paragraph, I think if I could tweak the weight or where in the animation its attempting to blend the two together might yield better results. How and where would I do this as well and perhaps some value guidelines would be most helpful.

Let me re-explain the issue, all primary un-blended Directions look good, Front - Backward - Left & Right. Half of the blended Directions Look great as well Front & Right, Back and Left. There are two blended directions in which the feet movement doesn’t look good at all its Forward & Left then Backwards and Right. It stead of a clean full stride in these directions it does a pitter patter of movement that doesn’t even appear to move the pawn in the direction they should be going.

Thus there in lies the issue of those two blends and yes its just those two blends because I have 3 levels of movement speed - cripple - walk - run and in all 3 speeds the results are the same. In the Front & left then the Back and Right the blends look bad.

Its slightly because we didn’t do a simple legs always running forward at a direct 0 Degree below the hips in every direction. When moving to the left the pawn will do the side step rather than back pedal. So how do you control the blend in a setup like this to provide better results. I do not think its a responsive issue either.

If I must I can take a recording and post, but does this explain the problem clearly Michael?

11

Hi OSIAS,

Sorry, the comments about being responsive because I thought you were saying the issue was a bad transition when going from front-and-left to back-and-right, not that each of those individually were bad blends.

Can you look at each of your animations and make sure they’re following the same foot pattern (e.g., left foot first or right foot first) and timing (e.g., all one cycle or all two cycles or whatever)? We don’t have marker based sync, only time warping, so you’d want the relative position of where the left foot goes down to be the same in all the animations you’re blending between (e.g., if the front animation starts at t=0 with left foot planted, all the other ones should too).

I realize this may not be ideal for you if you’re working with existing mocap data but the typical way to solve a problem in the blendspace is more samples (e.g., author a front-and-left animation and place it as a sample where the existing blend doesn’t look great).

Cheers,
Michael Noland

12

Ah thank you, I think you nailed the problem. I will recompile some aims and see how your suggestions pan out.

13

Michael,

No Joy, so I made my first vid. Its really raw I am sorry but I think you can see all the pedigree information you would need to diagnose the issue.

However I think your last statement quoted above just clicked for me. Are you saying I can just make another anim node between the other nodes in the blendspace? Interesting this might work but would have to setup my capture studio yet again and run another day of captures and this takes time, no way of knowing this will for sure solve my problem.

Take a look at my vid and see if you see anything else possible wrong before I commit to such a venture pretty please!

14

I was hoping someone with the knowledge would take a gander while I was gone for a week.
Anyone else perhaps have some input?

15

So next week I was hoping to re-setup our motion capture studio and recapture some things plus fix the above problems. However Looking back over the first person shooter game you provide in the marketplace - if you look the blend and each individual animation you will find.

The animations all start at the same sort of foot placement but its not at the beginning or end really of a motion/stride or loop imho, its more like in the middle of the stride and the left foot is up in the air but close to the middle and the right foot is firmly on the ground middle.

  1. So question is it best to have the feet closer together at the start and end of the loop or should they be spread as far apart as possible? I have been doing far as possible…

If you look at the blend file you will see the same problem I have mentioned at the beginning of the thread. Backwards and at an angle you will see on one side the legs completely clip each other but look pretty good and at the other backwards angle it just looks awful IE the same problem I have.

  1. Is just adding another animation node to blend in between really going to resolve this issue or is it perhaps in the leg movement style setup, is there a reason you guys left this in your demo?

  2. Is it perhaps better to strafe / shuffle when moving left or right instead of a full forward stride to the front or right so that backwards directions will blend better? If so any tips on which foot should be in front of the shuffle for either direction or same in both etc?

My concern is I just don’t want to dump hours into capturing / crunching / lining up etc and still have the same issue. Just want to make sure I clearly understand the issue and the resolution. I do not mind putting in the work, just not wasted work because it doesn’t work out.

Thanks in advance

16

Hey there, I took a look at your video and I’m pretty sure the issue you are seeing is foot placement order. This may seem counter intuitive, but before adding more poses or anims try changing the backwards animation so that the left foot starts behind him rather than in front. Rather than think of it as the animation always starting with the right foot always pulling backwards as you mention in your video, think about it more as the animation should always start with the right foot always pulling the body the direction the body wants to travel. This will help a lot. After that, depending on how the side directions are authored (is it more of a side step, or more of a running foward with the body turned left and right), then it may be possible you will want a few more animations to polish up the blending. But first step is getting the foot placement consistent.

17

Thank you that was the sort of explanation I was looking for. I should be able to have this backwards anim switched out to the dragging philosophy by some time tomm and I will let you know how that worked out.

Again Thanks sounds like the right direction.

18

Okay that didn’t really change much at all, it did a slight improvement but now all I could say is that I am at where you are in the first person shooter demo.

Its not the angle in which they clip each other either its the angle in which it looks awful imho is what I got. The other side actually looks perfect for that direction but that looked perfect before as well.

I really have to believe by just observing all this, your advice and playing with it a bunch that its a transition issue. If you could use your 3rd person blueprint demo and always keep the legs kicking forward no matter the relation to the body you wouldn’t have this issue at all, however that doesn’t seem realistic. At some point the hips or legs have to turn over with the direction.

So as far as I can tell you have two options, and in both of those options are your going to have two angle of transition issues for both of them because the hips have to turn over to the direction.

Scenario #1 forward, left & right = all has the character facing forward but the legs moving straight ahead In that direction. All 180 forward movement will look good and directly backwards will look good. But both backward angles will look bad.

Scenario #2 Left & Right = character facing forward but strafing left and right. This will have all -180 degree backwards movement looking great, moving forward looking great but moving forward and at an angle will look bad.

This is all dependent on just a 4 directional animation blend system, and I have to believe this has been an issue long before UE4 hit. Now so far the only possible solution I see is to add another animation in between the two to try and smooth it out. I do not know haven’t tried this yet.

However does everyone follow what I am saying and does it make sense and do you agree? If so any other tricks besides just adding more animations? I am going to give this a whirl next.

19

I follow and agree for the most part with a minor quibble.

Scenario #1 I completely agree that the back angles will be problematic. You will need more anims. If the player movement is limited to 8 angles then that will work fine. If you are going to have free movement with a joystick, you probably won’t be able to overcome it looking bad at some point without transition animations.

Scenario #2 I disagree that the forward angles will look bad. This was how I have accomplished the movement in our games we released with just 4 directions and I thought the forward angles looked pretty good :). However there was a slight issue with one of the backward angles where the feet had to change how they crossed one another. It wasn’t horrible though, we shipped with it. It just wasn’t perfect, which bugged me.

There is a scenario #3 in which you could always have the hips and legs facing the direction you are running and when running towards the camera have him look over his shoulder. There will be transition work to do when the top of his body needs to turn around during backward movement.

All of these ways have their pros and cons. If you are using a joystick, there will be transition work at some point unless you go with strafing. You should be able to get away with 4 directions, maybe 6 or 8 if you are really particular about it. If you are clamping the directions the player can move to the 8 directions, you are free to do what you want as long as you have all 8 directions have their own animations, and of course less if/when you can get away with it. Depending on what you choose in that case there could also be transitions to deal with, but ultimately it’s up to you and your end goal.

20

So scenario #2 with the feet being shuffled / strafing I just have one more question then. When strafing left or right which foot should be in front depending upon the direction?

strafing right = I would assume left foot stays in front
strafing left = I would assume right foot stays in front

And your confident that both forward angles with this setup should blend out well with the whole, choose one foot to start the animation loop dragging the player in the direction he should be moving.

Well Tomm morning I am planning on setting back up and calibrating our setup for a Mon-Tues capture.