Jump to content
  • Advertisement
Sign in to follow this  
BlackJoker

"Bind" Entities to Entity

This topic is 1432 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I start writing my own engine not so long ago and now trying to write Entity framework.

 

If I understood it correctly, It contains several lists with IUpdatable and IDrawable components.

 

This is good if I have only 1 mesh in my entity, but I want to timplement a little bit different behaviour.

 

But what if I have, for ex., a space ship consists from a 1000 meshes?

How to manage such situation? Need I create something like a mesh class with meshes list inside?

 

I can iterate through the collection of meshes, Ok, but what if I want to attach another meshes to this ship? For ex, a crew? And I want that these meshes automatically update their positions when ship update its position?

How to "bind" them to the ship?

 

And another question is this correct approach to create mesh component with meshes and submeshes collections (submeshes for that cases if one mesh splitted by different materials)???

 

P.S. I am writing on C# in XNA-like framework and now study Elephant framework as an example to write my own Entity framework.

 

 

Share this post


Link to post
Share on other sites
Advertisement

As I understood, I must get the entity`s children and call the transform on it recursively? If I not using parent/child hierarchy on the component.

The main thing I cannot understand is that all components are present in global list separately from entitty itself, so, in that case I could do transforms for the same entites few or more times and it will break everything.

 

This architecture just blow my brain each time I am thinking on it.

Edited by BlackJoker

Share this post


Link to post
Share on other sites

It also seems to put code logic in the components themselves, as opposed to systems that operate over components (as is more common these days)

 

Could You give some example of this? Because I cannot understand why it should be done that way. Each component has its own small logic and know how to work with itself.

Why I need to make class over the components, which will mainatin the logic for each component type?

 

Whats the profit from this?

Edited by BlackJoker

Share this post


Link to post
Share on other sites


But what if I have, for ex., a space ship consists from a 1000 meshes?
How to manage such situation? Need I create something like a mesh class with meshes list inside?

An entity usually has one mesh, but a mesh often need to be build by sub-meshes. Actually vertices are hold in sub-meshes, not in meshes. However, this is done to be able to attach different materials to different parts of the mesh. The placement of the entity in the world is used for the entire mesh.

 

If you have the need to attach meshes to other meshes at runtime, like e.g. the crew members and the spaceship, sub-meshes are obviously not the correct solution. Instead, you create a spatial relation between a crew member and the spaceship. This kind of relation is usually called "parenting" and implements a forward kinematic (but notice that other possibilities exist as well). Notice that parenting a crew member to the spaceship is done at runtime; the crew member may leave the spaceship at some time and hence the parenting will be destroyed. Other parentings may exist for the entire runtime of the game.

 

To express parenting you can use a tree hierarchy, i.e. you can have a child-entity list inside an entity. IMHO this isn't the best solution. I prefer to express relations between entities explicitly, i.e. to instantiate a Parenting object that will further be used to calculate the global placement of the "child" object from its local placement and the global placement of the linked parented object. So the instance of a Parenting object expresses the current existence of a relation, its kind, and the necessary parameters (the local placement and the link to the parent entity, in this case).

 


As I understood, I must get the entity`s children and call the transform on it recursively?

The important aspect is that things fetched from elsewhere are ready-to-use when being requested. One possibility is recursive calling. For example the global placement of a parented entity should be calculated. One term of the calculation is the global placement of the parent entity. When those placement is requested, the method first checks whether the placement is up-to-date. If not, it first calculates the new placement, perhaps again by requesting another placement. However, it returns the own global placement if and only if it is ready-to-use. The other solution to the problem is a so-called dependency graph. It is a structure (a sorted list is sufficient) where dependent objects occur logically behind objects they depend on. So when updating that structure it is guaranteed that dependencies are up-to-date simply because they are processed before the dependent objects.

 


The main thing I cannot understand is that all components are present in global list separately from entitty itself, so, in that case I could do transforms for the same entites few or more times and it will break everything.

Looking at the description of parenting entities above, what we have is the following:

 

* A collection of meshes, each one with a collection of sub-meshes.

* A collection of global placements, so that exactly one can be associated with each mesh.

* A collection of relation objects, e.g. Parenting instances. Each one means that the targeted global placement is dynamically computed.

 

Now think that during running the game loop one part is responsible to update the global placements (in fact there are more than one part, e.g. animation, physics, mechanisms like parenting, collision correction). This part iterates the collection of Parenting objects which may be given in dependency order. The update just needs to access a global placement and the Parenting code (which itself accesses the local parameters, of course). No need to access the mesh or whatever else makes the entity in its entirety. When later in the game loop the graphical rendering is processed, it just accesses the global placement and the mesh. There is no need to known about Parenting or such.

 

As you can see from this example, distinct stages during processing need access to only a particular subset of all of the entity components currently existing in the scene. Having such subsets already separated at hand is fine.

Share this post


Link to post
Share on other sites

haegarr

 

 

 


An entity usually has one mesh

 

In that case, if I have model build up from 10 meshes, I need to create 10 entites, which will have their own transform component, but will be updated at once somehow?

 

Didnt get the idea how it must work.

 

Why not create Entity per model, intead of Entity per mesh?

 

How I will understand, that these set of Entites represent a complete model?

Edited by BlackJoker

Share this post


Link to post
Share on other sites

"Usually" doesn't mean "ever"... and there are many ways to do things. Say, what is a concrete example of your 10 meshes from the same model?

 

Look at a car with a body and 4 wheels. The 4 wheels each need their own placement because the combination of position and orientation is unique for each one. Their rendering material is different from those of the car body. You can now say that the entire thing is an entity, but then you need to have a sub-level of some kind of entities, and you need to express the relation. The car body has a mesh with, say, 6 sub-meshes, one for the tin parts and 4 for the windows. Each wheel has a mesh with 2 sub-meshes, one for the rim and one for the tyre. Each wheel has a global placement controlled by a parenting with the car body entity as parent (although I'm using a Chassis4Wheel component which not only provides 4 slots at once but also some physical simulation parameters).

 

When you look at the problem, there is no real reason why the wheels cannot be entities side by side to the car body entity, which are nevertheless related to the car body entity by parenting. Each entity by itself is complete and can be described by the entity/component concept. You are used to think of a car as one entity, but in fact it is just an assembly of many parts, each one existing by itself, and a broken wheel hub (the physical equivalent of the parenting) will separate a wheel from the car.

 

On the other hand, an antenna which will never be detached from the car (or spaceship) and has ever the same placement can easily be implemented as a sub-mesh.

Share this post


Link to post
Share on other sites


Could You give some example of this? Because I cannot understand why it should be done that way. Each component has its own small logic and know how to work with itself.
Why I need to make class over the components, which will mainatin the logic for each component type?
 
Whats the profit from this?

 

Share this post


Link to post
Share on other sites
Optimize where you need it.

You can make very large, complicated games that run with perfectly good frame times using simpler and more flexible component models. You'd want to apply data-oriented design to things like your particle engine, physics engine, renderer, etc., but the applicability to game logic (which is where components live) is something you have to weigh on a game-by-game basis.

You also don't need components do _everything_. For instance, the idea that each game object has a single mesh is a little... limiting. The renderer should have its own efficient data structures that involve parent-child relationships of scene modes/meshes, and the component that binds game objects to rendering can just reference a node in that tree (not necessarily a leaf node). Now you can have a single game object that loads a complex model that has multiple meshes, materials, etc. You can have whole models that aren't even game objects at all, which is handy for mesh particle emitters, UI systems, and so on.

Components are for entities, which are game objects, which are a game system, which are in the layer that sits above the engine services like rendering, physics, and so on. Don't shove your components into layers they don't belong in. Once you separate properly you will likely find that you don't ever do any of the things ECS are supposed to help with compared to simpler, easier, more flexible game object component models.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!