11
\$\begingroup\$

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/

\$\endgroup\$
5
  • \$\begingroup\$ I think this is too localized. \$\endgroup\$
    – jcora
    Oct 16, 2012 at 19:30
  • 4
    \$\begingroup\$ I think its a general question. Can a game object have multiple instance of the same component? \$\endgroup\$ Oct 16, 2012 at 19:36
  • \$\begingroup\$ Yeah, it could've been, if it was asked like that. To me it seems as if he was looking for an answer to a very specific problem. \$\endgroup\$
    – jcora
    Oct 16, 2012 at 19:39
  • 4
    \$\begingroup\$ "...entity in a component based system can not have multiple components of the same type..." - why not? \$\endgroup\$
    – Den
    Oct 16, 2012 at 20:40
  • \$\begingroup\$ I don’t think it’s too localised. For instance in UE3, SkeletalMeshActor only has one SkeletalMeshComponent. It’s a common problem that can be addressed in many different ways. \$\endgroup\$ Dec 30, 2012 at 20:53

4 Answers 4

13
\$\begingroup\$

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.

\$\endgroup\$
8
  • \$\begingroup\$ So I have a hierarchy of entitys and these entitys have componends and are linked togheter. Is it then still a Component based game engine =) \$\endgroup\$ Oct 16, 2012 at 19:44
  • \$\begingroup\$ @MathiasHölzl is that a question? This kind of hierarchy is not the same as the problematic hierarchy in OOP. This is just a graphical hierarchy, children Entities won't inherit functionality from their parent and give you trouble, this is usually done anyway (having a tree of stuff to render). You can also go with Asakeron answer to your problem, having a list of Meshs, I don't see how that's problematic. Maybe I don't understand your question? \$\endgroup\$
    – Luke B.
    Oct 16, 2012 at 19:51
  • \$\begingroup\$ -1 Not sure if that's really the way to go. If what you need is a component handling a hierarchy of meshes, why not having a ModelComponent that contains a hierarchy of meshes? Splitting an entity just for that sounds like the wrong solution to the problem. See Asakeron's and Byte56's answers. \$\endgroup\$ Oct 17, 2012 at 7:42
  • \$\begingroup\$ @LaurentCouvidou I don't see why using more than one Entity would be wrong, it seems like the a good solution for me. I just wanted to give a different alternative to having a list of meshs, though I agree that a list of meshs would also be a good solution. \$\endgroup\$
    – Luke B.
    Oct 17, 2012 at 10:34
  • \$\begingroup\$ @LukeB. Because this group of mesh can correspond to one entity as a whole, with components that depend on this e.g. AI, sound, physics... By doing this you end up with a scene graph and all its quirks. \$\endgroup\$ Oct 17, 2012 at 12:24
8
\$\begingroup\$

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.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ A mesh has also components like transform, physic, graphic... \$\endgroup\$ Oct 16, 2012 at 19:39
  • 1
    \$\begingroup\$ So a mesh is an entity? Or is everything a component? The way I see it, transform, physic and graphic should be components in the entity not in the mesh, a mesh is just a description of vertices. \$\endgroup\$
    – Luke B.
    Oct 16, 2012 at 19:43
  • 1
    \$\begingroup\$ Yeah it should be a component but components can not have components so its hard to implement the hierarchy of the model. \$\endgroup\$ Oct 16, 2012 at 19:47
  • 1
    \$\begingroup\$ I believe you should provide more information on how you intend to build your engine in order to get better answers. Entity Component Systems can be implemented in many ways, check this answer by Kylotan for more information on that. \$\endgroup\$
    – Asakeron
    Oct 16, 2012 at 19:52
4
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .