It seems it’s a known issue but I can’t find a Fix for it.
When trying to set the Third person character with an attach camera and a use pawn control rotation, the animation glitch when running backward (a lot of interpolation show that the character does not go straight, trying to use the Jog right or left animation).
Can’t find a solution for now, same issue in all my third person games,
Controller Desired Rotation and Orient Rotation in character movement are uncheked, Root motion enabled for everything in the Anim BP.
Can I lock the character Direction to -180 or 180 when running backward ?
Ugg… Can’t find a solution for this one anywhere. Recap: Third person, running backwards(hold ‘s’), locomotion blendspace using interpolation > 0, and you get jitters. For some reason running backwards doesn’t lock itself to 180 or -180, it bounces from back and forth between the two give or take a degree, and because interpolation is turned on you get the jitters. Us non-programmer types could really use some help with this.
What’s your blendspace / animation blueprint look like? I had that issue and it was frustrating beyond belief. I can’t quite recall how I fixed it but maybe I can take a look at your setup and help you out.
First off yes it’s a common issue but it’s origin is with the intent of the design and not as to a solution to the jitter that is occurring as the final pose.
The main issue is when casting for the float values directly from the movement component the required value is not a fixed value as to the current state and can fluctuate but a large margin. If in your blend space the direction value for a backwards run take to be triggered is -180 is extrapolated from velocity the output from the blendspace can and usually does jump around based on the unstable value usually generated by the velocity as it interacts with world space.
This is where it’s know to be a common issue as a blendspace usually does not take into fact world iteration as to the need for a constant change base on direction.
The most common mistake is to mix to different control requirements for consoles, using joysticks and PC’s, using keyboard and mouse, and then triggering state changes based on speed.
Speed is only need where velocity as in a racing game for example is required so that the non-constant state of velocity can be changed but is of no help.
Working with Locomotion however does not benefit from non-stable values like velocity except to track if the player is moving or not as to a value to feed into a blendspace as to the intended output state.
This is where we get into design theory and why questions like this is not easy to answer as an issue it’s really easy to figure out what is causing the issue but not easy to answers as to the design intent.
The most direct answer to the problem, excluding design intent as well as the need for replication, is to directly feed a fixed value into the blendspace as to the intended output.
The most common control for Locomotion is the WASD keys which you can set up with any fixed value you wish in the input table.
They could be
Forwards/Backwards
W =1
S =-1
Left/Right
A=1
D=-1
Your blendspace axis would be set up as Forwards_Backwards in the vertical
and
Left_Right in the horizontal.
With this set up you will be feeding a fixed and absolute value as to the needed state change and not based on the almost at times random behavior of the movement component.
The easiest and most reliable solution is to remove the blendspace for the back motion and isolate the backwards animation in a 2d blend with just the speed input and relative frames.
You just have your state machine govern the rules for transition to the back animation based on an angular range instead above 0 less then 10, above -170 less then -180 for instance.
it works very much like the blendspace would, except you won’t have any angle issues when transitioning between 0 and -180 because the “backwards” state will remain active.
Hey, just wanted to say thanks!
Setting the interpolation time from 0.0s to 0.3s (in your image you set it to 0.2s) on Vertical Axis (Speed) fixed the issue for me.
On my side, I used a very good pack of anims, but for some reason the strafe right animation would be troublesome, doing some jittery movement for no good reason.
The interpolation time fixed it. Magic.
