Smooth VR Avatar Synchronization: Hands & Head

We configure server-side synchronization of VR avatars — from basic transforms to complex collisions. Hand and head positions update 72–120 times per second; without optimization, traffic for 8 players reaches 50–100 KB/s for positions alone. Achieving smooth synchronization without network overload is possible with key techniques: Dead Reckoning, quantization, authoritative server. Our certified Photon Fusion VR experts with 10+ years of experience and 50+ realized VR projects guarantee smooth synchronization. Typical implementation costs range from $5,000 to $20,000 depending on complexity.

How Does Dead Reckoning Work for Hands?

The Dead Reckoning technique comes from marine navigation and flight simulators. For VR avatars, it works like this: instead of position every frame, the client sends position + velocity + angular velocity. The receiver extrapolates the next position based on the last known state and a physical motion model. When the next packet arrives, we compare with the predicted position and correct. Dead Reckoning reduces packet rate by 10x compared to sending every frame.

In Photon Fusion VR, this is implemented via a custom NetworkBehaviour with [Networked] properties for position, rotation, and derivatives. Interpolation and Extrapolation are configured in NetworkTransform VR through InterpolationDataSource:

• Predicted — client-authoritative prediction, minimal perceived latency for the local player
• Interpolated — delayed but smooth for remote players
• Auto — Fusion chooses depending on State Authority

For VR hands, it's crucial that Predicted mode applies only to the StateAuthority object. Remote hands are always interpolated, and latency is inevitable — the question is how smoothly it is hidden.

What Is Quantization and Delta Encoding?

A VR hand position takes 3 × float32 = 12 bytes. Rotation as a quaternion — 4 × float32 = 16 bytes. Total 28 bytes per hand, 56 for two plus 28 for the head = 84 bytes per player excluding headers. Quantization reduces this to 15–20 bytes per player — 4–5 times smaller than the original size. Quantization is up to 5x more efficient than full float transmissions. Position in the VR working area (3×3×3 m) with 1 mm accuracy encodes in 15 bits per axis. Rotation via compressed quaternion (three components, fourth restored) — 10 bits per component.

In Photon Fusion VR, quantization is enabled through NetworkTransform.Precision and RotationPrecision. For custom data, we use INetworkStruct with manual quantization via BitStream.

Delta encoding is the next level: we only transmit the change relative to the previous state. A hand that hasn't moved (player holding an object still) sends almost zero delta, compressed to a few bits. In practice for VR, this gives 30–60% traffic reduction compared to full positions every tick. Delta encoding provides 30-60% additional savings compared to quantization alone.

Client or Server Authority: Which to Choose?

This is an architectural choice with direct gameplay consequences. Client authority for hands — the position is taken as-is from the client — minimal latency, maximum responsiveness. But it opens the possibility for cheats: a client can send a "hand" to a position physically unreachable.

Server authority (Authoritative Server VR) — the server validates every hand movement against physical limits (max speed, reach zone from torso) — cheat-resistant, but requires RTT compensation for responsiveness. For VR games without competitive elements (cooperative experiences, co-op), client authority with basic server validation of anomalies is sufficient. For competitive VR — server authority with aggressive client prediction and rollback.

How We Solved the Handshake Desynchronization Problem: A Case Study

Our client — a studio developing a social VR space — encountered an issue: players "shake hands," but with RTT 80–120 ms, positions diverged by 5–12 cm. The handshake looked like an empty gesture in the air.

Solution: a custom snap protocol. When one hand enters the collider of another (checked on the server), the server notifies both clients of the capture event. Both clients switch to anchor mode: one becomes the leader, the other the follower. The follower interpolates its position toward the leader with Lerp over 80 ms. Visually — smooth connection without teleportation. Contact us for implementation details.

What Is Included in the Work?

We deliver a full package:

• Analysis of current network architecture and identification of bottlenecks
• Design of custom NetworkBehaviour for your mechanics
• Implementation using quantization and delta encoding
• Load testing with simulation of 100+ players
• Documentation for maintenance and future improvements
• One month of post-deployment support
• Training session for your development team
• Access to example code and best practices guide

Work Process: Step by Step

1. Analysis — study the current network solution, measure traffic, determine requirements for precision and latency.
2. Design — choose architecture (client/server authority), define compression scheme.
3. Implementation — write code: custom NetworkBehaviour, quantization, delta coding, snap protocol if needed.
4. Testing — verify at different RTT (20–200 ms), measure FPS budget, server load.
5. Deployment — roll out to production, configure monitoring (logging of delays, sync errors).

Estimated Timelines

Cost is calculated individually after an audit of your architecture and requirements. Get a consultation — and we will find the optimal solution.

VR and AR Development

When we first launch a project in a VR headset, most teams face the same thing: technically everything works, but in the headset either motion sickness occurs, or hands 'float' with a delay, or the scene looks jerky at the periphery. These are not bugs in the usual sense — they are a consequence of the fact that VR/AR development requires a different approach to render architecture, interaction, and UX from the very beginning of the project. Our experience: over 7 years in game dev, 15+ completed VR/AR projects for Meta Quest, SteamVR, PSVR2, HoloLens. We work with teams that need not just a prototype but a production‑ready application with a stable frame rate.

Platforms and SDKs

We work with all relevant stacks. We use OpenXR as the base layer wherever possible — it provides cross‑platform compatibility between Meta, Valve Index, HP Reverb and other PC VR devices. On top of OpenXR, we build on the XR Interaction Toolkit (Unity) or VR Expansion Plugin (Unreal). Contact us for a stack assessment tailored to your project.

How to minimize motion sickness in VR locomotion?

Locomotion — the main source of motion sickness for inexperienced VR users. According to research, about 70% of users experience discomfort with improper movement settings Oculus Developer Guidelines. Teleportation — standard navigation method when smooth movement is undesirable.

Components from XR Interaction Toolkit: TeleportationArea, TeleportationAnchor, TeleportationProvider. Basic implementation works out of the box, but for production we refine it in four steps:

1. Setting up XRRayInteractor with a curved ray (Bend Ray) — the teleportation arc looks more natural than a straight ray and is perceived better by users.
2. Adding a valid landing zone — a visual indicator changes color when hovering over an obstacle (red/green).
3. Implementing fade transition — smooth screen fade (black fade) before teleportation reduces disorientation.
4. Rotation snapping — after teleportation we offer snap rotation by 45° or 90° instead of smooth, reducing motion sickness risk.

For projects requiring smooth locomotion (action games, simulators), we use comfort settings: vignetting during movement, reducing FOV during acceleration. Settings are available to the user in the menu — different people have different sensitivity thresholds. The difference between kinematic and physics‑based movement: kinematic gives instant hand following but lets objects pass through walls; physics‑based via Joint provides realistic collisions but requires velocity damping and max joint force tuning. We choose based on the type of interaction.

How to make object grabbing in VR physically realistic?

This is the most underestimated part of VR development. Clients often perceive it as 'just hand animation', but in practice it is a complex system where physical correctness, responsiveness, and comfort conflict.

Grab (grabbing)

XR Interaction Toolkit provides three types of Interactable for grabbing:

• XRGrabInteractable — standard grab, object follows controller via physics joint or direct position/rotation
• XRSimpleInteractable — for objects without physical movement (buttons, levers)
• Custom Interactable by inheriting from XRBaseInteractable

Attach Transform — a frequently ignored detail. Each Interactable must have a properly configured Attach Transform (the point where the hand 'attaches'). Without it, the pistol grip will be at the center of the mesh, not where it is held.

For weapons and tools with two‑handed grab — a separate TwoHandGrab system: leading hand determines position, the second — orientation. XR Interaction Toolkit supports this via XRTwoHandGrabInteractable or custom logic with two Attach Points.

Throw (throwing)

Velocity smoothing is critical for realistic throwing because the Rigidbody.velocity at the moment of controller release reflects instantaneous speed, often incorrect due to tracking discretization. The user makes a quick wrist movement — but the object flies half as fast.

Solution: velocity smoothing over the last N frames (typically 5–10 frames, ~80–160 ms at 60 Hz) before release. XR Interaction Toolkit does this via VelocityEstimator. Additionally, we apply a velocity scaling multiplier — a small speed increase (1.2–1.5×) makes throws subjectively more satisfying. Angular velocity (for objects that should spin in flight) is also averaged similarly.

AR: Plane Tracking and Environment Interaction

AR adds a different class of problems — working with real, unpredictable environment. AR Foundation — a cross‑platform layer on top of ARKit and ARCore. Most basic features (plane detection, raycasting, image tracking, face tracking) are available through a unified API.

Plane Detection

ARPlaneManager detects horizontal and vertical planes. Practical nuances:

• Initialization takes time — the user must look around the room while the system builds a map. An explicit onboarding with instruction 'slowly move the camera across surfaces' is needed.
• Planes are unstable — their boundaries and position are updated as data accumulates. Objects placed on a plane need to be attached via parent to ARPlane, not to world coordinates.
• Plane merging — two detected floor segments may merge into one, moving the anchor. For critical anchors, use ARAnchor instead of direct attachment to the plane.

Image tracking (via ARTrackedImageManager) quality directly depends on the quality of reference images. Images with high detail frequency and contrasting edges (like a QR code but stylish) track more reliably than smooth logos. ARCore Geospatial API — for outdoor AR with real‑world coordinate binding (accuracy up to 10 cm in well‑mapped areas).

Optimization for VR: Frame Rate and Comfort

VR requires stable high frame rate. About 60% of development time in mobile VR goes to optimization, not functionality — retrofit costs twice as much as proper architecture from the first sprint.

Single Pass Instanced Rendering

The main render optimization in VR. Without it, the scene is rendered twice (once per eye), doubling draw calls. Single Pass Instanced renders both eyes in one pass via instancing: geometry is processed once, the shader gets two view/projection matrices through GPU instancing. Enabled in Unity via XR Plug-in Management > Rendering Mode: Single Pass Instanced. Important: custom shaders must support SPI — standard URP/HDRP shaders support it, custom HLSL requires modifications (UNITY_SETUP_STEREO_EYE_INDEX_POST_VERTEX and related macros). Applying this technique reduces draw calls by 40–50%, making it twice as efficient as naive double rendering.

Foveated Rendering

On Meta Quest, Fixed Foveated Rendering (FFR) is available — reducing resolution at the periphery where visual acuity is lower. Configured via OVRManager or Meta XR SDK:

OVRManager.fixedFoveatedRenderingLevel = OVRManager.FixedFoveatedRenderingLevel.High;
OVRManager.useDynamicFixedFoveatedRendering = true;

Dynamic FFR automatically increases the level when frame rate drops — more convenient than fixed in scenes with variable load.

IPD and Comfort Settings

IPD (Inter‑Pupillary Distance) — affects depth perception. At the programmable level on most devices, only reading IPD is available (OVRPlugin.GetSystemDisplayFrequency), physical adjustment is on the headset. For applications requiring precise positioning (medical simulators, training), we account for IPD in scene scale calculations.

Haptics

Haptic feedback — an underestimated tool. Even a simple vibration response when grabbing an object or hitting significantly increases the sense of presence. On average, integrating haptic patterns takes 30–80 hours per project.

XR Haptics via OpenXR:

var hapticImpulse = new UnityEngine.XR.HapticCapabilities();
InputDevice device = InputDevices.GetDeviceAtXRNode(XRNode.RightHand);
device.SendHapticImpulse(0, amplitude: 0.5f, duration: 0.1f);

For complex patterns (tactile 'texture' of a surface when touched, increasing vibration when drawing a bowstring) we use Meta Haptics Studio — allows designing haptic clips visually. This can reduce time spent on manual haptic tuning by about 30%.

What does VR/AR application development include?

When ordering a turnkey project, we provide the following deliverables:

• Architectural document with stack description, render logic, and interaction system
• Working prototype (MVP) for testing on target device
• Integration of necessary SDKs (Meta XR, OpenXR, AR Foundation, etc.)
• Optimization for target frequencies 72/90/120 Hz with draw call and FPS profiling
• Testing on physical hardware (Quest, SteamVR, HoloLens) with user involvement
• Full documentation for build, deployment, and support
• Training for the client's team (workshop on XR Toolkit)
• Warranty support for 1 month after delivery

What affects cost and timeline?

VR/AR projects are more expensive than regular games of similar scope. Iterations are slower — each fix must be tested in the headset, an emulator does not convey the real experience. Motion sickness forces reworking some conceptual decisions after the first playtest. Optimization takes a significant portion of time — for mobile VR (Quest) up to 60–70% of the cycle. For Quest projects, we start optimization from the first sprint. The cost of basic SDK integration (XR Interaction Toolkit) varies depending on the scope of custom Interactable. Typical budgets for a full Quest project range from $25,000 to $80,000 depending on complexity, number of custom interactions, and depth of optimization. Proper architectural planning from sprint one typically saves 40% on later rework compared to fixing performance bottlenecks retroactively.

Get a consultation on your project — we will assess the task, stack, and timelines. Order turnkey VR/AR application development with a guaranteed stable frame rate.