STORM-IRIT / Radium-Engine

Research 3D Engine for rendering, animation and processing
https://storm-irit.github.io/Radium-Engine/
Apache License 2.0
100 stars 50 forks source link

Refactor Radium ECS and libraries #1014

Open MathiasPaulin opened 2 years ago

MathiasPaulin commented 2 years ago

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

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

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.

dlyr commented 2 years ago

Seems fine for me, now we need to identify a todo list to perform this refactor.