-
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, geomrtry, shaders etc.) can be sent once (e.g. during an initialization phase) and then permanently stored on the receiving side until explicitly deleted.
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
- doesn't come with an ecosystem (designer and authoring tools) - it is supposed to be integrated in existing tools and UI systems and only provide the distribution, NOT design yet another ecosystem.
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. The RAMSES API is also well documented - you can read it directly in the source code, or generate a Doxygen-based documentation. To do so, you have to install Doxygen, run CMake (make sure CMake found the doxygen executable), and build the INSTALL target of RAMSES, which will also build the documentation.