Ramses concepts

Overview

Ramses is a framework for distributed rendering of 3D content. It was initially created to visualize 3D scenes across different devices in the car which are reachable over a network. Ramses was initially developed by the BMW Group and is currently hosted on The BMW Car IT Github organisation as a free and open source software under the MPL 2.0 license.

Components

RAMSES consists of three logical components:

• client (creates and publishes 3D content)
• renderer (consumes and displays)
• daemon (global address broker, exchanges connection info between clients and renderers in case the underlying communication is TCP)

These components can be deployed as separate applications and communicate over network, or can be all used in a local rendering setup (within a monolithic application) - or in various hybrid combinations.

The Client component

Clients create scenes and manage their content, but cannot decide if and where a scene is shown (similar to a video stream which provides the video, but anyone can subscribe to it). For details on the various features of the Client API, see the following sections:

• RAMSES Client API
• RAMSES Validation
• RAMSES Resources
• RAMSES Effects and Binary Shaders
• RAMSES Rendering of Text

The Renderer component

Renderers act as content consumers, they can subscribe to content changes from clients and show it on screen. Renderers cannot change scene content directly, but can control when a scene is shown/hidden, in special cases can render off screen (RAMSES Offscreen Buffers) and link certain types of data across scenes.

For details on the various aspects of the Renderer, see the following sections:

• RAMSES Renderer API
• RAMSES Offscreen Buffers
• RAMSES Content Expiration and Time Limited Validity of Content

The Daemon component

In TCP-based a network deployment, the daemon "broadcasts" the existence of clients and renderers to each other (providers and consumers of scenes, respectively). This allows clients and renderers connected to the same daemon to find each other. After this initial discovery the communication is via a direct connection between to the clients and renderers.

Other communication middlewares normally include a discovery mechanism already and make the ramses daemon superfluous.

In a purely local rendering setup where the only clients and renderers are within a single process the daemon is normally also not needed.

Component deployment and communication

The three RAMSES components (client, renderer, daemon) can all live in the same process, or can be deployed across different processes or even different hardware units. Depending on the concrete deployment, Ramses will use different communication channels to send data from the client to the renderer. If the client and renderer are in the same process, they will not use any network communication, but will exchange data over local memory. If the client and renderer are not in the same process, the connection will be established over a network protocol (TCP by default).

Advanced concepts

Ramses offers some additional features and concepts which are specific to distributed rendering and designed to make it easier to share, link, composit visually demanding content in a environment with strict timing and performance constraints.

The DCSM protocol

The DCSM (Display Cluster State Management) is an additional protocol and API layer which resides both on the client and the renderer components. It is designed to give a fine-grained control over the state of content other than just showing and hiding it. See the section on DCSM for a general overview of the DCSM features. The scene referencing explains how to let scenes reference other scenes and control their state remotely.

Compositing

In addition to distributing 3D scenes, Ramses can composite other OpenGL native applications using the Wayland protocol. The Wayland protocol enables efficient compositing of 2D images with zero copy (i.e. no pixel buffers are copied throughout the system unless when directly rendered to the screen). In the RAMSES case, it is called "embedded compositing" because the RAMSES renderer is itself composited into the system compositor. Thus, applications which connect to RAMSES via Wayland are "embedded" into the RAMSES renderer, which is in turn "embedded" into the system compositor final rendering. For more details regarding embedded compositing visit the documentation page dedicated to it.

Examples

If you prefer to see code instead of reading diagrams and concepts - consider looking at the code examples.