Unreal Engine · Physics animation

PAC vs. PhysicsBlendWeight: two knobs that are not the same knob

2026 · VARMA DANDU · applies to UE 5.x — verify against your engine version

Ask a room of Unreal developers how to make a character "partially physical" and you'll hear two answers used interchangeably: turn on the Physical Animation Component, or raise PhysicsBlendWeight. They are treated as two spellings of the same feature. They are not. One acts inside the physics solve; the other happens after it — and which one you're actually using decides how your character behaves under contact.

PAC: forces inside the solve

The Physical Animation Component works by injecting spring-damper drives into the simulation itself. For each driven body, PAC computes the error between the body's simulated transform and its animation target, and applies corrective forces and torques — orientation strength, position strength, velocity strength — while the solver is running, substep by substep.

The consequence: the physics world feels the animation. A PAC-driven arm that hits a doorframe pushes against it, transfers momentum to it, and gets deflected by it, all within one consistent simulation. The pose you see is a genuinely physical pose — the solver negotiated it against every contact and constraint in the scene.

A detail worth knowing: PAC's orientation error is computed in axis-angle space via the rotation log-map. That's the same error formulation a damped least-squares IK solver uses for its rotational Jacobian terms — which is why PAC drives and IK targets can be made to cooperate predictably when you understand both as the same family of error-minimizing controllers.

PhysicsBlendWeight: a lerp after the solve

PhysicsBlendWeight does something entirely different. After the simulation has finished its step, the skeletal mesh component builds its final bone transforms by linearly blending, per body, between the kinematic animation pose and the simulated pose. At 0.0 you see pure animation, at 1.0 pure simulation, and at 0.5 a straight visual interpolation of the two.

Nothing about this blend feeds back into the simulation. The physics bodies keep simulating at their fully simulated state; the blend only changes what gets rendered and what the skeleton reports to downstream systems. It is a post-solve visual lerp — cheap, predictable, and completely non-physical.

Why the distinction bites

The failure modes follow directly from which side of the solve each mechanism lives on:

• Interpenetration during blends. A half-weight PhysicsBlendWeight pose is the average of two valid poses — which is not itself guaranteed to be valid. Blend a ragdoll lying against a wall back to animation and the intermediate poses can pass straight through geometry, because no solver ever saw them.
• Fighting drives. When a PAC-driven character lands on another physics body, the contact solver and PAC's drives are competing controllers acting on the same bodies in the same solve. Badly tuned gains show up as jitter precisely because both are real forces — something a post-solve lerp can never cause, and never fix.
• Hit reactions. If you want a character that visibly absorbs impacts while staying in control, that's PAC territory: the impact must exist in the simulation. If you want a clean, art-directed transition between "animated" and "simulated" states, that's blend-weight territory. Most production setups need both, layered deliberately — which is exactly why treating them as one feature produces systems nobody can tune.

The mental model

PAC is a controller inside the simulation. PhysicsBlendWeight is a compositor after it. One changes what happens; the other changes what you see.

Once the two are cleanly separated, ragdoll architecture gets simpler: drive the bodies with PAC (or per-joint constraint drives) while physical behavior matters, and reserve the blend weight for entering and leaving simulation — short, masked, and validated against the failure cases above. That separation is the foundation the AnimForge Ragdoll Stability Stack is built on.

Questions or corrections? Get in touch — engine internals evolve, and this page will be kept honest.