Hi, I am having trouble with my blend tree(s). The way I currently have mine setup is where my speed parameter handles walking, jogging, and running transitions in a blendtree.
When my player is moving the transitions between walk, jog, and run is pretty exact in how I want it to behave, but when I let go of my input floats (W,A,S,D) the player transitions to idle immediately. I want there to be a momentum effect from run to idle (run → jog → walk → idle).
How can I do this without using multiple blendtrees and transitions?
My scripts handle the move state and target speed to get the parameter to adjust accordingly, so i don’t think that’s an issue, I’ll probably have to change some things depending on the replies I get.
Since the input method is 0-1 on/off I don’t know if you can decrease the momentum - unless you code in some logic to say - if input goes from run 1 to idle 0 transition through jog and walk into idle.
If the input was using a joystick I think this could be done slightly easier, but the code would still have to be kinda ‘smart’ to understand the ramp from full run to no motion has to transition through jog and walk.
Disclaimer - I’m an animator not a coder - so I could be totally wrong.
Thanks for the reply! You do bring up valid things to think about, I’m noticing that because my input floats (W,A,S,D) return to (0,0), which is idle in the blend tree, it is impossible to make run animations go through it’s jogging/walking counterpart (i.e. forward, backward, etc). I’m looking into state machine behaviors to see where it goes but who knows
The easiest solution is to buffer the player input in the input controller so you can control the rate of change before passing it to the animation controller. You could use a curve field to define the acceleration / deceleration curves or just a simple lerp based system. So although the input would be 0 or 1, the actual float used by the animator would come from that math rather than the direct input.
As others mentioned, the best thing I’ve found is to separate the input and the actual parameters by one degree.
Have a check for the input against the current parameter value (i.e. is my input higher than my current speed), and then lerp to that value.
So for example, you’re fully idle and you press W. The input goes to 1, the system then lerps to that value (increases over time). This means the character which actually blend as the parameter increases. Flip this for slowing down, if the input value is less than the parameter (i.e. you press S to move backwards), then lerp the parameter to the value of the input
