Weapons · Updated May 27, 2026

Weapon Clipping

Weapon Clipping

Plan for preventing the FP and TP weapon meshes from visibly passing through walls, other players, and world geometry. Most apparent during melee swings, but the same problem occurs near walls in normal stance.

#Current State

FP only — TP has nothing.

  • FSLWeaponViewDriverFP::CheckFPWeaponObstruction() — 15 cm radius sphere sweep from

    • the camera, forward, distance FPWeaponBlockingTraceDistance (default 30 cm), on ECC_Camera.

  • Outputs bIsFPWeaponObstructed + FPWeaponObstructionAlpha (0..1 based on hit distance).
  • Called every tick from ASLPlayerCharacter::CalculateFirstPersonWeaponBlocking while in

    • FP view, locally controlled, not falling, not dedicated server.

  • Consumed by AnimBPs to drive a viewmodel pull-back pose.

#Why It Fails During Melee

  1. Trace is too short. The swing extends the weapon ~50–80 cm forward of the camera at

    2. the peak. 30 cm catches walls before you're close enough to swing — not walls the swing reaches into.

  1. Trace is too narrow / only forward. Swings arc downward/sideways — a wall to the

    2. lower-right gets clipped because nothing sweeps that volume.

  1. Pull-back is static. It fires when standing near a wall. The moment a swing starts

    2. the animation overrides the pose and the weapon punches through.

  1. TP is unhandled. Other players see your weapon clip their bodies, walls, and props.
  1. ECC_Camera doesn't hit characters. Even if the trace caught a player, it would

    2. miss them — character physics bodies block ECC_WeaponTrace, not ECC_Camera.

#Approach Menu

Grouped by problem axis. Sizes: XS (minutes), S (~1 hr), M (~half day), L (multi-day).

#A. FP weapon vs world

#ApproachCostNotes
A1Extend trace distance during melee — when bIsMeleeing == true, swap the 30 cm range for a melee-aware distance (~80–100 cm)XSSmallest possible fix. Reuses existing pull-back ABP plumbing.
A2Multi-trace cone — fire 3–5 traces (forward + down/left/right) during melee to catch swing arcSSame pull-back consumer, stronger detection.
A3Socket-based trace — trace from camera to a weapon socket like Muzzle_Tip per tick; if blocked, retractMWeapon-shape-aware. Needs per-weapon socket.
A4"Retract" pose blended into the Melee anim if obstructedMAlpha blend between the regular swing and a retracted swing based on FPWeaponObstructionAlpha. Cleanest visual.
A5Render FP weapon always-on-top (custom depth + second render pass)LIndustry standard (Halo, COD). Removes the problem instead of hiding it. Most invasive.

#B. FP weapon vs other players

Same as A but on a different channel. Current trace uses ECC_Camera which doesn't hit the physics-asset bodies set up for ECC_WeaponTrace. Easiest fix: trace on ECC_WeaponTrace (or alongside), since pawn bodies already block it. One-line change.

#C. TP weapon vs other players

Visible TP clipping when punching someone happens on every client except the attacker's.

#ApproachCostNotes
C1Cancel/abort the melee swing if the target is point-blank — nudge the attacker's character back so the punch lands at arm's lengthSHides the problem by preventing the swing from completing into the target. Halo does this.
C2Per-character TP weapon retraction sweep (mirror of A1 but on the TP mesh, run on all clients)MMore expensive — runs for every visible character.
C3Animation snap-to-target — when impact resolves, briefly snap the swing so the fist arrives at the target instead of clipping past itMSame trick Halo/Destiny use. Smoother than C1.
C4Ignore it — TP clipping is much less noticed than FP. Many shipping games don't fix this.XSReal option if playtests don't flag it.

#D. TP weapon vs walls

Low priority — the TP camera is usually pulled back enough that your own TP weapon clipping walls is rare. Same fix as C2 if it becomes a problem.

Smallest-first. Stop at the step that makes the clipping stop being noticeable.

#Step 1 — A1 + B (one C++ change)

Make the FP obstruction trace melee-aware and switch it to ECC_WeaponTrace so it catches both walls and players.

  • Add MeleeObstructionDistance (~90 cm) to USLWeaponDataAsset.
  • CheckFPWeaponObstruction reads bIsMeleeing from the character anim state and picks

    • MeleeObstructionDistance when active, otherwise FPWeaponBlockingTraceDistance.

  • Change the sweep channel from ECC_Camera to ECC_WeaponTrace.

Probably solves 80% of FP cases.

#Step 2 — A4 (animation polish)

Author a "retract" pose for the melee anim and blend toward it based on FPWeaponObstructionAlpha. Pull-back becomes aggressive during the swing if a wall is in range. Polishes what step 1 missed.

#Step 3 — C1 or C4 (decide on TP)

Playtest in 2-player PIE. If TP clipping is jarring, add a swing-distance cap that nudges the attacker forward/back so the punch lands at arm's length rather than clipping through the target. If not obvious, defer.

#Step 4 — A5 (nuclear option)

Only if everything above still leaves visible clipping. Custom-depth always-on-top rendering removes the problem class entirely. Multi-day task, changes how the FP mesh interacts with post-processing.

#What to Skip

  • A3 (socket trace) — overlaps A1 in effect, more setup per weapon.
  • C2/C3 (TP retract / snap) — complexity not worth it until C4 is ruled out by

    • playtest.

  • Physics simulation on the weapon mesh — bad idea for FPS, never feels right.

#Camera-Clipping Fix (separate from weapon clipping)

The look-down-through-wall issue is a camera-position problem, not a weapon-mesh one. Solved 2026-05-27 by moving the rotation source from the CameraBoom to the Camera itself in FP mode.

Setup:

  • Camera->bUsePawnControlRotation = true (FP default)
  • CameraBoom->bUsePawnControlRotation = false (FP default)
  • BP toggles these on view-mode change: TP needs the boom-driven rotation back so the camera

    • orbits the character; FP wants the camera to rotate at its own static world position.

Why it works: when the boom owns rotation, all child components (Camera, FPMesh) rotate as a rigid group around the boom anchor — the camera arcs through space on pitch, potentially crossing walls. When the Camera owns rotation, the camera's world position stays static and only its rotation changes; capsule collision keeps that position safe from walls, and the near clip plane (now 1 cm via NearClipPlane=1.0 in DefaultEngine.ini) prevents the frustum from poking past the capsule radius.

Also reduced NearClipPlane from 10 cm → 1 cm engine-wide for extra headroom.

#Status

  • [x] Step 1 — A1 + B (melee-aware trace distance + ECC_WeaponTrace channel) — C++ done 2026-05-27
  • [x] Refactor — obstruction state moved onto FSLAnimState (bIsFPWeaponObstructed, FPWeaponObstructionAlpha); old WeaponsComponent accessors marked DeprecatedFunction
  • [x] Trace origin fixed — MuzzleOffsetFromCamera data-asset field added; trace origin = CameraLocation + CameraForward * offset to fully decouple from weapon pose (eliminates the retract-pose feedback loop)
  • [x] Camera-clipping fix — rotation moved from boom to Camera in FP mode + NearClipPlane=1.0
  • [ ] Step 2 — A4 (retract pose blend during melee) — in progress: Apply Additive node wired in ABP_MC_FP_Shotgun, single-frame additive pose MC_FP_Shotgun_Obstruction being authored. Still to: confirm Mesh Space Additive setup, PIE-test near walls + melee, replicate in ABP_MC_FP_AssaultRifle, tune per-weapon distances.
  • [ ] Step 3 — C1 or C4 (TP swing handling) — deferred until 2-player PIE playtest tells us whether TP clipping is visually obvious
  • [ ] Step 4 — A5 (always-on-top FP rendering) — only if needed