Hi.
I noticed root motion overrides the characters current velocity.
Is there a setting we can possible enable to retain the current velocity?
For example when a character is moving at 600 units on the Y value, and the root motion animation kicks in, velocity will be set to 0,0,0
Setting the velocity does not work… and launching a character does not work either. It ignores everything except the root motion.
Can it not be additive to some degree?
I think this should rather be a feature request to have Current Velocity added to the root motion velocity.
For the time being i moved away from montages with root motion and am instead forcing velocity and disabling user input while a current animation is playing.
Still would be really cool to have the ability to have a sort of additive velocity.
Well, if you are fine with working in code, then you can indeed just extract the root motion from and then apply it partially or in any other way you see fit. Though it is not a trivial task. If you have access to GDC Vault then you can look up this year’s talk by Avalanche Studios about their approach to mixed setup for character locomotion using direct input and root motion together.
Hey Crocopede,
I emailed some of our Engineers about this issue and it got a discussion going. They’d like to get some more info on your current issue to understand the use case a little better. Could you break down exactly what you’re trying to do for us?
Thanks,
Hi .
Cool stuff.
Lets go with a diveroll animation.
Your character is traveling at 600 units in a direction and you execute the diveroll action. Your characters velocity goes to 0, as this is the start of the root motion animation. And then proceeds to apply the velocity of the root motion that was extracted.
If your character is moving at slow speeds this is not a problem as it might go unnoticed.
But if traveling at highers speeds like a full sprint and you execute a montage the pause is very noticeable and also a bit unnatural considering you are moving really fast, dead stop and then roll at a much lower speed.
I tried compensating by adjusting my animation to have the root shoot extremely fast but there will always be that initial 0 velocity and then you are also having the same velocity regardless.
If there was the possibility to use some additive velocity it would make some animations better as it would eliminate those awkward pauses. Not only that but perhaps in some cases your character would have traveled 1800 units forward while doing the animation at its current velocity. But Now it only travels 900 units forward due to the velocity being overridden or forced from the root motion extraction.
But then there is the catch of not having it always enabled. Because in some or majority of use cases you would not want the velocity to be additive.
For example in my ledge climbing animations, additive velocity from the root would result in inaccurate animations and some parts not aligning. So i guess if this is something that is being considered its very important to take that into account.
That its not forced to be additive but rather an option. If you can control this bool or change it at runtime that would be even better. Because you can then have your montage playing and at frame 26 set the bool to false, that way restricting it to the original montages velocity. For example at the frame your feet touches the ground again.
I use montages in a lot of situations. For now when doing animations that looks better when using the current velocity i implement a simple bool and place a branch in front of all my input nodes so that keys don’t register while doing that specific animation and then also force movement in the direction you were traveling. Its not hard to implement, but it would make life just a tiny bit more convenient working with montages that has additive velocity. And truthfully its only the one animation i have that would have benefited from this feature.
I hope this explains my use case a little better.
Humm well root motion is a self contained data set as being non-linear as to motion that is not physics based. If the player leaves the ground or preforms an action that is linear based on a physics then best to turn off root motion and just let the capsule handle the vorticity.
Now if I’m reading right the problem is timing and since velocity is built into the data one would only need to change the animation scale and pass on the scale var to the next set of animations as part of a match set of actions to make the player move faster or slower and correct the timing of anything that comes afterwards by polling the current scale.
But yeah UE4 does support additive animations but don’t expect to get linear motion from one blend into another with out an ease in and ease out as to the current state.
Work in progress.
Going from a full sprint to an idle the animation “will” pop but to correct the problem the animation “has” to first past through the additive ease out to bring it to rest.
So for each action you will need also need an ease in and ease out as to any change in the animation state as no amount of blending is going to solve the problem.
Short answer I guess is you don’t need to change this animation or that animation but what comes before or after. 
I wonder if this is your problem. Could you try to not disable your movement keys? (WASD)
Root Motion from Montages will be enabled after the montage is ticked.
The first frame it looks like this:
Second frame looks like this:
If you cut off input too soon, that first frame may think you’ve stopped moving.
If that is the issue, I would recommend disabling input based on whether root motion is playing, instead of whether your montage is playing. As root motion will only be ‘active’ after the animation update of the first frame you montage is played.
Hopefully that makes sense. 
Cool stuff. I didnt know thats how it works. Pretty neat.
I only apply force movement when not working with montages.
Will create a video demonstrating what i experience in my use case. Most likely only have it done tomorrow… looong. Gonna crash now.
Thx for the feedback.