animation-driven vs physics character controllers: has anyone actually gone back to physics after switching?

yeah ended up in basically the same place. also tracking angular velocity separately for turning, felt wrong to snap direction changes with no carry-through at all. the thing i had to figure out was ownership: does the state machine set velocity directly, or write a target and something else integrates toward it? went with the second. state machine declares a target velocity, a separate step lerps toward it each tick with configurable acceleration per-state. keeps the animation logic from needing to know anything about the physics side and makes tuning way easier when you want different states to feel snappier or floatier.

this bit us hard last year. level designer added a ramp sitting right between two of our blend thresholds and the character just walked through it slightly tilted. animator had to cut a new transition, level designer adjusted the ramp, then we realized the camera rig was also reacting to root bone pitch and it cascaded from there. probably three days of back-and-forth that started with one slightly-off slope angle.

still think animation-driven is worth it overall, but this is the real cost. it's not just 'the teams need to communicate more' — you end up with hard constraints on level geometry that nobody documents until someone violates one.

That's exactly what pushed me toward keeping a thin velocity accumulator even in an animation-driven setup. Not full rigidbody physics, just a persistent velocity value that doesn't reset on state transitions. Root motion gets converted to a velocity delta each tick and added to the accumulator. When a state ends, momentum carries through naturally. Gravity, surface friction, landing impact, it all just works without the animation states needing to know about each other.

You end up with maybe 80-100 extra lines of code, but transitions stop feeling like hard cuts. The seam problem you're describing mostly disappears because velocity continuity is handled one level below the state machine.

How do you handle the visual correction when the authoritative position diverges from the cosmetic root motion? On a stable connection the drift is probably small enough to catch up invisibly, but on higher latency, or after an actual misprediction, I'd expect a visible slide or pop. Do you lerp the correction over a few frames, or does the gap stay small enough in practice that players don't notice?

I'm working through a similar architecture question and this is the part I keep circling back to. The cosmetic layer approach is clean in concept but I haven't found many detailed breakdowns of what the visual error correction actually looks like from a player perspective, especially at the edge cases.

This is exactly what pushed me toward treating root motion as a cosmetic layer rather than a movement authority. The server runs a simple kinematic simulation (explicit state machine outputs, fixed movement vectors) and the client animation system renders that movement convincingly on top. Root motion plays client-side for feel, but actual displacement comes from server state.

You lose some fidelity in the animation-to-movement mapping, which matters a lot for games where footwork and micro-positioning are central. For a tight action game with dodge rolls and precise movement, that tradeoff probably isn't worth making. For an RPG or a slower-paced platformer? I'd take the networking sanity every single time.

The pattern that worked for us is maintaining a smoothed "display position" that lerps toward the authoritative position each frame, capped by a maximum correction velocity. On a bad connection the character drifts slightly rather than snapping, which most players read as lag rather than a bug. The cap value is the hard part: too conservative and you accumulate drift permanently, too aggressive and it's a teleport by another name. We ended up exposing it as a tweakable float and playtested across simulated packet loss conditions until it felt acceptable. Not elegant, but it works.

This is the part that gets buried in most of these comparisons, and it's what actually matters. The seam problem is where animation-driven controllers fall apart in practice, not on the happy path, but right at the transitions.

What worked for me was blending the root motion velocity at the code level between states, separate from the animation blend. A 3–5 frame lerp on the velocity value being handed to move_and_slide() hides the discontinuity well enough that it reads as snappy rather than jarring. A bit of extra math, but it covers a surprising number of cases where the raw transition looks wrong regardless of how clean the blend tree looks in isolation.