Connect Live Data
A digital twin is only useful while it reflects the state of the physical world. 3dverse applications can be connected to virtually any live data source — MQTT brokers, OPC UA servers, Azure Event Hubs, REST APIs, message queues, or custom systems — to synchronize a scene with real-world operations.
Incoming data can be used to:
- update live telemetry displayed in the scene,
- move robots, AGVs, conveyors, or other equipment,
- trigger animations and state changes,
- synchronize simulations with industrial systems.
Rather than embedding protocol-specific code inside your application, 3dverse introduces a headless client called the Livelink Agent. The agent receives events from your existing systems and applies the corresponding updates to one or more running scenes.
This section explains the architecture behind the agent, how events are mapped to entities, and how to connect different types of live data sources.
What is the Livelink Agent?
The Livelink Agent is a headless Livelink client with no viewport. It authenticates against a scene, joins one or more rendering sessions, and reads and writes entities through the same APIs as a browser client — it simply never receives video. See headless clients for where it sits in the platform.
That makes it the natural place to connect external systems to a running scene, whether the source is industrial telemetry, a simulation, a scheduled process, or any other event stream.
The agent runs wherever JavaScript runs. It can be deployed as a Node.js service close to your industrial infrastructure, or directly inside a browser when the data source is web-accessible.
Every integration answers three questions
Connecting live data to a scene always comes down to three independent concerns:
| Question | Object | Responsibility |
|---|---|---|
| Where do events come from? | Transport | Reads MQTT, OPC UA, Azure Event Hubs, playback, or any custom source. |
| How do events update the scene? | Event Mapping | Defines which events affect which entities and what components are updated. |
| Which scene receives the updates? | Agent | Connects to one or more running sessions and applies the updates. |
The Event Mapping is typically the only application-specific part. The transport and deployment mode can usually be changed without modifying the mapping itself.
Architecture — how data flows to the scene
The agent sits between your data sources and the 3D scene. Events flow through a transport, are mapped to entity updates, and applied to running scenes. Commands flow back the same way.
One event's journey
Two layers do this work, and you can use either alone:
IngestionPipelineruns the mappings. It has no idea what an agent, a session or a broker is — you bind scenes to it and push events in. That is what makes a mapping straightforward to unit-test, to drive from a webhook, and to replay one frame at a time.SceneIngestionis the wiring around it: it binds each ready session's scene to the pipeline, unbinds it when the session goes, and starts the data sources on the first binding.
Choosing a source
Which transport you need depends on where your data already is, and on one detail that is easy to miss: each transport
puts something different in an event's channel, which decides whether a mapping can route on it.
Data sources has the comparison table, the install line and runtime for each transport, and the two shortcuts worth knowing before you start — when to prefer MQTT over OPC UA, and why to build your mapping against a recording first.
When not to use the ingestion layer
The mapping model covers "an external event stream drives entities in the scene". It is not the only thing an agent can
do, and it is opt-in — the Agent class underneath is datasource-agnostic and gives you the entity API and typed
lifecycle events directly.
Reach past the ingestion layer when the mapping model does not fit — you need to read entity changes made by other clients and publish them back out, you already have an ingestion layer of your own, or the work is not event-shaped at all. What you take back on is the bookkeeping the pipeline was doing quietly: resolving ids to entities, skipping redundant writes, and turning off broadcast on the entities you drive. See using the agent directly.
You can also keep the pipeline and skip everything else: IngestionPipeline works with a scene from any Livelink
client, agent or not.
Next steps
- Quickstart — a working ingestion in a few minutes, with no infrastructure to set up.
- Preparing a scene for live data — the hierarchy, pivots and names that let live data actually drive the model.
- Driving mechanisms — the recommended approach for each kind of mechanism.
- Mapping events to entities — the part you actually design.
- Data sources — MQTT, OPC UA, Azure Event Hubs, playback, or a transport of your own.
- Running an agent — sessions, tokens, statistics and update rates.