What causes framerate-dependent Lerp smoothing in Unity?

Calling Lerp with a constant weight each frame applies that fraction more times per second at higher frame rates, so the same code converges faster on a fast machine than a slow one.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix Framerate-Dependent Lerp Smoothing in Unity

Quick answer: Make the smoothing factor depend on deltaTime using an exponential form: t = 1 - Mathf.Pow(1 - rate, Time.deltaTime), or use Vector3.SmoothDamp which is already time-correct.

A camera or follower that feels snappy at 144 FPS but sluggish at 30 FPS is using a constant Lerp weight. Tying the weight to deltaTime makes the motion identical at any frame rate. Here is the fix.

How to fix it

1. Use an exponential factor

Replace Vector3.Lerp(pos, target, 0.1f) with Vector3.Lerp(pos, target, 1f - Mathf.Exp(-rate * Time.deltaTime)) so the convergence speed is constant across frame rates.

2. Switch to SmoothDamp for position

For follow cameras prefer Vector3.SmoothDamp(pos, target, ref velocity, smoothTime), which is defined in terms of time and naturally handles variable deltaTime.

3. Avoid Lerping in FixedUpdate by accident

If you smooth in FixedUpdate, use Time.fixedDeltaTime, and never mix per-frame and per-physics-step smoothing on the same value.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Unity error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The bug you can't reproduce isn't gone — it's just invisible until you capture it from the player's device.