I’ve been playing around with the animation system and I have a pretty nice animation blueprint going with different poses and movement patterns.
One thing that I’ve been thinking about and haven’t quite figured out yet though is the best approach to take when you want to play “interrupting” animations that can change the state of the character drastically.
The typical example that I’ve been playing around with is what happens if one of the characters gets hit by an explosion. This is an example of an animation state that can be reached from anywhere in the graph.
I might want to play different animations if the character is in different poses (say, standing, crouching or being prone) but as far as I’ve tried this fits the features of an animation montage really well. The problem is that once I’m done playing the montage, I would like to coerce the character to blend into the prone state to get up again. One way to do this would be to have arrows from every state going to the hitbyexplosion state, but I don’t want to do this for obvious design reasons. This is something that I imagine is going to come up quite a lot however, so I assume there is a preferred strategy?
I’ve been looking around the function libraries and source, but I can’t seem to find it though
I’m subclassing AnimInstance to do as much of the actual animation checks and code in cpp, but looking at the related baseclasses and interfaces yields nothing of interest. It is possible to query current state names, and I can see some ways to set the state here, but it really doesn’t seem to be by design at all.
Is there really no better way than to have a state/conduit bound to every single state in the state machine?
In other engines there seems to be the concept of animation groups, where essentially, you can assign a state to a group, and then you can have transition rules from a group for example, might there be some way to achieve this behavior?
Just thinking aloud, it might be interesting to create “global transitions” that are always active to let you do this.
This just seems like something that should be fairly ubiquitous… Is there really no good way currently in place to do this?
Yes, I mentioned them in the opening post. The main problem as mentioned however is how to coerce the ABP into a particular state after the montage has finished playing.
Thank you for the reply anyhow
I’m still a bit stuck with this.
Is there really no way to properly do this?
To recap, I’m looking for a way to create states in the ABP with “global transitions” to that state. Basically a condition that will be tested at the same time as the output states of my current state, and if true will force the FSM to enter the state it points to.
Could you use the animBlueprint eventGraph to check if the montage is still playing (montageIsPlaying node) and set flags that inform blendByBool nodes in the animGraph?
Thank you for the reply
I’m not an animator by trade, so I’m not sure I understood you correctly.
I assume you are recommending the following:
Play a montage (hit by explosion or similar “global animation”)
In the eventgraph of the animation blueprint, keep a reference to this montage, and check on its progress.
In the animBp, use a “blend poses by bool” node to switch between the montage pose and my “main” locomotion state machine pose
Is that what you was referring to?
I was exploring this method a while back, but it basically came down to the problem that you cannot have multiple entry points in a state machine. So if I simply blended between the montage and the state machine, I could only really either restart the state machine after the montage is done or continue from where I left off in the state machine when the montage is done.
Now assume that I want this flow:
Character is in an arbitrary state in my locomotion state machine (Running / Walking / Crouching or anything)
Bomb goes off, sends my character flying (montage / ragdoll + force or whatever)
I now want my character to go to the “prone” state in my locomotion state machine)
Is there some way I could accomplish this using the blend poses by bool node? I can see some hacks here with duplicating state machines with different entry points, but that seems even more egregious to me than the other hack. Another hack might be to always enter the state machine in the prone position, but I don’t want to do that when the game starts for example, or let’s say I have a take damage montage (character flinching), that then should put the character in some other state of the machine. Clearly this would not solve these other problems.
I am however very interested in learning more about the general animation BP. Right now I only use it to use different state machines for different parts of my characters’ bodies (lower locomotion and upper aiming for example).
I’m sure there are a lot of other interesting techniques waiting to get discovered however
I found myself dealing with this problem as well. I have worked quite a bit with animations in UE4 so far, but I’m still far from being an expert on the subject though. So take my solution with a grain of salt, there must be better solutions to this problem.
What you could do is having the following setup:
Your initial Graph, lets call it the “Locomotion” graph which handles the majority of your animations.
Cache your “Locomotion” Graph and call it like “CachedLocomotion”.
Now, create an entire new Graph. This graph will hold additive animations that should be played on-top or have a higher priority over your default “Locomotion” graph. Call it something like “LocomotionAdditive”
Inside your “LocomotionAdditive” graph, create an entry state which simply contains “CachedLocomotion”. This state will play your default animation graph flow. Drag an arrow from here to create a new state “Explosion” with a new transition rule like bShouldExplode. Drag an arrow from that state and call the new state something like “GetUpAnimation” which will always play directly after your “Explosion” state has finished playing. Play the Getting_Up_Animation and then after its completed, drag an arrow back to your Entry State which, again, holds the “CachedLocomotion” and thus playing the default “Locomotion” graph. This way your Explode animation graph always has a higher priority over your base “Locomotion” state, but before switching back to your default “Locomotion” graph, it allows you to play an animation in-between; your getting-up-animation.
This approach is far from ideal. Because what happens if you suddenly want to have another high-priority animation that should overrule any other animation? For example; bShouldDrown or bShouldInteractWithNPC, resulting in many graphs. However, it will let you organize and prioritize certain animation-states over one-another. But hey, that’s kinda the gist of animation states; you have to control the entire flow yourself.
If done correctly, the amount of animation-states and graphs in your overal Animation Blueprint should be ‘‘deep’’ (graph in a graph in a graph, causing little overhead) rather than ‘‘wide’’ (many graphs next to each other). I hope this helps you out for now until you find a better solution. Please let me know if you do, I’m very interested in animations and animation-flow control!
If I don’t forget about this thread in the morning, I will try to include pictures, but for now, good luck! ^^.
This is quite interesting, thank you for the insight!
I will definitely play around with this as soon as I can!
It does seem a bit convoluted, but is still a large upgrade from any alternatives around.
I’m a bit concerned that this implies that my “upper” graph will be responsible for returning my animation state to what it was when it took over before handing control back to the cached graph.
So if the animation state of my character changes during the upper graph runtime, it will not be reflected in the actual animations before control has been handed back.
My “global transition rules” would not have this problem I think. I still wouldn’t get around the priority problem you mentioned without actually adding “priority” to the global rules themselves.
Yeah, the way to think about it is that a state machine (prolly locomotion in this case) produces a pose each tick that you hook into the final pose node in the animGraph. You could have several state machines or cached poses or animations but there’s only one final pose so there are nodes to blend the poses together to reach your final goal.
You can blend them by bone chain (i.e. from the shoulder to the finger tips), bool i.e. if this is true the pose is x if not it’s y, you can blend them by weight and by combination thereof. You do this by controlling the pose(s) in the animGraph using the ‘blend’ nodes to create the combined output which is then fed into the final pose. That way you can be walking forward, facing right while reloading a weapon. Sometimes caching the pose is useful/necessary.
You use the eventGraph to set the variables that drive the blends (e.g. the bool or weight) so that they’re scoped for the animGraph. Not sure if this contributes anything that Wabo hasn’t already said but thinking about it this way simplifies it for me.
And re-reading the original post, you can tell it to play a montage in the animBP eventGraph, but like with the state machine you want to check if your animation has run to its end, the isMontagePlaying node tests this kinda like when you use the transition rules in the state machine that go ‘if animation X remaining time < or nearly .1 leave the state’. When your montage is done you can set the appropriate variable for the state machine to put it into the state you desire.
