Locomotion not driven by Velocity?

Hi there,

I am thinking that I am going to need a pretty precise locomotion system for my character. I would like to avoid the kind of animation where he sort of slides forward and the feet sort of almost plant correctly but actually looks pretty slidey.
This must come from the velocity driven nature of many setups like the example ones. Where the forward motion does not match precicely the forward motion of the animation clip.

Does anyone know of any example to look at where I just get the characters directional translation from the actual animation clip itself?

Or would it be preferable to use some kind of IK feet locking mechanism? That sounds too me very fiddely to set up.

Cheers

Skating as it’s called is a typical problem of using in-place animation glued to a movement component so it’s the bounding box (capsule) that determines the movement, speed, and direction and the player model and animations are just along for the ride as a puppet inside a box. The problem with this is the movement component out of the box with out modification moves at a constant velocity so the in-place animations has to be back keyed to account for loss of velocity of any animations that are not driven by physics, or [in air].

So the solutions to fix an annoyance like feet skating using IK or some other voodoo magic trick is a band aid of a much bigger problem of converting the constant of the capsule to the non-linear nature of character movement dynamics where the animations by themselves can not supply the micro velocity changes you would need if the plan is for a “precise locomotion system”

As a matter of fact yes there is a feature of UE4 called “root motion”.

As a data set root motion driven animation contains data in two parts. The actual animation determines speed at non-constant velocity’s where the root determines placement in 3d space as well as direction changes that since it can be directly driven by controller input does not suffer from the skating problems associated with in-place>movement component connections.

The down side.

The concept of root motion has yet to establish a sound knowledge base as compared to the ease of use of a movement component that has been around forever so a lot of the key requirements offered by the movement component would have to be duplicated as part of the event or anim graph.

Opinion time.

Either case Root Motion is the future still to be proven and animators love the “concept” as RM give them complete control over game speeds and movement dynamics, not to be confused with physics, and the majority use in-place because the movement component makes the process as a function easier.

Now if Epic would toss in a Root Motion Component that would be a good thing :wink: