Render System and Component Hierarchy
Posted 20 November 2011 - 08:04 PM
At first, I took this approach, stuck a name plate component and a mesh component for my avatar on my entity, those two components self registered with the render system and kaboom! The subsystems were designed that for a specific entity, only 1 component of a given type (in this case base type is renderable) could be associated to a given entity. I made a few changes to the container API and now the subsystems can manage multiple components for the same family within a particular subsystem, such as the render subsystem. But this feels wrong to me because if I need to update name plates after meshes, etc then I loose that ability because the render system seems all those components it manages as a common base type, "renderable" so the notion of order between various renderables is non-existant.
So taking a simple example, a mesh system, name plate system, and lighting system. Each system handles a single component type but they all require some level of access to the render engine to perform their job. Additionally, some of these require a scene node which is what my existing render component provides. Is it common practice to have multiple renderables per game object or should my render engine expose it's API via an interface and that interface be provided to the mesh, name plate and lighting systems?
Posted 20 November 2011 - 08:27 PM
On the other hand, you could make a renderable a higher-level object that represents multiple draw calls and knows how to do each of them. In that case it might make sense to have a single renderable per object, or perhaps per component.
As for order control, one way to do it is to associate various sort keys with renderables, and update / render them in the order implied by the keys. For instance, the nameplate update key could be later than the mesh one. But the render keys might be in a different order than the update keys, based on the order things need to be drawn for correct appearance. For efficiency, not to have to totally re-sort everything on each frame, you could carry over last frame's sorted lists, and only update them when new objects are spawned or sort keys get changed (if you allow them to change).
Posted 20 November 2011 - 08:58 PM
From a separation of concerns perspective, it seems bad to have a high-level render component that knows how to do ALL these things, but maybe that is how it is done in commercial software. The concept of a "sort key" is very new and one which I haven't even seen introduced before in any articles or design documents about this particular architecture. Typically, I see that functionality should be broken down into simple components and subsystems, which would follow one for meshes, another for lights, one for name plates, etc. But they each of these require the ability to invoke things on the render engine.
My first thought was that all these various subsystems (mesh/lights/name plates) would be provided an IRenderer interface during their construction and during the update() call to those subsysetms, they could use this IRenderer interface to invoke drawing methods. Another solution to be totally decoupled without an interface would be to take the interface API and create events from those calls and simply have these various subsystems dispatch events to create lights, meshes, or to fade a light or destroy a light source, etc.
Ideally I would prefer to keep from having OGRE referenced in so many component and system files because I believe it should be encapsulated so should I change engines down the road, I could with minimal efforts. But maybe I am either suffering from over-engineering or over-generalizing too, idk.
Posted 20 November 2011 - 09:51 PM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users