Aim Offsets and Look/Aim Variables¶
An Aim Offset is an additive Blend Space for aiming or looking. The asset blends poses; your Blueprint still has to provide correct yaw and pitch values from the character, controller, camera, or replicated aim state.
At a glance
Use this for: upper-body aiming, looking up/down, weapon aim pose correction, remote-player aim presentation - Main inputs: aim yaw and aim pitch, usually relative to the character or mesh, not raw world rotation - Main asset rule: Aim Offset samples are additive poses, commonly mesh-space additive, layered over a base pose - Can fail by: wrong additive setup, bad yaw/pitch math, unclamped values, local-only aim state, layer order, or weapon traces using a different aim source than the animation - Official docs: Aim Offsets, Creating an Aim Offset, and Blend Spaces in Animation Blueprints
The one-minute version¶
- An Aim Offset is a Blend Space type that uses additive poses, usually to layer aim/look direction over a base pose.
- A normal locomotion Blend Space chooses a full walking/running pose. An Aim Offset modifies a base pose with yaw/pitch samples such as up, down, left, and right.
- The AnimBP must feed aim variables. The Aim Offset does not know your camera, controller, weapon trace, or multiplayer state by itself.
- Aim yaw is usually the difference between where the player/controller is aiming and where the character body/mesh is facing. Aim pitch is the up/down part.
- Clamp and optionally smooth aim values before they reach the pose asset. Values outside the asset's axis range clamp or produce edge poses.
- In multiplayer, remote clients need replicated aim information if they should see another player aim up/down or sideways. Local camera pitch is not magically available on every machine.
Aim Offset vs normal Blend Space¶
Both assets map numbers to animation samples. The difference is what the samples mean.
| Asset | Samples | Output use |
|---|---|---|
| Blend Space | Full locomotion samples such as idle, walk, run, strafe. | Produces the main pose for a state. |
| Aim Offset | Additive aim/look poses around a base pose. | Modifies a base pose to face/aim toward yaw/pitch. |
Typical graph:
Locomotion cached pose
-> Aim Offset AO_RifleAim
Base Pose = Locomotion
Yaw = AimYaw
Pitch = AimPitch
-> optional Layered Blend Per Bone
-> Output Pose
For upper-body-only aim, layer the aim result over locomotion starting at the spine/upper-body bone chain.
Additive sample setup¶
Aim Offsets expect additive-compatible poses. A common setup is:
Base pose:
rifle/aim forward neutral pose
Aim samples:
Aim_Up
Aim_Down
Aim_Left
Aim_Right
Aim_Up_Left, etc.
Additive settings on samples:
Mesh Space additive
Base pose/reference chosen consistently
If the samples are not additive relative to the same base, the Aim Offset can twist, double-apply motion, or produce extreme poses. Fix the asset setup before trying to hide the result with Blueprint clamps.
Where yaw and pitch come from¶
Aim values are usually relative values, not raw world rotation.
For a third-person character:
ControlRotation = where the controller/camera aims
ActorRotation = where the character body faces
Delta = normalized delta rotator from ActorRotation to ControlRotation
AimYaw = clamp(Delta.Yaw, -90, 90)
AimPitch = clamp(Delta.Pitch, -60, 60)
For an aim-facing character where the body turns toward camera yaw, yaw may stay near zero and pitch may do most of the work. For a strafing character, yaw can be meaningful because movement/body direction and aim direction differ.
For AI:
LookAtRotation = Find Look at Rotation from actor/weapon to target
Delta = LookAtRotation relative to actor/mesh facing
AimYaw/AimPitch = clamped values
The math owner should match the feature. Player camera aim, AI target look-at, and weapon muzzle aim are related but not always identical.
Keep animation and weapon traces aligned¶
Beginners often make the animation aim somewhere different from the hit trace:
Animation AimYaw/Pitch comes from controller rotation
Weapon line trace comes from actor forward
Projectile spawns from muzzle forward
Now the character looks up, but the bullet travels flat. Pick a clear aim source:
| Feature | Typical source |
|---|---|
| Crosshair trace | Player camera/control rotation. |
| Third-person weapon muzzle | Muzzle socket adjusted toward camera hit point or aim target. |
| Animation Aim Offset | Same aim target/control rotation, converted to mesh-relative yaw/pitch. |
| AI aim | Target location from perception/blackboard, converted to actor-relative yaw/pitch. |
The weapon, crosshair, and pose do not have to be mathematically identical, but their differences should be deliberate. If animation is cosmetic, small differences are fine. If the weapon trace is authoritative, do not let the pose be the gameplay proof.
Clamp and smooth¶
Aim Offset axes have ranges, such as:
Yaw: -90 to 90
Pitch: -60 to 60
Clamp before feeding the asset:
AimYaw = Clamp(NormalizedDeltaYaw, -90, 90)
AimPitch = Clamp(NormalizedPitch, -60, 60)
Smooth for presentation when input/network updates are sharp:
SmoothedAimYaw = FInterp To(SmoothedAimYaw, AimYaw, DeltaSeconds, 12)
SmoothedAimPitch = FInterp To(SmoothedAimPitch, AimPitch, DeltaSeconds, 12)
Do not smooth the value twice in separate places. Decide whether smoothing belongs in the character/controller data, the AnimBP, or the replicated presentation path.
Layering aim over locomotion and montages¶
Common graph shape:
Locomotion State Machine
-> Save Cached Pose "Locomotion"
Use Cached Pose "Locomotion"
-> Aim Offset AO_Aim
-> Save/continue as "AimedLocomotion"
Upper-body montage slot may layer over or under aim depending on project:
reload might override arms
recoil might add on top
melee attack might disable aim layer
Layer order is a design decision:
- aim before reload can let reload replace the aiming arms;
- reload before additive recoil can let recoil affect the reload pose;
- aim on full body can twist legs if not layered correctly;
- aim after root-motion attack may create unintended upper-body turns.
Preview one obvious pose at a time before stacking aim, slot, recoil, and IK.
Multiplayer aim¶
The local player's camera/control rotation exists locally. Other clients do not automatically know every private camera detail.
If remote players should see aim pitch/yaw:
Owning client:
sends aim/request data through the normal movement/controller/replication path
or server receives aim as part of gameplay request
Server / replicated actor or PlayerState:
exposes compact aim pitch/yaw or aim target if other clients need it
Remote clients:
AnimBP reads replicated aim values
smooths/presents remote aim locally
For first-person arms, only the owning client may need the full aim pose. For third-person bodies, other clients usually need enough replicated aim to show where the character is looking or firing.
Never make client-reported aim animation the proof that a hit is valid. The server validates traces/projectiles according to the game's networking model.
When it fails, and what failure looks like¶
| Symptom | Likely cause |
|---|---|
| Character twists violently | Samples are not correct additive poses, base pose mismatch, or yaw/pitch range too large. |
| Aim never moves | AnimBP variables stay default, owner reference missing, or Aim Offset node not in final pose path. |
| Up/down works only locally | Aim pitch is local-only and not replicated/presented for remote clients. |
| Bullets do not follow crosshair | Weapon trace/muzzle uses a different aim source than crosshair and Aim Offset. |
| Arms aim but legs twist | Aim applied to full body instead of upper-body layer, or branch filter starts too low. |
| Remote aim snaps | Replicated aim values are too sparse or not smoothed locally. |
| Aim clamps too early | Aim Offset axis range or Blueprint clamp is narrower than intended. |
| Reload cancels aim strangely | Montage slot/layer order overrides the aim layer. |
Debug by printing raw control/camera rotation, actor rotation, normalized delta, clamped aim variables, and the live AnimBP values feeding the Aim Offset.
What Aim Offsets do not do¶
- They do not calculate yaw/pitch for you.
- They do not turn the character body or controller.
- They do not move bullets, traces, or projectiles.
- They do not make non-additive samples safe.
- They do not replicate aim values.
- They do not choose layer order with montages/recoil/IK.
- They do not fix a weapon socket aimed differently from the camera trace.
Lookalikes - which one do I want?¶
| Tool | Use when | Watch out |
|---|---|---|
| Aim Offset | Additive look/aim poses should modify a base pose from yaw/pitch. | Requires additive samples and good input math. |
| Blend Space | Full locomotion samples blend from speed/direction. | Not normally additive aim correction. |
| Layered Blend Per Bone | Aim should affect upper body only. | Branch bone/depth matters. |
| Control Rotation | Player/controller aim direction is the source. | It may not equal actor body rotation. |
| Find Look at Rotation | AI or actor should aim/look at a target point. | Convert to local/relative yaw/pitch before feeding an Aim Offset. |
| FABRIK/IK/look-at nodes | Bones should solve toward a target procedurally. | Different system from authored additive samples. |
| Weapon trace | Gameplay needs a hit result. | It is not animation; keep it aligned intentionally. |
Rule of thumb: Aim Offset is pose presentation from aim variables; the controller/camera/AI target owns the aim direction, and gameplay traces own hit results.
Going deeper¶
- Blend Spaces in Animation Blueprints - the asset family Aim Offsets extend.
- Cached poses and Layered Blend Per Bone - applying aim to the upper body over locomotion.
- Montage slots layered over locomotion - deciding whether reload/attack slots override or coexist with aim.
- Get Forward Vector & Find Look at Rotation - direction and look-at math for aim variables.
- Crosshair, reticle, and interaction prompts - camera aim and hit targets that often feed weapon/prompt logic.
- Replication basics - replicating compact aim state when remote clients need to see it.
- Official docs: Aim Offsets, Creating an Aim Offset, Blend Spaces, and UAimOffsetBlendSpace.
- Engine source (requires engine access - we do not reproduce it here):
Aim Offset assets are declared in
Engine/Source/Runtime/Engine/Classes/Animation/AimOffsetBlendSpace.hand implemented inEngine/Source/Runtime/Engine/Private/Animation/AimOffsetBlendSpace.cpp; base Blend Space behavior lives inEngine/Source/Runtime/Engine/Classes/Animation/BlendSpace.handEngine/Source/Runtime/Engine/Private/Animation/BlendSpace.cpp; AnimGraph player nodes live underEngine/Source/Runtime/AnimGraphRuntime/.