-
Notifications
You must be signed in to change notification settings - Fork 58
Home
RAMSES is a distributed rendering engine designed with embedded platforms in mind. In a nutshell, RAMSES is a library/middleware which allows to have different processes running on multiple devices across a network in a way that one process provides the visual content (3D graphics), while another process renders it, potentially on a different network device, virtual space or a hypervised environment. RAMSES supports different deployments - one provider and multiple consumers, multiple providers and one consumer, or a mixture of both. The applications running RAMSES have the flexibility, but also the responsibility to choose how to work together to form what we call a display cluster - a union of displays and devices which appear to coexist in the same ecosystem, despite their difference in hardware and platform/OS.
As every software, RAMSES has strengths and weaknesses. RAMSES provides:
- abstraction of OpenGL -> don't have to write your own OpenGL code
Everybody who ever wrote an OpenGL based rendering system knows that it is a powerful API but not trivial to implement. Things like extensions, texture formats, binary shaders, threading can be cumbersome to implement and tricky to maintain.
- multiple versions of OpenGL
RAMSES supports different versions of OpenGL (ES 3.0+, desktop OpenGL 4.2, 4.5 ...). This allows the same code to be deployed on multiple platforms, even if they don't support the same OpenGL version.
- rich feature set
RAMSES is a low level API, close to OpenGL. It provides all the tools needed to minimize data traffic between provider and consumer, to enable running high quality 3D applications across network without noticeable delay or flickering.
- embedded support
Nowadays embedded targets have become more powerful and easy to use, but there are still things which are different than desktop/server development. RAMSES provides features to address that: DLT logging, remote shell execution, compatibility to a wide set of compilers, automated test suite, designed to deploy and run the tests on an embedded system over ssh
- serialization to files and caching
Possible to store assets and scenes in files for optimized start-up and loading. Also supports caching on the receiving side, so that data (textures, geometry, shaders etc.) can be sent once (e.g. during an initialization phase) and then permanently stored on the receiving side until explicitly deleted.
- Editor with GUI and headless mode
Comes with an editor which allows composition, version management and import from other tools. Find it here!
Using RAMSES could have following downsides:
- it is easy to write a RAMSES application, but it takes effort to design it in a way that it has a low memory and data bandwidth footprint
- has explicit, low-level API, as opposed to some existing engines, which have a convenient, high level API
You can find instructions how to build RAMSES in the README.md file.
We believe the best way to learn is by example. You can take a look at the bunch of examples included with the RAMSES SDK, which demonstrate individual features of RAMSES. You can find instructions how to run them here. For a complete reference on the RAMSES API, have a look at the Doxygen pages.
RAMSES implements a "provider-consumer" architecture with multiple providers and multiple consumers which can be mixed and matched. The RAMSES daemon connects all content providers (RAMSES clients) and all content consumers (RAMSES renderers) in the same network. Every client can provide any number of scenes, each scene having a global unique scene ID. Each renderer is notified of all available scenes on the network, and can subscribe and show a selected set of scenes. It is possible to combine a client and a renderer into once process, which allows more efficient data transfer for graphical content which is only shown locally and never distributed over network. For more details and concrete explaination, check the presentations available on the Genivi Confluence pages