How To Prevent Camera From Following Animations Ue4

(This article is a reprint from the original posted on my blog)

I decided to share the method I use in my current projection to handle my true kickoff person photographic camera. There is little to no documentation on this specific type of get-go person view, and so after looking into the discipline for a while I wanted to write about it. Specially since I had a few issues which took me a bit of time to resolve. The end result looks something like that :

True Beginning Person ?

What do we phone call "True Outset Person" (or TFP) ? It tin also be called "Body Awareness" in some occasions. Information technology's basically a camera that when used in a Showtime Person bespeak of view is attached to a an animated torso to simulate realistic body movements of the played grapheme, contrary to a unproblematic floating photographic camera. Hither are a few examples of games having this kind of camera :

(The Chronicles of Riddick: Assault on Nighttime Athena)

(Syndicate)

(Mirror'south Border)

(Mirror's Border)

What I'm not doing : carve up body and arms

In a carve up system, the ii artillery of the character are independent and attached directly to the photographic camera. This allows to directly animate the arms in any situations while being sure it follows the photographic camera rotation and position at all fourth dimension. The rest of the body is usually an independent mesh that has its own set of animations. One of the problem of this setup is performing total torso animations (like a autumn reception) as it requires to synchronize properly the ii split animations (both when authoring the animation and playing them in-engine). Sometimes games employ a torso mesh that is only visible to the player, while a full body version is used for cartoon the shadows on the ground (and visible to other players in multiplayer, this is the cas in recent Phone call of Duty games). This can be appropriate in order to optimize further, notwithstanding if fidelity is the goal I wouldn't recommend it. I won't go in details near this method as it wasn't what I was looking for. Too at that place is already tons of tutorials on this kind of setup out in that location.

Full-body mesh setup

As a full-body mesh suggests we employ only one mesh to represent the character. The camera is attached to the head, which means the body blitheness drives it. We never change the camera position or rotation straight. The grade hierarchy can be seen as this :

PlayerControler   -> Character      -> Mesh         -> AnimBlueprint         -> Camera

The PlayerController can always be seen on elevation of the Character (or Pawn) in Unreal, so this is zero new here. The Character has a mesh, here a skeletal mesh of the body, which has an AnimBlueprint to manage the diverse animations and blending. Finally nosotros have the camera, which is fastened to the mesh in the constructor. Then the Camera is fastened to the mesh, are we washed ? Of course not. Since the camera is driven by the mesh, we have to modify/animate the mesh to simulate the usual camera movements : looking upwards/downwards and left/right. This is done past creating additive animation (ane frame blitheness) that will be used as offsets from a base animation (1 frame as well). In total I use ten animations. You lot can add more poses if you want the grapheme to look backside itself but I found it wasn't necessary in the end. In my example I rotate the body when the player photographic camera look at his left or right (like in the Mirror's Border gif above). There is an additional animation for the idle as well, which is applied on top of all these poses. For me information technology looks like this :

One time those animations are imported into Unreal nosotros have to setup a few things. Be sure sure to proper name the base pose blitheness properly to observe it dorsum easily afterward. In my instance I named it "anim_idle_additive_base". Then for the other poses I opened the animation and changed a few backdrop under the "Additive Settings" department. I set the parameter "Additive Anim Type" to "Mesh infinite" and the parameter "Base Pose Blazon" to "Selected Blitheness". Finally in the asset slot underneath I loaded my base of operations pose animation. Echo this process for every pose.

Now that the animations are ready, it is time to create an "Aim Outset". An Aim Commencement is an asset that store references to multiple animations and allow to easily blend between them based on input parameters. The resulting blitheness is then added on height of existing animation in the Blitheness graph (such as running, walking, etc). For more more than details accept a look at the documentation : Aim Offset. Once combined, here is what the animation blending looks like :

My Aim Offset takes two parameters as input : the Pitch and the Yaw. These values are driven by variables updated in the game lawmaking. See beneath for the details

Updating the animation blending

To update the animation, y'all have to convert the inputs fabricated the player into a value that is understandable past the Aim Offset. I practice it in three specific steps :

Converting the input into a rotation value in the PlayerController course
Converting the rotation which is world based into a local rotation corporeality in the Character course.
Updating the AnimBlueprint based on the local rotation values.

Step ane : PlayerController input

When the actor move its mouse or gamepad control I take the input into account in the PlayerController course and update the Controller rotation (by overriding the UpdateRotation() function :

void AExedrePlayerController::UpdateRotation(float DeltaTime) { 	if( !IsCameraInputEnabled() ) 		return;  	float Fourth dimension = DeltaTime * (1 / GetActorTimeDilation()); 	FRotator DeltaRot(0,0,0);  	DeltaRot.Yaw	= GetPlayerCameraInput().10 * (ViewYawSpeed * Fourth dimension); 	DeltaRot.Pitch	= GetPlayerCameraInput().Y * (ViewPitchSpeed * Fourth dimension); 	DeltaRot.Curlicue   = 0.0f;  	RotationInput = DeltaRot;  	Super::UpdateRotation(DeltaTime); }

Notes : UpdateRotation() is called every Tick by the PlayerController class. I accept into business relationship the GetActorTimeDilation() so that the camera rotation is non slowed down when using the "slomo" console command.

Step ii : Photographic camera local rotation in Character

My Character class has a office named "PreUpdateCamera()" which more often than not exercise the post-obit :

void AExedreCharacter::PreUpdateCamera( float DeltaTime ) { 	if( !FirstPersonCameraComponent || !EPC || !EMC ) 		return; 	//------------------------------------------------------- 	// Compute rotation for Mesh AIM Offset 	//------------------------------------------------------- 	FRotator ControllerRotation = EPC->GetControlRotation(); 	FRotator NewRotation 		= ControllerRotation;  	// Get current controller rotation and procedure it to match the Character 	NewRotation.Yaw 			= CameraProcessYaw( ControllerRotation.Yaw ); 	NewRotation.Pitch 			= CameraProcessPitch( ControllerRotation.Pitch + RecoilOffset ); 	NewRotation.Normalize();  	// Clamp new rotation 	NewRotation.Pitch 	= FMath::Clench( NewRotation.Pitch, -90.0f + CameraTreshold, 90.0f - CameraTreshold); 	NewRotation.Yaw 	= FMath::Clamp( NewRotation.Yaw, -91.0f, 91.0f); 	 	//Update loca variable, will be retrived past AnimBlueprint 	CameraLocalRotation = NewRotation; }

The functions CameraProcessYaw() and CameraProcessPitch() convert the Controller rotation into local rotation values (since the controller rotation is not normalized and in World Infinite past default). Here is what these functions wait like :

float AExedreCharacter::CameraProcessPitch( float Input ) { 	//Recenter value 	if( Input > 269.99f ) 	{ 		Input -= 270.0f; 		Input = 90.0f - Input; 		Input *= -one.0f; 	}  	return Input; }  float AExedreCharacter::CameraProcessYaw( float Input ) { 	//Get direction vector from Controller and Character 	FVector Direction1 = GetActorRotation().Vector(); 	FVector Direction2 = FRotator(0.0f, Input, 0.0f).Vector(); 	 	//Compute the Angle difference betwixt the 2 dirrection 	float Bending = FMath::Acos( FVector::DotProduct(Direction1, Direction2) ); 	Angle = FMath::RadiansToDegrees( Bending );  	//Discover on which side is the angle difference (left or right) 	FRotator Temp = GetActorRotation() - FRotator(0.0f, xc.0f, 0.0f); 	FVector Direction3 = Temp.Vector();  	float Dot 	= FVector::DotProduct( Direction3, Direction2 );  	//Invert angle to switch side 	if( Dot > 0.0f ) 	{ 		Angle *= -1; 	}  	render Angle; }

Step 3 : AnimBlueprint update

The final footstep is the easiest. I call up the local rotation variable (with the "Result Blueprint Update Animation" node) and feed it to the AnimBlueprint which has the Aim Get-go :

Avoiding frame lag

I didn't mention it yet simply an effect may appear. If yous follow my guidelines and are non familiar with how Tick() functions operate in Unreal Engine, you lot volition come across a specific problem : a i frame delay. Information technology is quite ugly and very annoying to play with, potentially creating stiff discomfort. Basically the camera update volition ever be done with data from the previous frame (so late from the player point of view). It ways that if you motion your point of view quickly so suddenly cease, y'all will terminate only during the adjacent frame. Information technology volition create discontinuities, no matter the framerate in your game, and volition ever be visible (more or less consciously). It took me a while to figure out but there is a solution. To solve the consequence y'all accept to understand the order in which the Tick() part or each class is chosen. By default information technology is in the following order :

_____ UpdateTimeAndHandleMaxTickRate (Engine function) _____ Tick_PlayerController _____ Tick_SkeletalMeshComponent _____ Tick_AnimInstance _____ Tick_GameMode _____ Tick_Character _____ Tick_Camera

So what happens hither ? As you can encounter the Graphic symbol class updates afterwards the AnimInstance (which is basically the AnimBlueprint). This ways the local camera rotation will only be taken into account at the side by side global Tick, so the AnimBlueprint employ former values. To solve that I don't call my part "PreUpdateCamera()" mentioned before into the Character Tick() but instead at the end of the PlayerController Tick(). This manner I ensure that my rotation is up to date before the Mesh and its Animation are updated.

Playing montages

The base of the system should piece of work now. The next step is to exist able to play specific animations that tin be applied over the whole trunk. AnimMontages are great for that. The thought is to play an blitheness that override the current AnimBlueprint. And so in my instance I wanted to play a fall reception animation when hit the footing after falling a certain amount of time. Here is the blitheness I desire to play :

The code is relatively simple (and probably even easier in Blueprint) :

void AExedreCharacter::PlayAnimLanding() { 	if( MeshBody != nullptr ) 	{ 		if( EPC != nullptr ) 		{ 			EPC->SetMovementInputEnabled( false ); 			EPC->SetCameraInputEnabled( false ); 			EPC->ResetFallingTime(); 		} 		 		//Snap mesh 		FRotator TargetRotation = FRotator::ZeroRotator; 		 		if( EPC != nullptr ) 		{ 			TargetRotation.Yaw = EPC->GetControlRotation().Yaw; 		} 		else 		{ 			TargetRotation.Yaw = GetActorRotation().Yaw; 		}  		SetActorRotation( TargetRotation );   		//Beginning anim 		SetPerformingMontage(true);  		TotalMontageDuration = MeshBody->AnimScriptInstance->Montage_Play(AnmMtgLandingFall, i.0f); 		LatestMontageDuration = TotalMontageDuration;  		//Gear up Timer to the end of the duration 		FTimerHandle TimeHandler; 		this->GetWorldTimerManager().SetTimer(TimeHandler, this, &AExedreCharacter::PlayAnimLandingExit, TotalMontageDuration - 0.01f, false); 	} }

The idea here is to block the inputs of the player (EPC is my PlayerController) and then play the AnimMontage. I set a Timer to re-enable the inputs at the end of the animation. If you but do that, here is the result :

No exactly what I wanted. What happens hither is that my anim slot is setup before the Aim Offset node in my AnimBlueprint. Therefor when the full body animation is played the anim Showtime is added later on on pinnacle. So if I look at the footing and then play an animation where the head of the character look down besides, information technology doubles the amount of rotation practical to the head... which makes the graphic symbol look betwixt her legs in a strange way. Why doing the aim offset afterwards ? Only considering information technology allows me to blend in and out very nicely the camera rotation. If I applied the blitheness after, the alloy in time of the Montage would have been too harsh. Information technology would have been very difficult to balance between rapidly blending the body movement and doing a smooth fade on the head to non make the player sick. And then the play a trick on hither is to likewise reset the camera rotation in the lawmaking while a Montage is existence played. Nosotros tin can do that because the montage is disabling the histrion inputs. So information technology is safe to override the camera rotation. To do so I added few lines of lawmaking in the function "PreUpdateCamera()" that I mentioned earlier :

          //------------------------------------------------------- 	// Blend Pitch to 0.0 if nosotros are performing a montage (input are disabled) 	//------------------------------------------------------- 	if( IsPerformingMontage() ) 	{ 		//Reset camera rotation to 0 for when the Montage end 		FRotator TargetControl = EPC->GetControlRotation(); 		TargetControl.Pitch = 0.0f;  		float BlenSpeed = 300.0f;  		TargetControl = FMath::RInterpConstantTo( EPC->GetControlRotation(), TargetControl, DeltaTime, BlenSpeed);  		EPC->SetControlRotation( TargetControl ); 	}

These lines are chosen at the beginning of the function, before the local camera rotation is computed from the PlayerController rotation. What it does is that information technology simply resets the pitch to 0 over fourth dimension with the "RInterpConstantTo()" role. If y'all do that, here is the effect :

Much better ! :) It should be like shooting fish in a barrel to too save the initial pitch value and blend it back at the end of the montage animation to fix back the original player photographic camera angle. Nevertheless in my case information technology wasn't necessary for this animation.

Animation tip to avert motion sickness

Concluding matter to mention. When authoring fullbody animations it is important to be conscientious with the movements that happen to the head. Head bobbing, quick turns and other kind of fast animations can make people sick when playing. And then running, walking animations should be equally steady as possible. Even if in real-life people move, looking at a screen is different. This si similar to the kind of motion sickness that tin can arise with Virtual Reality. Information technology is usually related to the dissonance between what the human body feel versus what we come across. A fiddling play a trick on I utilize in my animations, mostly for my looping animation like running, is to apply a constraint on the grapheme head to always look at a specific betoken very far away. This style the head focus on a point that doesn't move and, beingness far away, stabilize the camera.

(I used an Aim constraint on the head controller in Maya)

Yous can then apply additional rotations on height to simulate a fleck the trunk motion. The advantage is that it's easier to get dorsum and tweak in case people become sick. You can even imaging adding these rotations in-game via code instead, then it can become an option that people disable. That's all !