Download

How to print out the velocity of the character based on the camera component's local axis?

I want to get the velocity (IN VECTOR NOTATION) of the character BASED ON THE CAMERA’S DIRECTION (which is looking directly towards the character). I don’t want the vector to be based off the world axis.

I’m using the third person character example which has a camera component already attached.

What I expect is NO MATTER WHERE I ORIENTATE MY CAMERA IN GAMEPLAY:

  • Whenever I push the forward button that is Up arrow or W key, the X-axis should always be 600 (600,0,0)
  • If I push backwards that is Down arrow or S key, the X-axis should be -600 (-600,0,0)
  • Strafe Left and Right with Left and Right arrow or A and D keys I should get 600 and -600 (0,600,0 or 0,-600,0) on the Y-axis.
  • Of course for diagonals say Forward Right I should get 300 on both X and Y axis (300,300,0).

So far I’ve tried this but doesn’t work.

Can anyone help me out on this matter?

Hi man , Please dont scream XD
can you do a little doodle? is hard to understand

Unrotate the velocity vector by the camera’s current rotation using the UnrotateVector node.

Hey Capsu1,

I tried my best to interpret and follow your suggestion; I did some research on how to get the current rotation of the camera in BP.

This is what I got:

Is this what you’ve exactly meant?

I tested it and the results are relatively close. So I rotate the camera component around the character, I do get results that are close to 600 and -600 on the X-axis and Y-axis based on the respective keys (W A S D) that I’ve pressed though there are numbers that display on the other axis.

Try this. The CMC by default never really returns true 0,0,0 etc on the axis after the camera has rotated at all for some reason; there will always be a tiny decimal left over when something should be 0 (most like due to floating point error). If you really need perfect “accuracy” in the sense that it’s a neat number how you want it, you might be able to use the function I put together in the last picture, with a tolerance set to like 0.005 or 0.01.



@Capsu1, I followed your suggestion and basically the results are better.

Regarding that piece of your quote.

As I was testing it out while I’m holding down the forward key or W, when I rotate the camera with the mouse and let go, I see numbers on the Y-axis but eventually it falls down to zero and of course X-axis is 600.

Overall I’m satisfied with the results so thanks for the help.

PS: If you still think that this can be further refined and you come up with something better, I look forward to testing it out. Now onto other matters in UE4.

How is the value used? Perhaps there is a better way to get what you need…

The idea behind using these values is so that when the character is still running while on deceleration the user is given certain movement options to either perform local side steps as well as applying the brakes. I’ll give you 2 examples after the second sentence.

In my BP I have 3 modes of movement for my character for analog buttons/sticks. 1 of the 3 is the sprint mode where any velocity >= 600 / 1.75 is considered a sprint.

I’ll give you two examples:

  1. While still running in the forward direction or positive X-axis direction, the user is limited to only doing side step to the left and right (by tapping the A and D keys or tapping the analog stick left and right fully to a scale of 1 of -1), gradually pressing the S or S & A or S & D keys or analog stick towards back, back left, or back right applies braking force and the brake force depends how deep/far you push/tilt them, but to tap these keys/stick would apply an abrupt braking force so it is as if he’s stopped instantly.
  2. Running forward right so in the positive X and Y-axis direction from the camera view, you have to tap W & A keys and S & D keys or tap the stick towards forward left and backward right to perform those side steps while in sprint mode. To brake would be by pressing S & A, A or D.

If you’re confused with example #2 just imagine a 4-way directional pad so like the one on a Nintendo controller, rotate it 45 degrees to the right and relate to the direction I was talking.

So, is the camera attached to the character or independent from it?
is the control rotation of the pawn inherited by the camera?

the rotation bit above makes sense to get a working vector. However you usually don’t need a working vector to push to ABP (ABP already knows almost everything it needs).

So, once again, how is the final value actually used?

You mention what you are trying achieve, but not where or how the variable comes into play.

Are you using it as add input, push force or what?

I know for sure it’s a component but I don’t think it’s attached; by attached I think you mean that character mesh is the parent of the camera and the camera should be indented to the right beneath Mesh. I think this pic will answer your question.
Capture.JPG](filedata/fetch?id=1821055&d=1602433968)

I am using it to limit the input of stepping in certain directions when in running mode; I have a dodge system where the character can quickly step in 8 directions and they all work when the character is standing or walking. Only when running the character can step in 2 of the 8 directions and that’s what I’ve mentioned in these 2 examples.

So just to reiterate the 1st example, when my character is moving between (600/1.75 and 600) and is upon deceleration in the X-axis I can only step left and right since he’s moving in the forward direction; I cannot step forward, forward left and forward right and if I were to push buttons that are opposite to 600 X-axis such as backward, backward left, and backward right, braking will be applied. But I think you’ve already mention that with ABP.

Does this answer enough your question?

Would you mind filming a short- provided there is no NDA concern-to share?

Its perhaps best to actually see what you mean to come up with a proper solution.

As far as the camera goes. Its still patented to the capsule component, but that doesn’t matter as much as the options on it for control rotation…