Sync run/walk anim with movement speed

Hey all,

I’ve been working on a 3rd person action game, using Mixamo animations. As I’m not a skilled animator, I’m pretty happy with the Mixamo assets and workflow, and I’ve been able to put together some pretty good stuff with their help. However, I’m running into an issue where, at times, the run or walk speed of my character does not sync with the animations, creating a “gliding” effect where the character appears to slide over the floor instead of realistically walking.

See here for example:

http://gfycat.com/RectangularScientificKarakul

As again, I’m not much of an animator, what solutions do I have to solve this and get a better looking effect? Someone on reddit tells me the term I’m looking to research is “root motion”, but I was only able to locate a handful of root motion options in Persona, and none of them seemed to solve this issue. Those root motion options did solve another issue I was having (where Mixamo run anims actually moved the character forward, instead of running in place), but no luck on getting the character’s feet to sync with his movement speed.

Any thoughts?

Well root motion solves the problem of feet sliding around as speed as well as direction is managed by the authored animations and not by the linear movement of the movement component of the inplace animations. What you can do in UE4 is tell Persona that the “authored” animations uses the Root Motion Option and not the more generally used in-place authored animations used in conjunction of a required BP movement component

The problem with using root motion at the moment is there is not a movement component that you can add to the character or pawn BP so things like network replication and error correction is real problem as having to be more or less built from scratch that’s just there to use for inplace.

On the flip side.

The main problem and issue of using a movement component is the constant state the capsule or bounding box moves at relative to the speed of the authored animations over X number of frames so when the animations is triggered it’s done in a way similar to what would be considered a 3d flip book and you can increase or decrease the speed depending on how fast or slow you flip the book.

In this case you could correct for speed differences by changing the “scale” rate of the animation as either attached to a blend space or on individual clips to match the playback so to speak to the velocities of the movement component (aka bounding box)

Thanks for the explanation Frankie, that does help a good bit. I suppose I’ll have to fiddle with correcting the animation’s play rate based on velocity.

I have been having this problem as well. I’ve tweeked blendspace speeds and character movement speeds till I’m blue in the face but no matter what, the animation is always slower than the movement speed. What I need is for my Blendspace animation to do what it says it does. Set the animation speed INDEPENDENTLY from the Character movement speed. Although, it doesn’t do that at all. Which is frustrating to say the least. Especially when you’re using Mixamo and Root Motion requires going into Blender for every animation, of which there are hundreds, and adding a root bone.
There HAS to be a better way to make the animation play a little faster, independently from the capsule movement. Why is this not a thing?

Bit of a necro-post there :slight_smile:

But it is a good question and thankfully there is an answer.

Speed / Animation Warping.

Several different people (including yours truly) have worked on their own versions of this technique.

There is a free one on the marketplace:

And another on GitHub:

There are several full solutions that handle it as well, included the Advanced Locomotion System 4

Hope that helps :slight_smile:

Except the speed warp nodes (free one on marketplace) used to cause the editor to crash after a while (likely a memory leak).

I would suggest you extract the animation and do the math.

Measure the widest step. Check how many steps the anim cycle takes.
add the distance, divide by the time.