Hey guys, im using the third person blueprint template, whats the best way to make the camera automatically turn itself to the direction of the player in the blueprint, kinda a newb when it come to characters?
Thanks guys
I think tutorial is explaining what you are searching for: ?v=UMcmqsMzcFg
1 Like
If it were me, I’d do it like :
I’d Get my controller rotation
I’d Get my actor rotation
I’d get the delta rot between them
I’d break that into Roll/Pitch/Yaw
I’d do a floatfloat on the Yaw and multiply it by 0.05 or something similar
I’d connect AddYawInput after both of my movement events and feed it the value coming off of Yaw0.05
If I’m right (and I’d have to try it to be sure), the camera should start continually adding a percentage of the difference between the way it’s facing and the way the character is facing every time the player starts moving. The camera would interpolate to the position with a curve where it sort of wheeled about when the player was facing really far from the look direction, but would only make very very subtle changes once the camera got close to the direction the player was facing. Of course it would theoretically never GET to the player’s rotation (just very close) but eventually rounding errors would correct that.
- thanks dude saw that one, he applied it to a button though, im conectrating on mobile atm, suppose it can work without one
@Rhythmn- thanks dude ill try it out tomorrow!
You can choose any event you like e.g event tick,… 
very true!
Well got it working great in third person, thought i would replicate it in the rolling as thats gonna be my project, i modified the vid link above a bit to work in the rolling template, but ran into problems i need it working on forward/back and right/left axis, i think i set it up properly, and separately they work, but together they don’t, one cancels the other, dont know where i went wrong, i done a vid with my blueprint on it ?v=c5PVDJklt0g, any ideas?
Thank you all in thread. I’m working on a 3rd person perspective racing game and thanks to the info in thread, have managed to get my vehicle game working with a Camera/SpringArm that uses the ControlRotation on the SpringArm, and now smoothly snaps itself back behind the car when there is no user input trying to move the camera on the x or y axis, exactly what I needed!
Still needs a bit more polishing, but the functionality works great. RythmScript - I followed your breakdown and it almost worked first try, however I had to toil over the vehicle specific things, but thank you for posting that info, it sent me in the right direction!
jdsb52: I will play around with it on my end and see if I can figure out a way to help, a ball rolling game is much different than mine. The only thing I can think of is whenever you push the gamepad stick in a certain direction to move the ball, try to make the camera look in the same direction as the movement, then the camera would always be behind the ball. I’ll try again tomorrow if there is any other things I can think of (I’m on GMT -8hrs), but hopefully I will catch you online and try some things.
Once I get it more polished tomorrow I will post a quick tutorial with the blueprint in the tutorials forum for any others interested in doing with a vehicle game. And I will make sure people know who helped out! Thanks again!
Thanks dude and yeah i stay up pretty late anyway so may catch you, gonna try modifying it today like you said to get it working
Hmm tried separating the auto adjust camera in in 2 one for forward/back and one for right/left, forward and back still override!
Sorry for not being able to get up and running today, I ran into a couple of issues… My pitch value wasn’t stopping where it should have, but happens very slowly so I think it just needs some tlc
However I thought I would post screenshot here for you in case it helps you out, and will be doing a more in depth write-up of soon.
Here is the BP I added to my player pawn (vehicle in my case):
&stc=1
*EDIT: Ahhh! now that I post it it looks all messed up, the two “Less Than” operators above should be “Greater Than”… I thought I had saved stuff… sorry it is not quite right, but I’m too tired, will fix it up in the morning…
Hope that helps a bit!
Is there a reason yaw gets multiplied by 0.05 (i.e. it applies 5% of the delta to the yaw input), but pitch instead is 0.05 divided by pitch input?
Have you tried making that a multiplier function, same with the Yaw, and seeing if that fixes it?
Thanks dude, looks good and yeah might help, i got two days before i go on holiday friday, might try and get it done by then
Yeah I have tried that, it was how I had it set up originally but was causing the pitch to go flying up or down at a high rate depending where I left the camera at with the thumbstick. I was testing random things, and does work pretty well as shown in the image above (with the division), it just slowly moves up or down based on where the camera was when I stopped giving input. I should have noted that better in the image.
Going to do some more testing today, and hopefully can get under control. I think the main is that I don’t want the camera to reset the pitch to 0, I want the camera to be slightly pointing down at the car from above at around 15 degrees above (like you see in Forza for example). I’ll do some more testing though and see what happens. Thanks for the input though, much appreciated!
Maybe instead of multiplying by 0.05, you could try to multiply by negative 0.05…?
The logic I gave you relies on the assumption that each impulse gets you closer to the target position; if the delta is the other way, and it gets you further, then every tick it will start wildly increasing the distance between them.
Anyway, if you want to get the camera to a position other than DIRECTLY behind the player, you just need to take your target rot (i.e. the character facing direction), break it, and then remake it with partially new values. i.e. Carry over the yaw value, but set the roll value to zero and the pitch value to your target downward angle. way what the rotation is trying to interpolate itself TO always has that constant pitch angle, and it only updates based on the yaw of your player’s facing direction.
Thank you for all your help RhythmScript, I finally worked it out yesterday in the afternoon, and forgot to come back here to report my findings, so here it goes.
At first I thought it was being caused by setting the CameraPitch input axis as “inverted” (I prefer it that way) was causing the values to go haywire, but I was pleasantly surprised that changing value has no effect on your blueprint setup, which means one less thing to worry about later when I create a menu to switch it, I don’t have to invert the value in the blueprint as well.
But in the end multiplying by a negative value fixed it, I also switched it over to multiply by “value * -0.75 * World Delta Seconds” and it gives it a much smoother transition, I will probably tweak the 0.75 value a bit to make it transition faster.
But thanks again for all your help! And Jdsb52: I will be adding the correct final setup above, I won’t delete the image, it will still be in the Attachments section, but the large image will be corrected.
I just wanted to bump to say that, in implementing similar functionality in my own game, I was able to get a far simpler setup using RInterpTo.
I simply plugged the actor rotation as the target and the control rotation as the start, and every tick (using the tick delta seconds for RInterpTo’s delta in) I Set Control Rotation using the output of RInterpTo.
Since the Actor rotation is constrained in certain ways (i.e. it never rolls or pitches, at least not when controlling a Character) only turns the camera left and right. You could also do a make-rot-break-rot to remove the roll or pitch manually if your actor could move in those ways.
It’s more elegant than the system I described previously ITT, since you can easily adjust the interpolation speed in an intuitive way by feeding any old float data to RInterpTo’s speed.