Render Pipeline Interface Overview

The Render Pipeline Interface (RPI) is the central hub in Atom’s rendering pipeline. Developers can use the RPI’s C++ API or JSON files to customize the pipeline and create new features. The RPI is universal and platform-independent; It’s built on top of the RHI, which is responsible for communication with all supported low level graphics APIs. With the RPI, developers can:

  • Implement split views. For example, the Open 3D Engine Editor features multiple viewports, allowing users to view the level with different cameras at the same time.
  • Add new passes to the render pipeline. For example, the rendering pipeline can apply an anti-aliasing technique by creating and enabling the MSAA pass.
  • Develop new graphics features. For example, developers can integrate their own lighting solution or particle system without needing to modify Atom. Also, code for each graphics feature is contained in an independent module, which makes the process of adding features simple and robust.
  • Improve user workflow by configuring the preview window renderer. For example, in Open 3D Engine, users can set up lighting, background environment, and post effects in the preview window.
  • Develop and switch to other rendering techniques such as deferred or checkerboard rendering. (By default, Atom uses a forward+ render pipeline.)

In Atom, the RPI is an essential system that is responsible for managing many tasks in the rendering pipeline. The following highlights some of the RPI’s responsibilities:

  • Define and implement a data-driven rendering pipeline.
  • Define and consume fundamental graphics data assets such as buffer asset, material asset, image asset, shader asset, pass asset, and resource pool asset. However, it is not responsible for high-level assets such as level assets or terrain assets.
  • Set up the architecture to collect rendering data and coordinate different graphics features.

RPI Architecture

The RPI architecture is centered around the RPI System, the core system that drives the rendering. All other systems rely on the RPI, such as materials, images, shaders, passes, and buffers. The RPI System is a runtime singleton and is defined in the API as the RPISystem class. The RPI Architecture Diagram shows the different components of the RPI and its dependent systems.

RPI Architecture Diagram

RPI Code Organization

The RPI interface is split into several modules, each with its own responsibilities. The code for these modules can be found in the Atom Gem, which is located in the folder Gems/Atom/RPI/Code/Source/.

  • RPI Reflect: Includes data structures and corresponding help classes that are used to fill and validate data in the data structures. The data structures are used in runtime to create runtime resources and instances. Data is provided through asset files that are generated by the Atom Asset Builder.
  • RPI Public: Contains the runtime classes with public interfaces, such as buses or functions. These classes can be accessed outside of the Gem. The RPI System can be found in this module. Typically, asset builders do not depend on this module because the RPI System is not needed for data structure conversions. The material builder is an exception because it loads runtime shader assets through its asset handler, which is defined in this module.
  • RPI Private: Contains classes that are not required to be accessed outside of the gem. Currently, it contains the gem module class and system component class.
  • RPI Builders: Contains asset builders to build most of the RPI assets. The streaming image asset and shader asset are exceptions.
  • RPI Edit: Data structures need to be accessed by both asset builders and asset editors. This module allows communication between builders and editors without them directly referencing each other. For example, the MaterialSourData needs to be accessed by Material Builder to convert it to a MaterialAsset; it also needs to be accessed by Material Editor to generate the MaterialSourData data. To avoid Material Builder and Material Editor referencing each other, the RPI Edit module holds the data structures that need to be accessed by both of them.

RPI Assets

Atom’s render pipeline is configurable. We can load the configuration from data that’s contained in Assets, which are defined in the RPI. Assets contain data that’s needed for rendering, which eliminates the need to write device and GPU resources or hard-code the render pipeline. There are assets for resources such as image, buffer, shader, and material. There are also assets that hold data to drive the rendering, such as pass asset, render pipeline asset, and scene asset. Since assets are defined in the RPI, the RHI does not deal with assets or file systems directly.

Developing with RPI

Developers use the RPI to develop new graphics features or add 3D rendering support in their application. It’s recommended to develop with the RPI instead of the RHI because the RPI implements a data-driven feature, which simplifies many workflows. You can create and configure many assets, such as materials or shaders, by editing JSON files.

Here are a few brief pointers when beginning to develop with the RPI:

  • To use Atom Renderer for rendering, instantiate and initialize the RPISystem class.
  • The RPI::Scene class must be created and added to the RPISystem. The RPI::Scene holds the data to be rendered.
  • At least one instance of the RPI::RenderPipeline class needs to be created and added to the RPI::Scene. The RPI::RenderPipeline is used to describe how to render the data in the RPI::Scene.
  • The application must call the RPISystemInterface class’s SimulationTick function to perform the scenes' simulation, and the RenderTick function to have the scenes rendered.

Copyright © 2022 Open 3D Engine Contributors

Documentation Distributed under CC BY 4.0.
For our trademark, privacy and antitrust policies, code of conduct, and terms of use, please click the applicable link below or see https://www.lfprojects.org.


The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Policy page.