Blog
Full Body Tracking Latency: Practical Causes to Review
Jul
If full body tracking looks late, compare the SlimeVR Server view with the avatar in your VR application before changing settings. When the server view follows your movement but the avatar follows later, inspect the SteamVR or OSC handoff, application load, and avatar. When the server view is also late, inspect the tracker connection and host path. If only one limb seems late, check its assigned role, calibration, and physical mount before calling it a network problem.
This method treats latency as a location problem: find the first layer where the visible motion falls behind. It also prevents a shaky, drifting, or missing tracker from being mislabeled as latency.
Decide whether the motion is late or simply wrong
Repeat one easy movement, such as a slow knee lift or torso turn, and watch what happens when you start and stop. True perceived delay has a timing pattern: your body moves, then the tracked result follows. A wrong direction, offset joint, or loose case can create a similar impression, but its path gives you a different clue.
| What you observe | Where to continue |
|---|---|
| Motion repeatedly follows after your body starts or stops | Stay on this latency path and compare the server with the app |
| A body point shakes while you are trying to hold still | Use the stationary-motion troubleshooting guide |
| The pose becomes progressively less accurate during the session | Use the progressive pose-error guide |
| A device vanishes, freezes, or does not appear in one layer | Use the missing-device decision path |
| Movement begins on time but travels in the wrong direction | Check role, mounting orientation, and calibration |
Do not estimate a delay in milliseconds by eye. You only need a repeatable observation at this stage: which view falls behind first, whether the whole body is affected, and whether the pattern appears every time.
Find the first layer that falls behind
Open the SlimeVR Server view and your VR application so you can compare the same movement. SlimeVR documentation separates a tracker connecting to the server from its virtual tracker appearing in SteamVR. That distinction is useful even when nothing is missing, because it gives you two places to watch the motion.
| Layer | Comparison | What the result means |
|---|---|---|
| On-screen result | Compare the avatar with your real start and stop | Confirms the symptom you are trying to reproduce |
| Application handoff | Compare the SlimeVR view with SteamVR or the OSC-driven app | Shows whether the visible delay begins after SlimeVR |
| Tracker transport | Watch whether the physical tracker changes promptly in SlimeVR | Shows whether the delay is already present before the VR app |
| Pose interpretation | Compare a known avatar and a fresh valid calibration | Separates tracking data from skeleton and avatar behavior |
| Physical coupling | Watch whether the case moves at the same time as the body segment | Reveals mechanical trailing that software cannot remove |
The first bad comparison owns the next test. If SlimeVR follows in time and the later application does not, leave the straps and Wi-Fi alone for that test. If the device view inside SlimeVR is already late, changing the avatar will not isolate the problem.
Inspect the handoff after SlimeVR
A SlimeVR setup can pass tracking data to a SteamVR route or use OSC for a supported application. The official quick setup treats those routes separately and instructs users to disable one before switching to the other. Confirm which route your session is meant to use, then verify that the matching driver, virtual trackers, or OSC settings are active.
Next, repeat the movement in a simple scene with a familiar avatar and without optional recording or overlay tools. This is not a claim that a particular app or avatar causes latency. It is a controlled comparison. If the server remains current but the avatar timing changes with the scene, avatar, or background workload, the delay enters after the tracker data reaches SlimeVR.
If you are unsure whether the basic path is configured in the intended order, return to the site’s setup workflow. Keep this test focused on the handoff rather than rebuilding every setting at once.
Inspect the tracker-to-host path
For Wi-Fi SlimeVR trackers, the official setup says the trackers use a 2.4 GHz network and the host must be on the same network. SlimeVR’s common-issues documentation also separates network discovery, server visibility, and SteamVR visibility. Check that the session still matches the connection route you originally configured.
Watch one tracker in the SlimeVR Server while moving the physical device through the same slow start and stop. Then repeat with another tracker. If every tracker appears late in the server at the same time, the shared path deserves attention. If one tracker differs while the others follow normally, record that device and its status rather than changing the entire network.
A firewall, guest-network rule, or server-discovery problem usually presents as a connection or visibility failure in the official troubleshooting branches. Do not treat changing those settings as a universal speed fix. Use them only when your observation points to the tracker-to-server path, and preserve the settings that already work until you have a specific reason to change them.
Separate pose interpretation from transmission timing
A wrong role, mounting direction, or body calibration can make a leg take a longer or stranger path even when the tracker update arrived on time. Check whether the matching tracker in SlimeVR rotates with the physical device at the expected moment. If it does, but the virtual limb arcs, twists, or catches up from an offset position, review pose interpretation before the network.
Use the calibration recovery reference when the symptom begins after a reset or mounting change. If the behavior changes only when you switch models, use the avatar comparison procedure. These checks answer different questions, so run one and repeat the same movement before moving to the next.
A successful recalibration can correct a pose relationship. It does not by itself prove that the tracker connection has no delay. Compare the server and application views again after the pose is valid.
Check for mechanical trailing at the body
The electronics can report promptly while the case moves late. A strap may stretch, rotate, or slide after the body segment starts moving, especially during a direction change. The avatar then follows the tracker correctly, but the tracker itself followed your body late.
Look at the case while you repeat the same slow motion. It should move with the body point rather than swing, settle, or rotate afterward. If the mount shifts, use the strap contact and stability checks to correct that separate problem. Return here only after the physical case and the body segment begin and stop together.
Change one layer and replay the motion
- Choose one slow motion that reproduces the delay without changing your stance or route.
- Record whether the SlimeVR Server view and the VR avatar fall behind together or at different points.
- Change one layer only: the app route, the tracker connection under review, the valid calibration state, the avatar, or the physical mount.
- Repeat the same motion and write down which view changed.
- Restore the previous state if the comparison did not improve or clarify the result.
Before contacting support, record the tracker roles in use, which handoff you selected, whether the delay appears inside SlimeVR, whether all trackers or one tracker are affected, and the exact change that reproduced the result. If you need to confirm the current tracker-count and package details while documenting the setup, use the FBTKit product configuration page. The product page is a configuration reference, not evidence that hardware replacement will solve the symptom.
FAQ
Does an avatar that follows late prove the Wi-Fi path is slow?
No. The visible delay may begin at the tracker connection, the SteamVR or OSC handoff, the VR application, the avatar, or the physical mount. Find the first view that falls behind before changing the network.
Can using the wrong SteamVR or OSC path create apparent delay?
It can create an incorrect or conflicting application handoff that feels late on screen. Confirm which route your session is meant to use, keep only that route active, and compare the result without changing another layer.
Why can one body part appear slower than the rest?
One late-looking limb can come from that tracker’s data path, assigned role, mounting direction, calibration relationship, or physical movement on the strap. Compare the individual tracker in SlimeVR before changing shared settings.
Why can delay look stronger when movement changes direction?
A case that shifts on its strap may continue moving after the body changes direction, which makes the tracked result appear to catch up. Watch the case and the SlimeVR view separately before blaming the data path.
Does recalibration test the network connection?
No. Recalibration can correct the relationship between tracker data and the virtual skeleton, but it does not measure tracker transport or the application handoff. Compare the server and app views again after calibration.
Official sources
