Skip to main content
5 min read

Rendering Sessions

In the previous section we saw how applications in 3dverse are built on top of the platform.

When an application needs to run live, it relies on a rendering session — a dedicated process of the cloud renderer running on a GPU node. A session can be seen as the runtime instance of a scene, hosted by the renderer and connected to clients through Livelink.

Two clients connected to the same rendering session.

Rendering sessions are managed by the platform, which handles their creation, location, and termination across the pool of GPU nodes.

Architecturally, this is where 3dverse becomes live: the scene isn’t just stored, it is running as an active environment where interaction flows in real time between clients and the renderer.

Session Lifecycle​

A session progresses through a straightforward sequence:

  1. Creation — requested via the Platform API with a target scene. The platform provisions the renderer process on a GPU node and initializes the session.
  2. Running — the session is active: it accepts clients, maintains the scene in memory, and reacts to state updates in real time.
  3. Termination — when idle or explicitly closed, the session shuts down and frees GPU resources.

Sessions and Scenes​

Every rendering session begins with a scene. When the session is created, the renderer loads this scene into memory and uses it as the entry point for everything that follows.

The scene defines the structure of the world hosted in the session. As clients join, they interact with this live state by issuing commands or making modifications — and all participants see the updates in real time.

Within a single session, all participants share the same live state. But since a session is just one instance of a scene, multiple sessions can also be created from the same source scene. Some may run independently, while others can be synchronized by the platform so that changes propagate across all of them in real time.

How these changes are treated — whether they disappear when the session ends or persist in the data model — depends on the session’s persistence mode.

Transient vs. Persistent Sessions​

A rendering session can be configured in two persistence modes: transient or persistent.

  • Transient session — no state changes are ever persisted. All modifications, regardless of client or action, are discarded once the session ends.

    Example: a design review session where users annotate or explore freely, but nothing is saved.

  • Persistent session — changes are written back to the data model as they happen. By default, actions are persisted immediately, but they can also be flagged as transient, meaning they only affect the live session and are not stored.

    Example: a world-building session where edits to geometry or materials become part of the permanent scene, while temporary elements like a viewer camera remain session-only.

Multi-User Collaboration​

A rendering session is not limited to a single participant. Several clients can join the same session at once, interacting with a shared scene in real time. Collaboration requires consistent state across participants, which is where the platform comes in as the source of truth.

Platform as the Source of Truth​

The platform maintains the authoritative state of every scene. Renderers hold only a live working copy of that state, sufficient to drive real-time interaction.

Every action flows through the renderer to the platform, which applies it to the authoritative state and propagates updates back:

  • Clients send actions to the renderer over Livelink.
  • The renderer forwards them to the platform, which validates and commits them.
  • The platform broadcasts updates back to all renderers consuming the same scene, keeping sessions synchronized across nodes and regions.

Roles and Permissions​

Client scopes control how participants contribute:

  • View-only clients may issue transient actions (e.g. spawn a temporary camera) but cannot make persisted changes.
  • Privileged clients can perform persisted actions, which the platform validates and stores.

This model allows heterogeneous participation: for example, a headless system can inject telemetry while viewers observe and interact — all while the platform ensures consistency across sessions.

Rendering Sessions at a Glance
  • One session
    One renderer process managed by the platform.
  • Scene
    Entry point hosted in memory for the duration of the session.
  • Joinable
    Multiple clients can connect to the same session.
  • Transient or persistent

    Actions may vanish with the session or be written back, per session and per action.

  • Synchronized
    Platform ensures consistency across sessions consuming the same scenes.

With rendering sessions defined, the next step is to examine the data they host and manipulate: assets — the building blocks of every scene.