I am about to tweak the animations for our game (BattleArena), when I stumbled across an oddity which seems to be caused by the locomotion direction. With the current setup I calculate the direction variable like this:
But when I debug that value it ranges from 0 to 180 (forward) and from -90 to 90 (right, which seems fine). I would expect the forward direction to range from -90 to 90*. Thats also how I set up my Blendspace, and that is probably why I have the bug I am after.
Make sure your skeletal meshes are pointing in X+ in your blueprints. X+ is forward in Unreal. If you import something from Maya, the mesh will face Y+. Which means you have to rotate it 90 degrees in the engine after adding it to the blueprint. This is the case with the blue guy in all of epics examples and not something unusual.
I use kb and mouse, only have in place animations and I don´t have “45 degrees” movement animations. Only forward, backward, left strafe, right strafe and idle. My current blendspace looks like this:
You also answered on the other thread, where I commented. This is the bug I am trying to fix. The funny thing is, that the blend of forward and strafe works for one side, but not for the other (like the other thread mentioned). But the working side does not get more information for blending than the other?
As purely input as I still can’t read into it what kind of control you are after and just ramble on a bit.
First whats a bit confusing is you are breaking out the rotation of the mouse and feeding it into a blend space as a means of direction control, by the looks of it. Normally the reason to break out the pitch and yaw is to feed it into the AimOffset blend space that can interpolate with in the blend space.
A normal 2d blend space on the other hand can only interpolate at run time based on a fixed value so if you are feeding in the digital value of a mouse you could land up with a conflict with what the character blue print has built in already.
By default the 2d blend space wants a fixed value and you only need to set the target weight interpolate speed and the direction blends are done for you. Not saying don’t do it but a mouse generally does not rest at zero and is unpredictable the best of times.
Then as a though.
There is a problem that could be introduced called gimble lock. Since you are doing a 360 from one extreme to another once you pass from 360 to zero then the output values will want to flip and it has happen to me a few times.
Is there a reason to directly control direction using a mouse in this manner as the character blueprint can do this for you already?
As an opinion.
You don’t need to use large values and I’ve found using smaller numbers behave much better.
Sure but as an after thought looking at the blueprint your feeding a single value into what at it’s core is a 2 dimensional array. Try a 1d blend space instead.
