Refactor Radium ECS and libraries

Expected Behavior

It appears that the aim of Radium-Engine is clearly diverging (without forgetting) from its initial aim. Instead of being only a computer animation framework, with low rendering requirements, scoped geometry requirements and dedicated animation uses cases, Radium-Engine is becoming a general computer graphics framework which aim at defining 3D oriented data structures, algorithms and application component usable for any 3D related use case.

This evolution requires us to adapt, integrate and extends several software components of Radium-engine with more questions than answers.

This issue aims at opening discussion on the global design of Radium-engine framework to allow better adaptability and extensibility of the base framework.

Current Behavior

One major issue about the current design of Radium, as expressed in already opened/closed issues and their corresponding PR is that some data are not represented by a Ra::Core object but only by an Ra::Engine Object. (i.e. all data related to appearance : bsdf parameters, textures, ...). This limits the ability of an application to manage the lifetime of the object without thinking about OpenGL limitations and synchronization.

This is confusing and, in my opinion, results from a mis-interpretation we made when restarting Radium-Engine development such as Engine == all OpenGL/GPU stuff whereas Engine should be only the scheduler of all systems managing the data.

To ease the use of Radium software components to develop any kind of 3D related application, a huge refactoring seems mandatory and, even if doing it step by step, e.g. beginning with textures to decouple the data from their GPU adaptation, will take long times and need a common effort in defining the needs and their specification.

Possible Solution

If we refer to the basic definition of the ECS pattern used in Radium-engine (https://en.wikipedia.org/wiki/Entity_component_system) and as I understood it, we should have the following sketch about Radium-Engine Framework

Radium-Core : set of classes, data structures and CPU-side algorithms allowing to manage data (e.g. geometry, textures, bsdf, animations, ....)
Radium-Engine : set of classes defining the ECS implementation with :
- Entity being a top level object with only an id and a modeling transform, sharing ownership of all Components attached to the entity with a System
- Component being a specific aspect of the entity and associating Core-Data with some System related requirements.
- System defining how to process the Entities having the desired component to generate some results the other systems can use
Radium-App : set of classes allowing applications to interact with the Engine to manage the lifetime of entities, components and systems
Radium-Gui or Headless or ... set of classes that make the interface between the host system and the Radium-App

Taking as an exemple how to manage textures, we may have

On Radium Core, a Texture class managing only the data as arrays of texels, with format description and access functions, and a Sampler class defining the function and its parameters to access a given texture information (with, e.g., mip-map filtering or without filtering or wrapping or ....)
On Radium-Engine : a Component that associates a Core Texture, a Core Sampler and their OpenGL representation that will be use by one or several OpenGL synchronizer system. We can also think about a component associating a Core Texture, a Core Sampler and their Vulkan representation, to be used by Vulkan related systems, ...

This kind of representation is already present in Radium-Engine for Geometry management : Core-Geometry, GeometryComponents and GeometrySystem.

With this kind of approach, RenderObject might be removed and replaced by a RenderingComponent attached to the entity and managed by a rendering system (not restricted to OpenGL.

The discussion is opened, feel free to add your requirement on ECS implementation according to your use cases or the way you want to use the Radium-engine framework. In your suggestion, be as precise as you can to define your use case and the way you imagine it could be handled by the ECS pattern.

STORM-IRIT / Radium-Engine