Skip to content

Set View Target with Blend

At a glance

Lives in: Blueprint API / Game / Player; target is a PlayerController - Returns: nothing - Changes: the actor the player's camera manager uses as its view target, optionally over a blend time - Can appear to fail by: targeting the wrong controller, passing the wrong actor, expecting possession/input to change, or having another camera system immediately take the view back - Official docs: Set View Target with Blend, APlayerController::SetViewTargetWithBlend, Cameras, and APlayerCameraManager

The one-minute version

  • Set View Target with Blend changes what a PlayerController looks through. It does not move the player, possess a pawn, switch input, or attach a camera.
  • The New View Target pin wants an Actor, not a CameraComponent. A CameraActor works because it is an actor with a camera. A pawn or custom actor can also work if its camera setup is the one you want viewed.
  • If the target actor has a usable CameraComponent, the camera manager can use that component's point of view. Otherwise the actor's own camera calculation or transform becomes the fallback.
  • A Blend Time of 0 is a hard cut. A longer time blends from the outgoing view to the new target. Blend Func, Blend Exp, and Lock Outgoing shape that transition.
  • View target is not possession. If the controller is still possessing the old pawn, input still drives the old pawn while the camera looks somewhere else.

What it actually does

Each local player has a PlayerController. That controller owns camera-facing decisions through a PlayerCameraManager. The camera manager keeps track of the current view target and, during a blend, a pending view target.

At beginner altitude, the relationship is:

flowchart LR
    PC[PlayerController] --> PCM[PlayerCameraManager]
    PCM --> Current[Current view target actor]
    PCM -. blend .-> Pending[Pending view target actor]
    Current --> POV[Final player view]
    Pending --> POV

Set View Target with Blend tells the controller:

pseudocode of the behavior - not engine source

PlayerController.SetViewTargetWithBlend(NewViewTarget, BlendTime, BlendFunc):
    CameraManager starts using NewViewTarget as the desired view target

    if BlendTime is 0:
        final view cuts to the new target now
    else:
        final view blends from the outgoing point of view to the new target
        until the blend is complete

The important part: the view target is an actor-level camera source. You are not saying "activate this camera component directly." You are saying "this controller should now view through that actor."

The pins that matter

Pin Meaning
Target The PlayerController whose view should change. In a custom PlayerController Blueprint, this is usually Self.
New View Target The actor to view through. Common choices are a CameraActor, the player's pawn, or a custom actor that owns a CameraComponent.
Blend Time Seconds spent transitioning. 0 cuts instantly.
Blend Func The curve style used by the transition: linear, ease in, ease out, ease in/out, or other available view-target blend functions.
Blend Exp Extra exponent used by blend functions that need a curve strength. Higher values make the easing shape more pronounced.
Lock Outgoing Keeps the outgoing camera point of view fixed during the blend instead of continuing to update it while blending away.

The node has only an execution output. It does not return the camera it chose, the previous view target, or a success flag.

What counts as a view target?

The pin type is Actor. That makes the node more flexible than it first looks, but it also causes a common mistake: beginners try to plug in a camera component reference.

Use one of these instead:

Target actor What the camera manager can use
CameraActor placed in the level The CameraActor's camera component and camera settings.
Player pawn or character The pawn's camera setup, often a Spring Arm plus Camera Component.
Custom actor with a Camera Component That actor's camera component, when the actor is configured to find camera components as view targets.
Actor without a camera component The actor's camera calculation or actor transform fallback, which often looks like the view is at the actor's origin.

For a normal cutscene or death cam, the clean beginner setup is:

Place CameraActor in level
-> get reference to that CameraActor
-> Get Player Controller 0
-> Set View Target with Blend
   Target = PlayerController
   New View Target = CameraActor
   Blend Time = 0.75

To return to gameplay, set the view target back to the possessed pawn or character:

Get Player Controller 0
-> Get Controlled Pawn
-> Set View Target with Blend
   Target = PlayerController
   New View Target = ControlledPawn
   Blend Time = 0.5

If your playable pawn uses the usual Spring Arm + Camera setup, returning to the pawn view target puts the player back on that follow camera.

View target is not possession

This is the confusion the node creates most often.

Possess answers:

Which pawn is this controller driving?

Set View Target with Blend answers:

Which actor is this controller viewing through?

Those can be the same actor, but they do not have to be.

flowchart LR
    PC[PlayerController] -- possesses/input --> Pawn[Player Character]
    PC -- camera view --> Cam[Cutscene CameraActor]

In that setup, movement input can still drive the character while the screen shows the cutscene camera. That is useful for spectator shots and some camera-only effects, but it is wrong if you expected to control a different body.

Use:

  • Set View Target with Blend when the player should look through a different camera actor or camera-bearing actor.
  • Possess when the controller should drive a different pawn.
  • Both, deliberately, when a transition changes body and camera separately.

See Possession for the controller/pawn side of that relationship.

When it appears to fail

The node does not report failure. The execution pin continues, and the only evidence is what the player's camera does.

Common causes:

  1. The PlayerController target is wrong or missing. You changed a controller that is not the local player you are looking through.
  2. The New View Target reference is empty or not the actor you think it is. Print the target name before the node so you know which actor you are actually handing to the camera manager.
  3. You passed a camera component. The New View Target must be an actor reference, such as a CameraActor or pawn.
  4. The target actor has no useful camera. If the actor has no camera component and its transform is at the floor, the view can look wrong even though the switch happened.
  5. You expected input to move to the new target. View target does not possess the target actor.
  6. Possession or auto camera logic immediately takes the view back. A pawn being possessed can ask to take camera control, and other camera code can call Set View Target after your call.
  7. The blend is too slow to diagnose. A long blend may make it look like nothing changed yet. Test with Blend Time = 0 while debugging.
  8. Lock Outgoing makes the outgoing view stop moving. That can look odd if you expected the old player camera to keep tracking during the blend.
  9. You are testing split-screen or multiplayer with the wrong player index. Camera view is local-player-facing. Change the relevant local player's controller, not a random controller reference.
  10. A Level Sequence or custom camera manager is also controlling the camera. If another system owns the view after your call, your blend can be overwritten on the next update.

Use Print String and the Output Log or breakpoints to prove which controller and target actor references are reaching the node.

The pattern everyone actually uses

For a simple death camera:

PlayerCharacter death event
-> Get Controller
-> Cast to PlayerController
-> Set Ignore Move Input true
-> Set Ignore Look Input true
-> Set View Target with Blend
   Target = PlayerController
   New View Target = DeathCameraActor
   Blend Time = 0.6
   Blend Func = Ease In Out

The C++ twin, for the curious (our own example code):

void ATrainingPlayerController::ShowDeathCamera(AActor* DeathCameraActor)
{
    if (!IsValid(DeathCameraActor))
    {
        return;
    }

    SetIgnoreMoveInput(true);
    SetIgnoreLookInput(true);
    SetViewTargetWithBlend(
        DeathCameraActor,
        0.6f,
        VTBlend_EaseInOut,
        2.0f,
        false);
}

For a temporary inspect camera:

Interact with object
-> store OldViewTarget = PlayerController.GetViewTarget
-> Set View Target with Blend to InspectCameraActor
-> Set Input Mode Game and UI or UI Only if an inspect widget is open

Close inspect
-> Set View Target with Blend to OldViewTarget, or to Get Controlled Pawn
-> restore input mode and cursor state

The quick path is to move the character's follow camera into position for every special shot. The concrete cost is that you turn a one-off cutscene, death cam, or inspection view into state that must be unwound from the player's normal camera rig. A separate CameraActor plus Set View Target is the cleaner beginner pattern when the shot is not part of normal character control.

Lookalikes - which one do I want?

Thing Use when Not the same as
Set View Target with Blend A PlayerController should view through another actor, with an optional camera blend. Possessing that actor or changing input ownership.
Possess A controller should control a different pawn. Changing the camera view by itself.
Camera Component An actor needs a camera point of view and camera settings. A valid New View Target pin by itself.
CameraActor You want a standalone placed camera for cutscenes, fixed shots, death cams, or previews. The player's possessed pawn.
Spring Arm Component A camera should follow at a collision-aware distance from a pawn or actor. A controller-level camera switch.
Set Input Mode UI/game input routing should change for the local player. Camera view switching.
PlayerCameraManager You need lower-level camera behavior, shakes, modifiers, or project-specific camera arbitration. A beginner Blueprint node for a one-off camera blend.

Going deeper