Architecture Overview
3dverse is built on a three-tier architecture — Platform, Cloud Renderer, and Client — each with a clear role and boundary.
This architecture isn’t just an internal detail. It’s what sets 3dverse apart from monolithic engines and web-based 3D frameworks.
By separating the system into three distinct layers, 3dverse avoids the constraints those models still carry and creates the foundation for scalability, security, and real-time collaboration.
We’ll unpack each tier in detail before showing how this design compares to traditional approaches.
The Three Tiers at a Glance
- Platform — manages assets, sessions, and access.
- Cloud Renderer — performs all real-time rendering in the cloud.
- Client — sends commands and input, and receives video or state updates.
All three tiers are connected through well-defined communication channels:
- Client ↔ Platform — interaction via a REST API, following industry-standard practices for managing assets, sessions, and access.
- Client ↔ Renderer — communication via Livelink, a bespoke binary protocol specified with AsyncAPI, used for real-time control, state, and video streaming.
- Renderer ↔ Platform — an internal link for orchestration, synchronization, and asset delivery, not exposed to developers.
This separation lets each part evolve and scale independently, while the channels keep them tightly coordinated.
With the overview in place, the next sections examine each tier in detail.
Platform
The platform is the authority layer of 3dverse. It connects to both the client and the cloud renderer and coordinates services that keep the system consistent.
Its architectural responsibilities include:
- Access management — handling authentication and permissions.
- Session orchestration — creating, joining, and monitoring renderer processes across the GPU pool.
- Asset management — validating, storing, and exposing assets so they can be reliably used by renderers.
Internally, the platform is split into independent microservices, each scaling on its own. This design makes the system resilient and allows each part to scale independently as demand grows.
By acting as the single source of truth, the platform ensures that every client and every renderer operates against the same consistent state. This central authority is what makes assets dependable, sessions secure, and collaboration possible at scale.
- Authority layer — governs assets, sessions, and access
- Single source of truth — consistent state across all tiers
- Scalable — microservice architecture grows with demand
- Secure — permissions protect resources
Cloud Renderer
The cloud renderer is the rendering layer of 3dverse.
It is provisioned and managed by the platform, which decides when and where to launch renderer processes on GPU-powered nodes.
This orchestration allows rendering capacity to expand or contract automatically, and to be scheduled across available regions and hardware.
Rendering Nodes
Rendering nodes form the infrastructure backbone of the system.
They are provisioned as virtual machines or bare metal servers equipped with GPUs, and the platform continuously monitors their traffic and capacity.
When existing nodes approach their limit, new ones are spawned automatically, so rendering power grows in step with demand.
Nodes are deployed across multiple geographic regions so rendering can run closer to end users, reducing latency and improving responsiveness.
Caching System
Each node includes a local caching layer that sits between the platform and the renderer processes. When data is requested for the first time, it is retrieved from the platform and stored locally on the node. Subsequent requests are served from the cache, so all renderer processes on that node benefit from faster access and reduced network traffic.
This caching system ensures that assets are available with minimal delay and that bandwidth is used efficiently, especially when multiple sessions rely on the same data.
For sensitive use cases, organizations can supply their own rendering nodes within their infrastructure and/or configure customer-managed storage. This flexibility allows the same architecture to serve stricter security requirements.
Rendering Engine
A node by itself does not render anything. When rendering is required, the platform spawns a renderer process on one of the available nodes. Each process is an isolated instance of the internal renderer, called the FTL Engine, designed from the ground up for cloud deployment.
Multiple renderer processes can run in parallel on the same node until GPU capacity is saturated. Each process is sandboxed, with GPU resources scheduled by the engine so workloads don’t interfere. This architecture allows 3dverse to balance workloads dynamically without dedicating full hardware to each application.
In pixel-streaming services, each application instance consumes a full VM. 3dverse takes a different approach: multiple renderer processes can share the same node. This pooling model makes GPU usage more efficient and scaling more flexible.
FTL Engine
The renderer is built on Vulkan, chosen for its fine-grained control over GPU resources. This low-level access allows 3dverse to manage GPU memory and scheduling in a way that supports multiple renderer processes sharing the same hardware. It also ensures the engine is not tied to a single vendor ecosystem — Vulkan runs on virtually any modern GPU, making the architecture portable and future-proof.
As a cloud renderer, the engine integrates capabilities that are essential rather than optional:
- Low-latency video encoding to stream frames interactively over the network.
- Multi-point-of-view rendering so several users can explore the same scene simultaneously.
- A network replication layer, coordinated by the platform, to keep renderers on different nodes synchronized in real time, even across regions.
Unlike traditional engines, only the video stream and lightweight state updates leave the renderer — assets and GPU data remain confined to the cloud environment.
- Platform-orchestrated — decides when and where renderers run
- Elastic — nodes scale with traffic, multiple renderers per node
- Efficient — caching system for faster reuse
- Cloud-native — Vulkan-based, low-latency streaming, multi-user by design
- Secure — assets and GPU data stay in the cloud, only video streams leave
With rendering centralized in the cloud, the final piece is how end-users and systems interact: the Client.
Client
The client is the interface layer of 3dverse.
A client is any external process that connects directly to a renderer over a persistent socket.
Its role is to send commands and input to the renderer, and to receive rendered video frames or scene state updates in return.
While a client may also call the Platform API to register or query assets, API use alone does not qualify as a client — without a live connection to a renderer, a process is not part of this layer.
Viewer Clients
A viewer client connects to a renderer and requests video output, triggering actual rendering on the GPU. In practice, the vast majority of viewer clients are delivered as browser applications — not because the architecture requires it, but because it makes deployment and access seamless.
Viewer clients can:
- Forward user input (mouse, keyboard, touch, and gamepads).
- Display the renderer’s video stream.
- Combine rendered output with additional UI for workflows or tools.
Because rendering happens entirely in the cloud, viewer clients remain lightweight: they need no GPU, do not store assets, and can run on virtually any device with a modern browser. Multiple viewer clients can join the same session simultaneously, enabling real-time collaboration.
XR Viewing
Extended reality (XR) viewing is a natural extension of the viewer client. When running in a browser on an XR headset, the client can use WebXR to request stereo output — effectively two cameras rendered, one per eye.
This makes it possible to deliver immersive experiences directly to headsets without native applications or a separate client type. The same browser-based viewer can seamlessly switch between standard display and XR mode.
Headless Clients
A headless client connects to a renderer without requesting video output. Because no camera needs to be rendered, they impose minimal GPU cost. Their architectural role is to extend 3dverse into other systems by streaming external data into a live scene at real-time frequency.
Typical use cases include:
- Server-driven simulations — e.g. a legacy system streams its simulation results directly into 3dverse.
- Physical systems integration — e.g. a robot streams its state to a digital twin that mirrors it in real time.
- A client is any process that connects directly to a renderer.
- All clients use persistent socket connections (e.g. WebSockets in browsers).
- Headless clients — do not request video output, minimizing GPU cost. Used to feed external data such as simulations or physical system states.
- Viewer clients — request rendered output (mono or stereo via WebXR) while also sending user input.
- A process using only the Platform API is not considered a client.
Communication Channels
Clear boundaries between tiers also mean clear boundaries in how they communicate. 3dverse uses three distinct channels, each purpose-built for its role: a REST API for resource management, Livelink for real-time interaction and streaming, and an internal orchestration link for coordination between the platform and renderers.
Client ↔ Platform: REST API
Clients interact with the platform through a REST API, specified with OpenAPI. The specification provides a single reference for endpoints, payloads, and schemas, making it possible to generate client SDKs, validators, and documentation automatically.
This channel is the integration surface for external systems. Applications use it to:
- Upload or query assets.
- Launch or join rendering sessions.
- Manage access and permissions.
- Tie business logic or pipelines directly into the 3dverse ecosystem.
Because the API follows industry conventions and is schema-driven, it integrates smoothly with existing infrastructure.
Client ↔ Renderer: Livelink
Communication with the cloud renderer uses Livelink, a binary protocol formally described with AsyncAPI. Using a formal spec ensures message types and sequencing evolve consistently, and makes it possible to auto-generate implementations, validators, and docs across languages.
Livelink is optimized for continuous, low-latency communication. It carries both state updates and events as well as the video stream produced by the renderer, ensuring interaction stays responsive and synchronized.
Through this channel, clients can:
- Send commands or trigger actions in the scene.
- Receive live state changes and rendered video frames.
- Stay synchronized with other clients connected to the same scene for real-time collaboration.
Platform ↔ Renderer: Internal
The platform and renderer communicate over an internal orchestration channel, not exposed to developers. This channel handles:
- Dispatching renderer instances on demand.
- Streaming data and resources needed by the renderer.
- Synchronizing state across multiple cloud renderers.
- Monitoring health, scaling, and orchestration of workloads.
Why Not a Single Public Channel?
Managing resources and driving a live renderer are fundamentally different problems.
The REST API is best suited for discrete, structured operations such as registering assets or launching sessions. Livelink, by contrast, is optimized for continuous, low-latency streams of state and video.
A single protocol would have forced compromises in ergonomics, performance, or reliability. By separating concerns across three channels — two public, one internal — 3dverse ensures each communication path is tuned to its job, without overloading one protocol to serve all needs.
- REST API (OpenAPI) — resource management and integration with external systems; spec-driven with auto-generated SDKs and validators.
- Livelink (AsyncAPI) — real-time entity/component updates, scene events, and video streaming; spec-driven to ease multi-language implementations.
- Internal link — orchestration, synchronization, and asset delivery.
Now that the architecture and its communication patterns are clear, let’s contrast it with existing approaches to see what problems it solves.
Beyond Monolithic and Web-Based Engines
To better understand the design of 3dverse, it helps to contrast it with the two models that have dominated real-time 3D until now: monolithic engines and web-based 3D frameworks.
Monolithic Engines
Traditional engines package everything into a single binary. Rendering, asset management, application logic, and user interface all run together on the end user’s machine.
This model requires users to install and update software, sometimes across large teams or audiences. Collaboration is handled offline, through source control and build sharing, with new binaries produced every time a feature or asset changes. Because assets are distributed with the application, sensitive data is always present on the client’s machine, making control and security more difficult.
Web 3D Frameworks
Web-based 3D libraries move distribution to the browser, but the rendering model remains the same: everything happens locally. Scenes and assets must still be downloaded to the device, and performance depends on the end user’s GPU. This simplifies delivery but does not solve the deeper challenges of scalability, data control, or real-time collaboration.
3dverse
3dverse takes a different approach. By separating the Platform (authority layer), Cloud Renderer (rendering layer), and Client (interface layer), it creates a cloud-native model where:
- Rendering happens in the cloud, not on the device.
- Assets never leave the platform, only video streams reach the client.
- Distribution is instant — a link is enough to access an application.
- Collaboration is architectural: multiple clients can connect to the same renderer, each with its own interface.
- Scaling is elastic: the platform can spawn additional renderers, and multiple renderer processes can share a single node, pooling GPU resources efficiently.
This architecture turns the limitations of traditional and web-based engines into starting points for a system designed for security, scalability, and real-time collaboration.
Comparison at a Glance
| Monolithic Engines | Web-Based 3D Frameworks | 3dverse | |
|---|---|---|---|
| Distribution | Installed binaries | Browser-based, but assets downloaded locally | Instant, link-based |
| Rendering | Local GPU | Local GPU | Cloud GPU (shared nodes) |
| Assets | Bundled with app | Downloaded to device | Stored on platform, never leave cloud |
| Collaboration | Offline, via builds & source control | Possible but usually external to framework | Real-time, multi-client per renderer built in |
| Scalability | Limited by each device | Limited by client hardware | Elastic, orchestrated, multi-renderer per node |
| Security | Assets on client | Assets on client | Only video stream leaves the cloud |
This three-tier architecture is the foundation of 3dverse — and the reason it can deliver secure, scalable, and collaborative 3D experiences that traditional models weren't built to offer.
With that foundation in place, the next page explores applications, where this architecture is put into practice to deliver real-time 3D experiences.