Applications in 3dverse
A 3dverse application is what we called the client in the three-tier architecture. It is the interface layer that connects users to the cloud renderer, providing the user interface and business logic while leaving all heavy 3D computation to the cloud.
This page describes how applications work in 3dverse, the types of applications you can build, and how they compare to traditional engine-based workflows.
Key Characteristics
A 3dverse application is simply a web page that connects to the 3dverse platform and renderer. It handles interaction and workflows, while all heavy 3D computation and rendering run in the cloud — keeping the client lightweight.
Web-first distribution
Published and accessed instantly through a URL, like any website.
Cloud-powered rendering
All 3D processing happens on GPU nodes managed by the platform.
Streamed interaction
Video frames and input events flow between the application and renderer over Livelink.
Device agnostic
Runs in any modern browser, with no installs or GPU requirements.
Dev/prod parity
Same browser environment in development and production, no packaging step.
Instant access
Opens immediately in the browser — with no installation, no GPU requirements, and no asset downloads.
Unlike traditional engines, which require compiling and distributing binaries for each platform (along with shipping assets to every device), a 3dverse application is published the same way as any regular website.
Types of Applications
Applications in 3dverse generally fall into two categories. Both are delivered as web pages that connect to the cloud renderer, but they differ in how assets are introduced and what infrastructure is required.
Static Applications
A static application is the simplest kind of 3dverse app. All assets, flow, and logic are provided by the developer, and the experience is fully predefined. End users simply load the page and interact with what’s already there, without needing asset uploads or backend integration.
Example use cases include:
- A product showroom where users browse a catalog of 3D models.
- A training simulation where scenarios are fixed in advance.
- A game where all assets and rules are authored by the developer.
- An interactive narrative demo where users explore a handcrafted 3D environment.
Because nothing depends on user input beyond interaction, static applications are lightweight and straightforward to deploy — much like static web pages in the broader web ecosystem.
You can see real examples of static applications at 3dverse.com/features.
User-Content Applications
In a user-content application, end users provide their own assets (e.g. CAD models, point clouds, textures). The application adds business logic and workflows on top of rendering and typically integrates with backend systems. These applications often rely on the Asset API to register, query, and manage user content.
Example use cases include:
- A design review platform where architects upload building models, annotate them, and collaborate live in the same 3D scene.
- A factory operations tool where engineers upload CAD models of production lines or machine layouts, then layer in workflows such as maintenance planning, safety training, or process optimization.
While the distinction is useful, many real-world applications combine elements of both models, mixing predefined assets with user-provided content depending on the workflow.
Web-Native Development
Beyond the type of content they handle, all applications in 3dverse share the same architectural foundation.
From a web development perspective, 3dverse can be seen as a backend for real-time 3D. Instead of returning JSON or structured data, it streams frames to the browser and receives input events in return.
Like other backend services, integration happens through a JavaScript SDK. Livelink.js is the browser implementation of the Livelink protocol: it builds on web standards like WebSocket and WebCodecs, but abstracts away that complexity behind a front-end–friendly API.
Placing 3dverse inside the web stack is not incidental.
The system was designed from the start to behave like any other web service, so teams can integrate 3D the same way they already integrate storage, payments, or analytics — with familiar tools, workflows, and deployment models.
The Quickstart guide walks you through creating your first 3dverse application with the create-3dverse-app starter. In just a few steps, you’ll have a project running directly in the browser.
Separation of Concerns:
Business vs. 3D Backend
Just like other web services, 3dverse has a clear boundary of responsibility. It handles only the 3D layer — storing assets, running the cloud renderer, and orchestrating sessions. All other responsibilities remain with the application developer: user data, authentication, payments, and business workflows.
This separation is intentional.
3dverse does not need access to business-critical data; it only requires the 3D assets needed for rendering.
Developers remain in full control of how their logic is implemented and secured, using their own backends, databases, and identity providers.
From a security perspective, this means sensitive data never leaves the customer’s infrastructure. 3dverse provides the rendering service, while the application integrates business workflows on its own terms.
- 3dverse — 3D assets, rendering, sessions
- Your backend — business logic, sensitive data, workflows
- Benefit — strong separation of concerns, no exposure of business-critical data to the rendering layer
Decoupling the 3D World from the Application
In traditional engines, the development and production environments are fundamentally different. Editing requires a full editor running with special asset states, while experiencing the result requires compiling and packaging a separate build. This creates a gap that slows collaboration, complicates debugging, and forces duplicated workflows.
In 3dverse, the 3D world lives independently of the application layer. Assets, scenes, and sessions exist on the platform, and applications are simply different ways of interacting with that world. An application might act as an editor, a viewer, or both at once — all connecting to the same underlying 3D world.
This decoupling has several benefits:
- No dev/prod gap — editing and experiencing use the same assets; the difference lies only in the tools.
- Collaboration by design — multiple applications can connect to the same 3D world at the same time.
- Faster iteration — debugging and monitoring happen directly against the live environment, without builds or packaging.
By separating the 3D world from the applications that interact with it, 3dverse removes the friction of legacy pipelines and enables a more fluid, collaborative workflow.
Comparison at a Glance
These design choices mark a clear break from both traditional engines and browser-based 3D frameworks. The comparison below shows where 3dverse takes a fundamentally different path:
| Traditional Engine App | Web 3D App (e.g. three.js, Babylon.js) | 3dverse Application | |
|---|---|---|---|
| Distribution | Installed binaries per platform | Web page, assets downloaded to device | Web page, instant access via URL |
| Rendering | Local GPU | Local GPU (via WebGL/WebGPU) | Cloud GPU (streamed to client) |
| Assets | Bundled with the app | Downloaded to client for rendering | Remain on platform, never leave the cloud |
| Collaboration | Offline via builds & source control | Limited, not inherent to framework | Built-in, multiple clients connect to the same renderer |
| Scalability | Limited by each user’s device | Limited by client hardware | Elastic, pooled GPU resources, multi-renderer per node |
| Dev/Prod Gap | Wide — editor vs packaged build | Narrower, but local dev vs deployed app still distinct | None — same assets, same environment, only tools differ |
| Security | Assets distributed to client machines | Assets stored and processed on client | Assets stay secure in the cloud, only video is streamed |
In practice, a 3dverse application is nothing more than a web page connected to a cloud renderer.
All heavy 3D work — rendering, asset loading, synchronization — runs in the renderer, while the application supplies the interface and logic for its users.
Because the 3D world exists independently of the UI layer, the same scene can be edited, viewed, or extended by different applications without duplication or rebuilding.
With this foundation in place, the next core concept is the rendering session — the live renderer process that applications connect to in order to display and interact with a scene.