How can I use multiple meshes per entity without breaking one component of a single type per entity?

Question

We are just switching from a hierarchy based game engine to a component based game engine. My problem is that when I load a model which has a hierarchy of meshes, and the way I understand, is that an entity in a component based system can not have multiple components of the same type, but I need a "meshComponent" for each mesh in a model. So how could I solve this problem.

On this site they implemented a Component based game engine: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Answer 1

Your Position component could have a "parent/children" logic, where any Entity with a Position may have a parent and their position is relative to their parent. Instead of having several meshs on the same entity, you can make more than one entity, each with its own mesh and link them together. You can even make the children entities listen to their parent events (or whatever system you have for communication between entities) and react accordingly.

Answer 2

Your meshComponent may contain a list of meshes. I'm not sure how you are implementing your engine, but a system could easily iterate over all meshes and simply draw them.

Answer 3

I would create my mesh component with a list of mesh objects. Each mesh object has the mesh data along with an offset. When drawing, the drawing system takes the position from the position component, then draws each mesh in the mesh component at position + offset.

You can have multiple meshes inside your mesh component, while still saying with a single mesh component per entity.

Answer 4

TLDR: By making the component consist of multiple meshes to begin with.

I agree with Asakeron/Byte56/Laurent in that another level of indirection is needed between the mesh/material pairs, and the entity itself. Instead of looking at the GraphicsComponent as vertices and materials, think of it as a blob of pixels on the final raster - how it/they get there is an implementation detail and nothing more.

I thought about this a lot for my project and I think the optimal solution is to make the GraphicsComponent a much higher level component, encompassing much of the functionality of the traditional 'Model' object - because this functionality isn't optional! To render those polygons a lot more than just the buffer data and the shader is needed, such as:

• Position which you have mentioned
• Skinning/Animation data
• The Current Pass (e.g. if using two pass alpha)
• Shadow casting information (if you are doing it)
• Information on how and when to update the material
• Culling functionality

And thats just for 3D assets, without considering particle systems, billboards, etc. But all of it is pertinent only to the graphics/rendering code - it doesn't affect the physics, sound or scripting, so it makes sense it should sit in the Graphics/Rendering component.

I ended up with:

Model : Entity, IHasGraphicsComponent, IHasSkeleton, IHasAnimationStore     //This is the 'game object' - it is passed to the GraphicsController
    ModelComponent : GraphicsComponent                      //This is the actual graphics component, used by the GraphicsController in the context of the game object.
        ModelComponentPart : GraphicsComponent              //This is also a graphics component
            Mesh                                        //These are implementation details
            Material
        ModelComponentPart : GraphicsComponent
            Mesh
            Material
    Skeleton
    Animations

In this:

• Model is any game asset that has a graphics component.

• The ModelComponent is analogous to the traditional Model and in fact, is, for 3D assets. The GraphicsComponent controller (if you use the Model-View-Controller pattern) is responsible for figuring out what type of graphics asset it is and drawing it correctly (note that ModelComponent is a subclass of GraphicsComponent).

There were also a couple of compromises in mine for simplicity and backwards compatabilitys sake, such as each GraphicsComponent is also an Entity, and Entity stores Position data directly so its only calculated in one place, but the idea is the same: GraphicsComponent handles what is needed to draw the item - all of what is needed - not just what comes from the modeller.