Entity-Component (ECS) for Scene Object Interface
Introduction
The entity-component architecture is a well known architecture used in many game engines (ECS is more widely used). The motivation behind it is the desire for modularity and extensibility of a scene object interface. The idea is to prefer composition over inheritance for the scene object interface. This allows one to add/remove functionality (components) to an object easily. This also allows things like object morphing as you are not tied to a subclass (ex: a PbdObject can become a FemObject by addition of PbdModel and removal of FemModel).
A quick simple psuedo-example for the very unfamiliar (note many ECSs are data oriented and may not have an update, or hybrid and have a subclass that then adds the update):
class Component
{
virtual void update() = 0;
}
class Object
{
Component[] components;
void update()
{
for (every comp i in components) { comp.update(); }
}
}
// One should subclass Component to add functionality to Object
iMSTK is well suited for this type of architecture due to the large amount of "intra-object customization" required by users. This has been on iMSTK's plate for awhile and it's been lightly moving towards/prepping for it for quite some time now (moving functionality out of the Objects).
Example Use Case
Here's an idea of something that could be possible depending on design:
- Ex1: One could construct a ThreadObject which contains PbdModel & AnimatedModel components. Which simulates a line mesh and skins it to a thread geometry.
- Ex2: One could construct a SkinObject which contains multiple PbdModel's, VisualModels, & GeometryMap components.
- Ex3: One could construct a SkinObject which contains one PbdModel but multiple VisualModels + GeometryMap components.
- Ex4: One could construct a all-in-one tool (say arthoscope head) which contains a Camera, Light, RbdModel, & GeometryMap. Possibly even multiple RbdModel's for each piece.
Continued details in documents: