VRCode LabWeb

Designing Lightweight VR Meeting Prototypes Using WebXR

UUnknown

2026-03-05

10 min read

Build a minimal WebXR meeting room with three.js and open standards — a practical, vendor-free alternative to heavy VR platforms in 2026.

Stop Rebuilding Workrooms: A Lightweight WebXR Meeting Prototype You Can Ship

Hook: You’re a developer or DevOps engineer frustrated with big vendor lock-in, heavy clients, and disappearing enterprise VR apps. Meta shut down Workrooms and restructured Reality Labs in early 2026 — and many teams are asking: can we build a simple, open, maintainable VR meeting experience that isn’t tied to a single vendor?

This code lab walks you through building a minimal, real-time VR meeting room using WebXR, three.js, and open web standards. The goal: a tiny, extensible prototype you can run on the web, iterate on quickly, and use as a foundation for experiments or internal tools — without committing to heavyweight proprietary platforms.

Why build a lightweight WebXR meeting prototype in 2026?

In late 2025 and early 2026 the XR landscape shifted. Meta announced the end of standalone Workrooms (Feb 2026) as it refocused Reality Labs and Horizon services. Enterprises that once relied on closed ecosystems are reconsidering openness, portability, and cost.

“Meta is killing the standalone Workrooms app on February 16, 2026… the company said Horizon evolved enough to support productivity apps” — news summary, 2026

That creates an opportunity for teams to adopt lightweight, standards-based approaches that emphasize:

Interoperability via WebXR and glTF—so clients run in browsers and future AR wearables.
Incremental complexity—start with avatars and audio, add spatial tools later.
Real-time collaboration using WebRTC or simple socket servers for presence.
Low ops cost—static hosting + small Node server or managed signaling.

What you’ll ship by the end of this lab

A tiny WebXR-enabled three.js scene that runs in browser VR or 2D.
Head pose and hand/controller updates streamed to other clients.
Basic avatar primitives (head + hands) and position interpolation.
Simple voice pass-through (WebRTC) or a placeholder for integrating spatial audio.
Design notes for scaling, security, and future features.

Architecture overview

Keep it minimal: clients render and track local XR inputs, and a small server distributes presence updates.

Components

Client (Web) — three.js + WebXR for rendering and input.
Signaling / Presence Server — Node.js with Socket.io for discovery and relaying position updates (or use a managed WebSocket service).
Optional Media — WebRTC for real-time voice (and optional datachannels for P2P pose exchange).

We’ll implement a simple Socket.io-based presence server for clarity; switch to WebRTC when you need lower latency or decentralized voice streams.

Step 0 — Prerequisites

Node.js 18+ locally
Basic familiarity with three.js and JavaScript
HTTPS hosting for WebXR in secure context (localhost via mkcert is fine)
A WebXR-capable browser (Edge/Chrome/Firefox for PC + Android, or headset browser like Oculus/Meta Quest that supports WebXR)

Step 1 — Minimal three.js + WebXR scene

Create index.html and app.js. The scene contains a floor, a table, and light. We’ll enable WebXR via WebXRManager and the XRButton helper.

// app.js (abridged)
import * as THREE from 'three';
import { XRButton } from 'three/examples/jsm/webxr/XRButton.js';

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(70, window.innerWidth/window.innerHeight, 0.01, 100);
const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(window.innerWidth, window.innerHeight);
renderer.xr.enabled = true;
document.body.appendChild(renderer.domElement);
document.body.appendChild(XRButton.createButton(renderer));

// simple room
const floor = new THREE.Mesh(new THREE.PlaneGeometry(10, 10), new THREE.MeshStandardMaterial({ color: '#444' }));
floor.rotation.x = -Math.PI/2; scene.add(floor);

const light = new THREE.HemisphereLight(0xffffff, 0x444444); scene.add(light);

// animation loop
function animate() {
  renderer.setAnimationLoop(render);
}
function render(timestamp, frame) {
  renderer.render(scene, camera);
}
animate();

The XRButton opens the immersive session when available. Run over HTTPS or localhost and check on a headset.

Step 2 — Representing the local user (avatar)

Keep avatars simple: a sphere for the head and cylinders for hands. The crucial bit is mapping WebXR pose to your avatar nodes.

// inside scene setup
const localAvatar = new THREE.Group();
const head = new THREE.Mesh(new THREE.SphereGeometry(0.15), new THREE.MeshStandardMaterial({ color: 0x0077ff }));
localAvatar.add(head);
scene.add(localAvatar);

// XR frame mapping
function render(timestamp, frame) {
  if (frame) {
    const refSpace = renderer.xr.getReferenceSpace();
    const session = renderer.xr.getSession();
    const pose = frame.getViewerPose(refSpace);
    if (pose) {
      const p = pose.transform.position;
      const o = pose.transform.orientation;
      localAvatar.position.set(p.x, p.y, p.z);
      localAvatar.quaternion.set(o.x, o.y, o.z, o.w);
    }
  }
  renderer.render(scene, camera);
}

That gives you a head-aligned avatar in world space. Add hands using inputSources and XRInputPose for controller/headset tracked hands.

Step 3 — Presence server (Node.js + Socket.io)

We’ll implement a tiny server to exchange lightweight JSON presence messages (id, timestamp, head position & rotation, optional hand transforms). This is authoritative-less: everyone broadcasts and everyone applies interpolation for smoothness.

// server/index.js
const express = require('express');
const http = require('http');
const { Server } = require('socket.io');
const app = express();
const server = http.createServer(app);
const io = new Server(server, { cors: { origin: '*' } });

const clients = new Map();

io.on('connection', (socket) => {
  console.log('connect', socket.id);
  socket.on('presence', (data) => {
    // broadcast to others
    socket.broadcast.emit('presence', { id: socket.id, ...data });
  });
  socket.on('disconnect', () => {
    socket.broadcast.emit('leave', socket.id);
  });
});

server.listen(3000, () => console.log('Presence server running on :3000'));

This server is intentionally small. For production, add authentication, rate limits, and namespaces for rooms.

Step 4 — Client networking: send & receive poses

On the client, connect and emit a compact pose payload regularly but at a modest rate (15-30Hz). Keep precision low (rounded floats) to save bandwidth.

// client networking pseudocode
const socket = io('https://your-server:3000');

function sendPose(avatar) {
  const p = avatar.position;
  const q = avatar.quaternion;
  socket.emit('presence', {
    ts: Date.now(),
    px: Number(p.x.toFixed(3)), py: Number(p.y.toFixed(3)), pz: Number(p.z.toFixed(3)),
    qx: Number(q.x.toFixed(4)), qy: Number(q.y.toFixed(4)), qz: Number(q.z.toFixed(4)), qw: Number(q.w.toFixed(4))
  });
}

setInterval(() => {
  if (renderer.xr.isPresenting) sendPose(localAvatar);
}, 66); // ~15Hz

socket.on('presence', (payload) => {
  // update or create remote avatar and push into interpolation queue
});

When you receive presence updates, store the latest pose and use interpolation/extrapolation on the rendering side to smooth motion. Never apply raw remote transforms instantly — network jitter will be visible otherwise.

Interpolation strategy (practical)

Keep a short buffer of recent states (100–300ms).
Render remote avatars with a fixed interpolation delay (e.g., render state 150ms behind real-time).
Linearly interpolate positions and slerp quaternions. Snap if distance > 1 meter to avoid warping.

Step 5 — Adding voice (optional): WebRTC basics

For simple voice, you can establish a WebRTC connection between participants. Use your signaling server to exchange SDP and ICE candidates. For small groups, a full mesh is okay; for larger rooms, consider a small SFU (Jitsi, mediasoup) or cloud service.

// Signaling: reuse socket.io to exchange offers/answers
socket.on('webrtc-offer', (data) => {/* setRemoteDescription and create answer */});

Given audio is often prioritized in meetings, start with mono audio and bitrate caps. Spatial audio can be added later with WebAudio APIs and head-relative panning.

Step 6 — Support non-VR participants

Not everyone has a headset. Provide a 2D fallback: the three.js scene still renders in a flat view and users control a camera with WASD/mouse. Keep the same presence protocol so 2D users can join and interact.

Operational notes & tradeoffs

Bandwidth and update rate

15–30Hz pose updates are usually fine; audio uses more bandwidth and requires different handling.
Use delta compression for transforms; transmit integer millimeters or compressed quat formats if necessary.

Security & privacy

Run over HTTPS and use secure WebSocket (wss). WebXR requires secure contexts.
Minimize PII in presence packets. Use ephemeral room tokens and short TTLs.
Authenticate users for company deployments; integrate OAuth/OIDC or service tokens.

Scalability

For up to ~10 participants, a small Node server and mesh WebRTC works.
Beyond that, add an SFU for audio/video and consider interest management for presence (only send updates to nearby avatars).

Interoperability & standards

WebXR and glTF are your friends: glTF for avatar assets, WebXR for device access. Also watch OpenXR and the growing alignment between native XR runtimes and web APIs in 2026 — polyfills and bridges make hybrid deployments easier.

UX tips for small prototypes

Start with presence and voice. Add shared whiteboards, screenshares, or spatial pointer tools later.
Use subtle avatar indicators (nameplate above head) and a microphone activity indicator.
Keep UI minimal: avoid modal flows inside VR; use radial menus or laser pointers.

Testing and debugging

Use developer tools in desktop browsers and chrome://inspect for remote devices.
Log network packets and simulate latency/jitter with tc on Linux for robust interpolation logic.
Record sessions (server-side) for later analysis of desync issues.

Future-proofing & 2026 trends

As vendors pivot away from monolithic metaverse platforms, open, web-based prototypes will be more valuable for teams that want control and portability. In 2026 you’ll see:

Better browser XR support and WebGPU adoption for richer visuals on the web.
An increase in hybrid experiences — browser + native client bridges (OpenXR + WebXR polyfills).
More enterprise interest in small, auditable XR tools rather than large vendor lock-in.

Design your prototypes to be modular: separate rendering, input, networking, and policy/authorization so you can swap in an SFU, a cloud signaling provider, or a native client later.

Real-world example: 15-minute staging checklist

Clone the minimal repo and install dependencies.
Run the presence server on a public URL (or ngrok / cloud) with wss and TLS.
Open client URL on headset and desktop; verify both can join the same room ID.
Confirm head pose sync and that you can hear voice via WebRTC if enabled.
Adjust interpolation delay until remote motion feels smooth but responsive.

Advanced strategies (when you’re ready)

Implement interest management: only send updates for nearby avatars.
Use an SFU for scalable audio + optional centralized voice moderation.
Integrate decentralized identity (DID) or corporate SSO for access control.
Persist room state in a small database for meeting transcripts or playback.

Common pitfalls and how to avoid them

Don’t stream high-frequency raw transforms — compress and downsample.
Don’t trust client timestamps — use server-side arrival timestamps or monotonic counters.
Avoid heavy GL scenes early; prioritize stable frame rates over fidelity.

Actionable takeaways

Ship a minimal prototype first: presence + voice + simple avatars.
Leverage open standards: WebXR for device access, glTF for assets, WebRTC for media.
Design for modularity: separate rendering, networking, and auth so you can evolve the stack.
Instrument and test: capture latency metrics and iterate interpolation until motion feels natural.

Where to go from here

This lab is intentionally opinionated and small. If you want to scale the prototype:

Swap Socket.io for an SFU-backed signaling layer (mediasoup, Janus)
Add spatial audio via WebAudio panner nodes and position-based gain
Support avatar uploads with glTF avatars and a small processing pipeline

Closing: the practical opportunity in 2026

As large platforms reshape their XR strategies in 2026, teams can regain agency by building lightweight, standards-first prototypes. WebXR + three.js gives you a fast path to working examples that run in browser or headset, and simple presence servers let you iterate on UX and collaboration patterns without massive infrastructure.

If you want a starting point, fork a small repo with the pattern above, or drop into a community channel to test shared rooms with peers. Prototypes like this reduce vendor risk and help you validate whether immersive collaboration actually improves outcomes for your team.

Call to action

Ready to build the prototype? Clone the minimal repo, run the small Node server, and join our weekly dev lab to iterate together. Share your prototype in the community for feedback, and tag your repo so others can build on it. If you want, I’ll review your first PR and help set up SFU or WebRTC audio for scale.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.