Flow Render Engine Architecture

The project pursue a rendering engine with a modular architecture design, totally decoupled of the graphic API used in a simplest manner as possible, to get a good scalability, this decoupling allows to be able to implement the rendering behaviour with different existing graphic APIs, without modifying anything of the common underlying layers, such as are Core layer and Graphics layer. To get this, the Graphics layer mainly declares an interface that finally is implemented in the GraphicsOGL3 layer with a determinate graphic API.

In this case, the graphic API implementation, it's made with OpenGL 3.x for now.

The engine is mainly organized with three layers, see diagram above, each module has a name that defines the global functionality within the engine, this layers are defined as follows: Core, Graphics and GraphicsOGL3.

This layers are related between them starting from bottom layer to up layer, in this case the Core layer is related to Graphics layer and Graphics layer is related to GraphicsOGL3 layer, and so, all the layers build the engine. The reason to split the engine with layers pursue the goal to group the functionality of rendering engine by topics and software level, at the same time, to get more definition granularity the modules are split in submodules internally using name spaces.

Below is a brief description of each layer that will be expanded in the engine layers definition and implementation.

The Core layer, is the lowest software level of the engine, maintains the system functions a general application framework and common utility functions like mathematics library especially designed and implemented for this render engine, with the common functionalities for computer 3D graphics, all is separated with submodules.

The Graphics layer, is build on top of the Core layer, is a platform-independent module that defines different submodules with different data structures and mechanism to store and manage the geometry data in computer memory, before being sent to the graphic card memory to be rendered. This layer defines a rendering interface that is implemented within the GraphicsOGL3 layer.

The GraphicsOGL3 layer, implements the rendering interface declared in the Graphics layer, this implementation builds the bridge between the rendering interface and OpenGL in this case, this module is platform-dependent and could be implemented with different manner with other graphic APIs like Vulkan or Direct3D as well, getting different layers for each graphic API as shown in the diagram above, however, for the moment is implemented with a modern computer graphics paradigm with OpenGL 3.3 only.

The diagram shown above, depicts the structure discussed above, and how the applications use the rendering engine in conceptual manner, the diagram shows GraphicsVK and GraphicsDX layers, but this kept in grey color, due to not implemented for the moment, however, it shows for better understanding.

Rendering interface approach

The rendering interface main goal is to provide an easy-to-use entry for coding graphics both in 2D and 3D. This approach must to enable the developer should not bother about graphics API specific details. Therefore the interface abstracts graphic device features in a graphics-API-independent way.

The rendering interface itself, provides all common rendering operations like creating, vertex and index buffers, textures, shaders, with a factory approach, finally this interface is implemented in the GraphicsOGL3 module with the OpenGL graphic API, which can be loaded and switched at runtime, therefore this module must be seen as a plug-in. The interface concept makes the Graphics layer, completely independent from the underlying hardware and any graphics API like OpenGL, Direct3D or Vulkan

Concretely the rendering interface has been implemented with OpenGL 3.3 only, however, the interface approach leaves ready the engine to be implemented with other graphics APIs like Vulkan or Direct3D, but in case to be implemented it, with Direct3D, the engine and the applications would not be portable to other platforms for obvious reasons, since Direct3D is a graphic API for Microsoft Windows only.