I’m trying to break up the player’s velocity vector in to it’s basic components so I can use the (x,y) values to drive forward and lateral movement… my blend space animation looks like this:
So in my animation graph I want to extract the x-component of the velocity and use that for the ForwardMovement, the y-component for the LateralMovement; at least that’s how I assume I should be going about this.
Now in the event graph for the character’s animation blueprint, each tick I’m trying to grab the character’s velocity vector, rotate it by the character’s current rotation and then extract the x-component so I can set the current ForwardMovement variable… but I’m clearly doing something wrong:
This works if the character is moving backwards or forwards in the x-axis, but not if I start the game (from the editor) facing down any other axis (or combination of axes). In the event graph I’m dividing the x-component of the rotated vector by the max-speed of the character as the blend space is using the (-1, 1) range.
Anything obvious I’m doing wrong here? Must be the way I’m trying to rotate the velocity vector of the character, but using the raw velocity vector doesn’t really produce anything usable.
What is confusing is I don’t know why you want to combined rotation and velocity as a means of player control when the ability is already built into the design usage of one or the other. In an in-place set up it’s the movement component that controls speed and direction. For rotation (direction?) just lock the cameras yaw and the player will move off in the direction the movement component is facing. Velocity as a get function is generally used to change the animation rate to match the velocity change of the movement component with in the Blend Space.
As well
The Blueprint suggests that you are using in place where the Blend Space suggests that you are using Root Motion.
I’m probably going about this in completely the wrong manner, but my reasoning for the rotation was I wanted the velocity vector to be relative to the direction the camera is facing… the idea being that I drive the ‘Forward’ variable of the blendspace with the x-component, and the ‘Lateral’ variable of the blendspace with the y-component.
If I just drop the player in to the game (from the editor) so the camera is pointing directly down the y-axis, moving the character forward doesn’t affect the x-component of the velocity vector (as expected)… hence the attempt at rotation.
The actual movement for the player works without any problems at all as I do that from code (I’m relatively new to Unreal, and this is the first blendspace and animation system I’ve tried to build)… I’m just trying to drive the animation blend space by the velocity.
Really what I want is to be able to push forward on the controller (or other input method, keyboard for instance) and blend between walk & run, pull back on the controller and blend between the ‘walk/run back’ animations, and combine that with my strafing animations (with the left/right movement on the controller).
Managed to get the desired effect by modifying both the blend space and the event graph for the animation blueprint.
I’ve set up the blend space so the x-component is ‘direction’ and the y-component is ‘speed’. Direction goes from -180 to 180: -180 the player is considered to be moving backwards, the same with 180. 90 & -90 are considered strafing:
I’m now calculating the direction of the player in the event graph by feeding the base rotation and velocity and rotation of the actor in to a ‘calculate direction’ node:
As the animator for our team I do cringe as to the idea of using procedurally driven solutions as to game speeds where the solution of velocity corrections could be done in the blend space.
As a premier a blend space is just an array containing an address for a given animation set.
Something I did way back when as proof of concept.
What you might be interested in is near the end as although changing the scale of a run to walk speed can be done using velocity the result would look more like a bullet time effect as compared to a clamped value that says use this animation at this address in the blend space that just happens to be a walk cycle, or crouched cycle or prone cycle or ect ect.
Im not a fan of the Idea of having the direction in angles rather than vectors… Unless you accept the fact that your character will snap to face new input directions rather than softly blend, youll have to come up with a way of interpolating them stable.
Otherwise if you have big changes in direction your character is gonna play the entire range to reach that going through 0. Like if move upRight (45 degrees), then suddeny switch to bwdLeft (-135 degrees), the values will go all the way back to 0, -45, -90 till reaching the -135 leading you with a very wired motion while changing direction. This wouldnt happen if you do the interpolation on vector level.
I dont have an editor nearby now, but does anyone know or can try if the RInterpolate (clamped or not?) goes through ±180 and flips there if the current and target values are closer to those values than to 0?
Yeah that’s exactly why I wanted to have the animation driven by the velocity vector… but I couldn’t seem to get it oriented to the camera’s view direction.
This is working for the moment though. I’m no animator (coder by trade), so it’ll serve it’s purpose for the moment while I get the actual game play systems in place. If I can get smooth transitions between animations running though, I certainly wouldn’t complain
Hey, just if you still want it, I did set up a thing like you wanted for my own project now… here it is:
Basically you get the velocity vector, and like negInfinity stated calculate the dotproduct against actor rotation forward and right vector to get its relative signed direction and magnitude.
(also this setup could be optimized even more by shifting around some nodes and removing redundant stuff… but Ill leave that up to you. Also dont mind the lines going off, thats for non related or outdated stuff… need to cleanup haha)
One thing to keep in mind, in order to successfully work with variable speeds, like walk and run, youll have to have either a customMaxWalkSpeed variable, or a movementMode variable that you can multiply the output with. Ideally you would set that mode with your walk and run states in the chracterBP.
Like what I do, my walk mode is 0.5, my run mode is 1.5 and my spring is 2. So when I multiply the output of the above graph with those values, I can get the correct areas of the blendSpaces according to the current movement mode.
