Orient Rotation to Movement Issue

[RodericDarkwell]

I´m making a a system in my project where the player is able to change between third person to first person willing while playing with no need to change anything in the definitions and I had to uncheck the Orient Rotation to Movement so that I could have the effect I wanted on the First person view with no issues… but now my Third person view doesnt rotate or move properly… does anyone know how I could fix this without having the Orient Rotation Movement ON?

[gardian206]

is this in C++ or blueprints?
can you show an example of what you are currently doing in both directions?

could you set the value as part of your function/event?
does your ThirdPersonCamera have the SpringArmComponent (“CameraBoom”)

are you trying to do this with 1 camera or 2? (the 1 camera approach is not impossible but it gets very special very quickly, while the 2 camera approach has a little bit more book-keeping)

[gardian206]

an example of a 2 camera approach (where the “camera moves” between 1st and 3rd person perspective)
a “ThirdPersonCamera” would be setup on the SpringArmComponent and there would be a second “FirstPersonCamera”

if we assume we start in Third-Person-Mode. when the player triggers the switch into First-Person-Mode:

• the transform of the “FirstPersonCamera” is set to the transform of the Third-Person-Camera
• the active camera is switched to the “FirstPersonCamera” (there should be no need to blink the screen if the transforms and frustum setting are “the same”)
• the “FirstPersonCamera” is the moved into position through some kind of Lerp() type function (this might mean having a SceneComponent Parented to the Pawns Root with the desired offset of the “FirstPersonCamera”)

reversing the steps is almost trivial.
the Reason to use 2 different cameras might not be the Orientation of the Camera itself, but rather a “ThirdPersonCamera” typically using a “SpringArmComponent”, that requires doing SetupAttachment(), or breaking attachments which can get messy.

[RodericDarkwell]

Hello friend! Sorry for the late reply… It´s a Blueprint two camera system and I start from Third Person to First Person In-Game, and the Third Person camera has a springarm yes.

[RodericDarkwell]

A second First Person Camera on the springarm of the Third Person Camera? I should do that?
That´s another problem I´m having… I want a smooth transition on the switching if cameras but all my attempts were “choppy” so I ended up discarding it till I find a way to do it right.
So I need to take of the springarm of the Third Person Camera? I´m quite new at this so I´m quite blind here…

[gardian206]

the approach I was describing would only be 2 cameras:
1 third person camera attached to the character via a spring arm
1 other camera that shall be the first person camera, but will also be the one transitioning between the transform of the Third person camera and its desired location as a first person camera.

maybe try looking for "unreal engine third person aim down sights" (this is a semi-common application for what you are describing) I see a few videos that might give you some other ideas, or a setup that could help.

as most of these should end up being something to the effect of “I have a third person camera, but I need to put a camera at that other point, and be able to get it back”
breaking and reattaching the “SpringArmComponent” (Camera Boom) setup is not impossible, but it can get really messy, so an additional camera is often “easier” even though it needs more specific book-keeping.

[RodericDarkwell]

Well… after a lot of trying… I can´t get anywhere! What if I want to have the third person camera transion to the first person camera by scrolling with the mouse wheel? Is it possible to do that with a two camera situation? cause all the videos I´ve seen It´s always a one camera scenario…

[gardian206]

probably spent a bit too long on this, but I was able to come up with this for a 2 camera setup:
started with 3rd person template
added Input Action IA_Scroll Value Type = Axis1D
added IA_Scroll to Default Mapping Context setting “Mouse Wheel Axis” (you can add a modifier of negate if you really want scroll down to be zoom in)
in BP_ThirdPersonCharacter
*added SceneComponent (“FirstPersonTarget”) attached to Capsule Component (as this is technically the ROOT) Location = (10, 0, 50)
*added CameraComponent (“MovingCamera”) attached to CameraBoom (this is so I get the controller rotation for free)

CameraIncrement = 5 as default value (you don’t “need” this but I like the sanity)

I kind of apologize for my spaghetti I prefer code a bit more:
the print string was for me validating

when you set the transform matters, and because the Follow Camera is majorly controlled by a spring arm you need to work in world space.

it is not just doing the “opposite” of the zoom in directly

then to save some spaghetti I made this a function

there are some optimizations that can be made:

• do the repositioning based on the CameraDistance in Tick() because this will currently not update if the spring arm gets shifted.
• always set the MovingCamera to the FollowCamera Transform, then teleport it to the percentage point along the vector
• it might save the float conversion to keep the CameraDistance as a float instead of an int, but then the compares become fuzzy due to floating point approximation.

[RodericDarkwell]

I can´t thank you enough for the work you´re making!!

I actually have the First person Camera on the Mesh attached to the head of the character ( attempting a more realistic first person view), I don´t know if that would be a issue here.

I did two enchanced inputs, one for zoom in and another for zoom out, Not sure If It would be the best approach or it should be only in one input.

Before seeing your work I tried following many videos and forum to try and find a way to do this correctly and I ended making two functions ( zoomIn and zoomOut ), the scrolling mechanic works fine but the transition of both cameras is still “snappy” when I was trying to do a smooth transition between the two.

I´ll be trying the method you presented cause It´s quite promising, not sure I will be reaching the goal here, but to be honest right now I´ll try anything to reach the result I´m looking for since my main issue for now it´s this and not being able to change the orient rotation to movement manually ( in blueprint ).
I´m quite sorry for any confusion I may be giving.

Plus I´ll try to answer faster this time around sorry for the delay.

[gardian206]

if you want the “realism” of the first person camera in the head then you can move the FirstPersonTarget to be located in the head; just keep in mind that many games for say First person Shooters the camera is closer to between the breasts/pectorals, and maybe as high up as the bottom of the neck (unless you want to believe the character is in a perpetual lean forward position for the entire game), and some “old school games” almost have the camera in the bellybutton (Duke can kick how high?)

you can also add a Socket to the player character Skeletal Mesh, to accommodate for say crouching or laying prone; such that those animation deforms would be applied to the sockets as well.

for 2 input actions vs 1, that is a “up to you” thing where 2 is more deliberate/explicit (it “should” be impossible for a single mouse to be sending both scroll up and scroll down on the same game loop tick), with 2 input Actions if you give the player the ability to rebind they could bind each to something else and then hit both at once causing a potential random outcome.

for “smoothness” of effect you either need more granular increments (I was going by 5% steps which can still have some visible steps, a 1% or even .5% would be less apparent but is most steps to cycle through), unless you have a camera physically move you will always get some kind of jump.

you can minimize how abrupt that jump is even for 2 cameras that are relatively static by just “blinking the camera”:
set the current camera to active = false then fire off a delay of like 0.01 then set the other camera to active = true (be sure to SetViewTarget() whenever you change cameras) even though it is a really short amount of time (about 100 fps) to the viewer it will be a long enough to prevent a nauseating sensation if they are prone to motion sickness. regardless of how high fps a person believes they are able to see just a single frame of black is often long enough to prevent that motion sick nausea (though it will cause a full discard re-calc on the entire scene, but that might happen on a camera switch anyways)