Motion Interpolation Algorithm Development for Networked VR Games

id: 237 slug: vr-network-motion-interpolation-algorithm-development title_en: "Development of Motion Interpolation Algorithms in Network VR Games" tags: [vr-ar]

Development of Motion Interpolation Algorithms in Network VR Games

In standard network shooter, motion interpolation with 50–80 ms delay imperceptible: model slightly lags, normal perception. In VR doesn't work. Another player's head and hands must move without jerks — otherwise brain perceives as unnatural, destroying presence feeling. Meanwhile HMD sends tracking data at 72–120 Hz, network delivers packets irregularly.

Why Standard Interpolation Poorly Works for VR-Avatars

Typical mistake — apply same algorithms for VR-avatar as for gameplay objects. Vector3.Lerp between two received positions with fixed t=0.1 gives "rubber" lag especially noticeable on hand movements: hand continues moving to old target when new position already received.

Root problem in frequency difference: VR-scene render — 90 Hz (11 ms/frame), network updates — 20–30 packets per second (33–50 ms/packet). Between two network snapshots need generate 3–4 intermediate states. And do this accounting for jitter (packet delay variation) reaching 20–30 ms even on good connection.

Avatar head and hands — specific task: head moves smoothly and predictably (follows physical movement), hands — fast and unpredictably. One algorithm for both suboptimal.

Motion Interpolation Algorithms for VR-Tracking

Dead Reckoning with correction (Predictive Interpolation). Store buffer of last N states (position + orientation + velocity + time). On render compute predicted position based on last known velocity: predictedPos = lastKnownPos + velocity * deltaTime. On new network packet smoothly correct to real position over 3–5 frames. Compute velocity as (currentPos - prevPos) / packetDeltaTime and smooth via EMA (Exponential Moving Average) with α=0.3.

Approach works well for head where movement inertial. For hands — worse: hand can stop instantly or sharply change direction.

Hermite Spline Interpolation — for smooth curved movements. Build spline through last 4 tracking points with tangents (derivatives). Much better than linear interpolation on gestures and slow movements. Implemented as HermiteInterpolate(p0, p1, m0, m1, t) where m0/m1 — tangents at points.

Jitter Buffer — mandatory system component. Maintain buffer of incoming packets for 2–3 network frames (60–100 ms). Always render from buffer, not last packet. Adds delay but removes jerks from irregular packet arrival. Adapt buffer size dynamically: if jitter grows (determined via standard deviation of interpacket interval last 10 packets) — increase buffer, if stabilizes — decrease.

Orientation via Quaternion Slerp, not Lerp. Quaternion.Lerp gives non-linear rotation speed at large angles. Quaternion.Slerp — correct choice for head tracking. For IK-solver wrist recovery from motion data important to also normalize quaternion after interpolation — accumulated float-errors over several frames give artifacts in FK.

Inverse Kinematics for Avatar Body

HMD + two controllers give 3 tracking points. From them need restore shoulder, elbow, spine poses. For this use IK-solver:

In Unity — Animation Rigging (package com.unity.animation.rigging) with TwoBoneIK Constraint for arms and ChainIKConstraint for spine. Hint object setup for elbows critical: without them arms fold into unnatural poses. Hint position computed analytically from controller position and direction to body.

For more complex bodies and Full Body IK — FinalIK (Ootii) or custom FABRIK-solver. FABRIK (Forward And Backward Reaching IK) iteratively converges in 5–10 iterations, sufficient for real-time.

Work Stages

Network profiling. Measure real jitter, packet loss, RTT on target audience.

Algorithm selection per requirements. Balance between visual smoothness and response delay.

Jitter Buffer + interpolation implementation. Separate NetworkAvatarController with isolated logic.

IK calibration. Tuning for target anthropometries, test on extreme values (short/long arms).

Testing under network degradation. Simulate via tc netem (Linux) or Clumsy (Windows): 200 ms latency, 10% packet loss, 50 ms jitter.

Cost calculated after accuracy requirements and target network conditions analysis.