realvirtual WEB: an open-source 3D HMI for industrial digital twins, in the browser

Thomas S — Tue, 16 Jun 2026 20:59:55 +0000

Most "digital twin in the browser" demos are sealed viewers: a proprietary format, a hosted backend, and no way to connect your own controller. realvirtual WEB takes the opposite approach. It is open source (AGPL-3.0), it loads plain GLB files, and it talks to any PLC over a documented WebSocket protocol you can implement in about 30 lines of code.

Here is what it is and why it is worth a look if you build for the web or work in automation.

Repo: https://github.com/game4automation/realvirtual-WEB
Live demo: https://web.realvirtual.io/demo

What it is

realvirtual WEB is a browser-based 3D HMI and digital twin viewer for manufacturing. You give it a standard GLB/glTF file and it renders an interactive 3D model. Add rv_extras metadata to that same GLB and the model becomes a working digital twin: drives move, sensors trigger, signals update, all from one self-describing file. There is no external scene database and no proprietary project format. The GLB is the single source of truth.

The stack

It is a normal modern web app, not a plugin or a native runtime:

Three.js for rendering (WebGL, WebGPU in beta, WebXR)
React 19 and Material UI 7 for the interface
Rapier.js (WASM) for physics
Apache ECharts for live and historical charts
Vite 6, TypeScript 5.7 (strict)
Vitest and Playwright, 1300+ tests

Requirements: Node.js 20.19+ or 22.12+.

git clone https://github.com/game4automation/realvirtual-WEB.git
cd realvirtual-WEB
npm install
npm run dev

Drop a .glb into public/models/ and it appears in the model selector. That is the whole loop to see your own geometry in 3D.

Connecting to a real controller

The interesting part for automation people is the live link. realvirtual WEB visualizes PLC signals in real time over WebSocket or MQTT. The WebSocket side uses the rv WebSocket Realtime v2 protocol, and it is deliberately small:

JSON over WebSocket, bidirectional
signal-centric: the smallest unit is a named signal (Bool, Int, Float, Array). The protocol does not know about drives or sensors, only signals.
delta-based: after the initial snapshot, only changed values are sent
built for a 60 Hz update loop, matching the viewer's fixed-timestep engine

Because the protocol is open and signal-only, a minimal bridge to your own system is about 25 to 30 lines of code in any language. You are not locked into a vendor SDK to feed the twin.

More than a viewer

Transport simulation: a 60 Hz fixed-timestep engine with conveyors, sensors, and collision detection. Kinematic by default, real physics via a Rapier plugin when you need stacking or friction.
Machine Information System: attach PDFs and documentation directly to 3D components.
WebXR: VR and AR on Meta Quest, Apple Vision Pro, and mobile, from the same build.
Layout planning (beta): drag-and-drop factory assembly in the browser.
Multiuser (beta): shared sessions with avatars.
Plugin architecture: extend with custom HMI and behaviors via viewer.use(new MyPlugin()).
AI-ready (MCP): an MCP server lets AI assistants inspect, control, and debug the viewer.

Performance, concretely

CAD models are heavy, so the project ships with explicit budgets:

initial download (Three.js plus viewer) under 16 MB
55+ FPS at 500K polygons
under 500 draw calls

The note that matters if you have fought WebGL performance before: the bottleneck for CAD is draw calls, not polygon count. Mesh merging and instancing usually beat polygon reduction.

License

realvirtual WEB is AGPL-3.0-only. If you deploy it or build on it, including as a web service, you publish your project under the same license, and the watermark stays unless you hold a commercial license. Commercial licensing is available at https://realvirtual.io/en/company/license.

Why this design

A digital twin is only useful if it outlives the tools that made it. By using GLB as the data format and an open signal protocol as the wire format, realvirtual WEB keeps the twin portable and self-hostable. The geometry and the live data stay on your own infrastructure. You can read every line of the viewer, swap the controller, or write your own bridge. That is the part most twin platforms do not hand you.

Repo: https://github.com/game4automation/realvirtual-WEB
Demo: https://web.realvirtual.io/demo

What Is a Digital Twin in Unity?

Thomas S — Tue, 16 Jun 2026 20:51:29 +0000

The word digital twin gets attached to almost anything that looks like a 3D model on a screen. In realvirtual.io it means something more specific. A digital twin is 3D geometry plus behavior. The geometry is what the machine looks like. The behavior is what it does. Without the behavior part you have a 3D viewer, not a twin.

The easiest way to see how the behavior is built is the Getting Started demo that ships with realvirtual.io. It is a small machine you can open, run, and take apart. Three building blocks make it work.

Drives make the geometry move

A drive turns a static mesh into a moving machine axis. You attach a Drive component to a part, and that part can now translate or rotate with a real motion profile: acceleration, deceleration, speed, end positions. Machine axes are arranged as a kinematic hierarchy, so a part mounted on another part inherits its parent's motion. Move the base and everything on it follows.

Behavior reacts and decides

Drives move when something tells them to move. That something is a behavior model. Behavior models sit on top of drives and sensors and define the logic: when a sensor reports a part, close the gripper. When a cycle starts, run the axis to its end position. The behavior is driven by signals. In the Getting Started demo you can force a signal by hand and watch the machine react: force the door signal and the machine door opens or closes. No code change, no recompile.

Signals and the interface to a real PLC

Signals are not just an internal trick for testing. They are the same I/O a real controller exchanges with the machine. realvirtual.io models them as PLCInput and PLCOutput objects. The direction is defined from Unity's point of view as the simulated plant: a PLCInput is something Unity writes toward the controller, like a sensor reading, and a PLCOutput is something Unity reads from the controller, like an actuator command. While you build and test, you force those signals by hand. When you are ready for virtual commissioning, realvirtual.io Professional connects the same signals live to a real controller such as Siemens or Beckhoff, and the PLC program drives the twin instead of you. The behavior you built does not change. Only the source of the signals does.

Try it yourself

The Getting Started demo is free. You get drives, behavior, sensors, and a PLC interface already wired up in the realvirtual.io Starter from the Unity Asset Store. You need Unity 6.3 LTS to open it. Install it, press play, and force a signal to feel how the three blocks fit together.

Free Starter: realvirtual.io Digital Twin Starter on the Unity Asset Store
Documentation: doc.realvirtual.io This article is part of the realvirtual Know-How series.

DEV Community: Thomas S