tl;dr: When and how exactly do blend times affect animation lengths?
===================
Hi all, I’m working towards making a deterministic sort of game (w/ rollback), and one large concern of mine is knowing exactly what frame an animation will play. Specifically, I’m worried if/when blends modify how long an animation is
For example, I have a Montage which has a blend in time of 0.25 sec and a blend out time of 0.25 sec. Do those numbers mean that the first 0.25s of the target Montage animation will be blended over, and then at the end an additional 0.25s will be added after the animation is over but before the next animation plays?
What I love about Sequencer is that you can easily see exactly how blends work- timing is extremely straightforward. Unfortunately, I’m not certain at all how blends in general affect animation length elsewhere (both in Montage as well as for normal anim graph blend nodes).
Tried searching around for a while including UE docs as well as various forum posts, but unfortunately didn’t find anything covering this exact topic
So basically (not in all cases because otherwise how could you possibly achieve a splitting headache?) Blend time is the time that the engine takes to transition from Pose A to Pose B.
Where Pose A is the final frame of wherever the character is at, and Pose B is whatever the next frame is supposed to be.
For example, a blend out time of 1 minute between 2 state machine animations would make the process of transitioning between the 2 poses take 1 minute.
In theory. (In practice, I have literally never used a value higher than .25. And even then, they don’t seem to be .25 seconds)
Now with that said.
State machines use the blend different and have themselves blend settings which can include a curve other than linear.
Remember what I said about splitting migranes before? Well this is the first hard point.
While the time should stay constant, how you play an animation backwards would require you to know what curve was used and reverse its values. Easy enough on linear. Good luck with a custom sine of some sort…
Note that Blend nodes are called that, but they generally don’t have a timing.
Inertialization could be a special case here because it does sort of blend.
I don’t think it’s possible to accurately “rewind” an inertialized animation.
Last thing, the montages:
Those do match time as you would expect going from A to B.
It would probably be easier to just play them backwards with a - play rate…
As I have suggested a couple times before, a custom “play montage” system had to be built to accurately “rewind” with.
When you make the system you can keep track of a “stack” of calls, and just play them backwards to undo your actions.
(There’s much more to it than this obviously. But creating your own wrapper for montages can become extremely powerful)
2 Likes
Thank you for the thorough response!
If I understood correctly:
- Generally speaking, there are no guarantees that blend times won’t modify length of animations. They’re just how long the blend itself should take
- Not sure but it sounds like Montages are pretty consistent with their blend times and behave as you would expect them to
In addition, from my testing it seems that Blend In and Blend Out times on Montages only impact the frames of the current animation. ie, a Blend In of 0.25s time will cut into the Montage animation’s beginning for 0.25s while a Blend Out of 0.25s will cut into the last 0.25s of the Montage animation. Length of Montage animations are supposedly kept in tact, but not sure if that’s 100% accurate or otherwise regarding edge cases (eg, not sure about back to back manually-initiated Montage plays)
Thankfully for my specific use case, I don’t need to play animations in reverse but rather start/restart an animation at an exact frame which base montages should do well (as well as have the animation play in perfect sync with completely separate gameplay based on baked anim data). The custom stack idea sounds pretty neat for rollback, but trying to avoid modifying the engine as much as possible for forward compatibility
Thanks again!
2 Likes