Entity Hierarchy

Coordinator
Dec 6, 2007 at 4:19 PM
Apparently there is much to be discussed about this topic, so heres a new thread for which to do that. :)
Dec 6, 2007 at 9:35 PM
Edited Dec 6, 2007 at 9:35 PM
Depends on what you mean by Entity Hirarchy. The hirarchy in itself isn't all to complicated and I could envision something like this
    Entity : IUpdateable
        | DrawableEntity : IDrawable
 
    EntityGroup<T> : where T class, Entity
        | DrawableEntityGroup<T> : where T class, DrawableEntity
(I know the group inhericy isn't all legal, but something like that)

But there are going to be a lot of types inheriting from Entity and DrawableEntity do you want to discuss those or did you want to discuss the properties of the Entity classes?
Coordinator
Dec 7, 2007 at 6:06 AM
Edited Dec 7, 2007 at 6:08 AM
Well, we definitely need to clarify all the types of entities.

For instance, we have things that will have physics applied to them, and things that won't. If we were using only that logic we'd have two types. However that isn't the case, we also have things that are drawn and things that aren't. Now we have a possible matrix of possibilities including:

- Drawn, and collidable
- Drawn, but not collidable
- Not drawn, and collidable
- Not drawn, and also not collidable

We can't have both (derived from BaseEntity) because C# does not allow for multiple inheritance (and rightfully so in my opinion). This likely still leaves us with multiple options, here are the ones I see:

1. Have all things that can recieve physics also be drawn. This would mean that collidableEntity was derived from the type drawableEntity. (Inheritance)
2. Have all things that are drawn also have physics considerations. This would mean that drawableEntity was derived from the type collidableEntity. (Inheritance)
3. Have drawableEntity with a bool for whether or not it has physics considerations.
4. Have collidableEntity with a bool for whether or not it is drawn.
5. Have physics setup through an object type that isn't part of the BaseEntity heirarchy, such as a PhysicsBody class. DrawableEntities could optionally have a PhysicsBody or not. (Composition). This would allow entities that are drawn to have physics or not. However, if PhysicsBody isn't of type BaseEntity then it couldn't be an BaseEntity on its own. This being the case, how would we have physics collisions with something that couldn't be drawn? I guess it is possible to give a BaseEntity a PhysicsBody rather than just letting DrawableEntity have it.

There are probably more options, these are just what I've got at the moment. The names of these classes are just for example. I'm trying to spark some discussion on this so we can get going with it.
Dec 7, 2007 at 6:29 AM
I was planning along the lines of option 5. Physics actors can be drawable or non-drawable, and drawable entities aren't necessarily physics entities (i.e. you don't need collisions with particle systems or volumetric effects like fog). If an entity needs a representation in the physics world, then let it create an instance of a physics actor, which is queries each frame for updated position/orientation.
Dec 7, 2007 at 7:19 AM
Using a actor pattern here does seem like a good idea. And since the data now resides inside the entity you should not have the overhead of property accessors.
Dec 7, 2007 at 8:57 AM
Iget drawable but not collidable, but what kind of things are collidable but not drawable? Please dont say invisible walls :)
Dec 7, 2007 at 9:02 AM
Audio emitters, proximity triggers, black holes, and such.
Coordinator
Dec 7, 2007 at 11:45 PM
Edited Dec 8, 2007 at 12:34 AM
I need your guys' advice on something. As I'm designing a camera interface I've come across a small dilemma. I think it would be useful to attach all camera's to an entity. Now, I don't mean they have to be fixed onto an entity, just that it belongs to that entity. That way if I want to see player3's fixed camera I can simply pass a message to the camera interface telling it which player, and which camera/cameratype. This seems ok, but then I think to myself, what if I just want a camera flying around the world, that doesn't belong to anyone? Then I though, well what if the world itself was a base entity? This would allow the world to have its own cameras and possibly other things down the road. I've never thought of something this way, so I'm not sure if it is even a good idea or not, thought I'd bounce it off you guys first.

I was also thinking about an parent/child entity relationship. Any of you that've used Ogre may understand this already. As an example I could have the parent entity be a human torso. Then I could give the human 4 limbs, each are a child of the parent. Well what is the benefit to this you ask? Well if I rotate the torso 15 degrees, it would in turn rotate all child entities by that much. Makes it much easier to "connect" things together.

If I had the "scene" as an entity, everything could be a child off of it. If I wanted to rotate an entire scene (not sure if I would really need to, much it might be neat to see), then everything in the scene would rotate as well.

Another benefit is that if a parent entity was destroyed we could easily chose to destroy all of its children, recursively. Or if we simply chose to render the parent, we could render its children recursively as well.

These are just some thoughts I had, I don't know if it would make sense or really be efficient, or just be too much work.

Don't need answers to all of these now, although I am wondering how to setup the camera interface, and if I base it on entities I can use a dictionary to store all of the camera's, but if the camera's are not all attached to entities and some are free, then I couldn't use entities as a key for the dictionary, and may have to use a list, which is more flexible, but less efficient.
Dec 8, 2007 at 12:42 AM
Actually over in Prototype design we did discuss this. But lets take it from the top.

  • Cameras are entities and can be attached to anything in the world
  • Everything is a entity, even the world
  • Entities contains entities, and should have the behavior described above (Adds complexity, but makes really good user experience)
  • SceneManager is a Entity, and therefore contains entities.
  • Entity implements IDisposeable, and does relevant cleanup
Dec 8, 2007 at 1:07 AM
I thought a scene manager "manages" the entity hierarchy... not belongs to it.
Coordinator
Dec 8, 2007 at 5:33 AM
Is it possible to have it as an entity, but not have it manage itself? This is definitely confusing, but at the same time I think that it could be useful to be able to treat it as an entity, for things like attaching a camera to the scene.
Dec 8, 2007 at 5:43 AM
I was thinking you would have a scene manager which handles the entity hierarchy, and have a root terrain node to which you can attach your cameras and all other "free" entities.
Coordinator
Dec 8, 2007 at 6:41 AM
That is something to consider. The terrain could be a root entity possibly. Or it may not have to be an entity.

My main issue is how to organize the camera interface so I can attach cameras to "something". If I could have the main scene/terrain act as an entity I could attach a camera to the scene just like I would any other entity in the game. If you look at the CameraInterface.cs class you can see where I'm going with this. Of course, this is just one way to do it. If there is a better way to setup the Interface then I'm not really as concerned with the main scene acting as an entity.
Dec 8, 2007 at 12:54 PM
Giving it some more thought the SceneManager can't be a entity, it only contains entities (and is responsible for update/draw calls).

There can only be one root entity per node in the SceneManager I envision something like this:
public class SceneManager
{
    public ICollection<TerrainEntity> Terrains;
    public ICollection<Entity> Entities;
    public ICollection<Entity> Skies;
    public ICollection<Entity> Waters;
    public ICollection<Entity> Sounds;
    public ICollection<Entity> Cameras;
    public ICollection<Entity> Shaders;
    public ICollection<Entity> Screens;  // HUD
}
If you need to attach a camera to the player I could imagine something like this:
CustomGame.cs
{
    public void SomeMethod()
    {
        ...
        this.Player.Mounts[MountPoint.Camera] = this.SceneGraph.CurrentCamera;
    }
}
Every entity potentilly have a set of mount points, on these mount points you can attach other entities.

The mount points are defined in the model, there could be head, torso, left/right arm/leg etc. And also a mount point for the camera. This way the modeller can design humans to have camera mount point at the eye level, and when doing a Mech that could be placed in the stomach area.
Coordinator
Dec 8, 2007 at 7:38 PM
Well there is certainly the possibility of a mounted cameras, but most of the cameras will simply point at the model's origin, or relative (0, 0, 0). Having a requirement for mount points may require extra work for any artists working with the engine, but I agree it should be a possibility. I used mount points for a game in which you could mount different weapons to a player, and it worked out nicely.
Dec 8, 2007 at 9:41 PM
Mounting cameras to another entity gives the posibility of attaching cameras at different places on a Mech for one, which would provide rear/side/overhead views. For the player sitting inside the Mech, along with forward view.

Yes, this meas some extra work for modellers, but most engines I've encountered have this requirement. Though not for first person only engines.

An artist wouldn't have to do anything in which case we would simply default to a specific position relative to the model. The importer would simply add a mount point for the camera if noone was defined for the it.

We shouldn't have any predetermined number of possible mount points, any number of points should be possible.
Coordinator
Dec 8, 2007 at 10:48 PM
I'll look into having a MountableCamera which can be derived from. I'm not sure if the arc-ball camera could derive from it, the free camera definitely wouldn't, but the fixed camera absolutely could. I'll likely develop an FPS camera that could mount to the position of a model's eyes, or where they would want to "see" from, like the head on a mech.

I agree a single entity should be able to have multiple of the same type of camera, this is one problem I've found with the current CameraInterface design. Luckily I'm not using the Interface until it is ready, so I have no problem scrapping it if needed.
Dec 8, 2007 at 11:21 PM

LordIkon wrote:
I'll look into having a MountableCamera which can be derived from. I'm not sure if the arc-ball camera could derive from it, the free camera definitely wouldn't, but the fixed camera absolutely could. I'll likely develop an FPS camera that could mount to the position of a model's eyes, or where they would want to "see" from, like the head on a mech.

Why do you need a mountable camera? What's the difference between a mountable and the standard camera? Since cameras are entities they can be mounted at any point, this is the idea behind it all.


LordIkon wrote:
I agree a single entity should be able to have multiple of the same type of camera, this is one problem I've found with the current CameraInterface design. Luckily I'm not using the Interface until it is ready, so I have no problem scrapping it if needed.

At this state I really do not see the reason for having interfaces for entities. So unless you have a valid scenario for it, I think we should keep away from creating more.
Coordinator
Dec 8, 2007 at 11:34 PM
It sounds like your idea of mount is basically how I had a Vector3 'Target' in the template engine. For some cameras it could serve as a point where the camera must be 'mounted' at that exact position (like an FPS camera), and for others the camera would swivle or look at that position. If all it is a position of an entity, then I think we're close to talking about the original system I had planned, where all camera's needed an entity to attach to, except this 'mount' idea could include a position offset from that entity.

I'm still left with the issue of having a camera as the only 'entity' in a scene. Let us say we have a completely empty scene, and only a camera to fly around, currently this wouldn't work because the CameraInterface will require every camera belong to an entity.
Dec 9, 2007 at 12:23 AM
There shouldn't be any requirements to entity that it requires another entity (Well at least not base entities, I guess, there might be special case entities). This goes for camera as well. You will want cameras which are floating around, which do not have any target nor attached to a mount point.

But there is another way to this. If you say that we will only allow cameras which are attached to something and you need a camera which is just floating somewhere, we could just create a null type entity and attach the camera to that.
Coordinator
Dec 9, 2007 at 6:14 AM
That is what I was thinking, something like BaseEntity sceneEntity, which could be a single entity that you could attach a camera to.
Coordinator
Dec 9, 2007 at 6:30 AM
Edited Dec 9, 2007 at 6:34 AM
By changing StaticEntity constructors to require the game reference be passed to them you can no longer instanciate entities inside of a scene, which currently has no need for game. If we're going to require all entity types have a game reference, then most of the engine's classes are going to require a game reference as well. Should we really be passing game around to everything just so entities can have it?

Not only that, but it seems to me that it breaks OO practices. Entities are handled by systems, these systems should be controlling their entities I would think, rather than having the entities referring to the game on their own. Letting all entities control themselves, or have the ability to control themselves, we're removing usefulness of management systems I would think. For example, the cameras don't do anything on their own (other than reactions, like collisions). The cameras do what they're told by the CameraInterface. So if I send a message to strafe the camera, I send the message to the CameraInterface, and the interface calls that camera's strafe method. This requires no need for the camera to know about the game, only that the game knows about the camera.
Dec 9, 2007 at 11:39 AM
Well there are many reasons to expose Game throughout the engine. The most important one I can think of is ContentManager, which you make accessible simply by making it a Singleton. I don't believe it should be a singleton, as it's "just" a element in the services collection.

Talking OO paradims, the Singleton pattern is often refered to as a anti-pattern as it promotes global variables. I do admit that they most certainly have their validity, I use them, but when designing new systems I rather look for other patterns to use. Having the Game as a property on our types and having the need to pass it at constrution, it is strictly not needed, instead we could pass SceneManager, this would give access to Game as SceneManager references game, but limit entities to one SceneManager.
Dec 9, 2007 at 5:44 PM
How can you have an entity that belongs to multiple scene managers? That seems like just asking for trouble.

About content manager, I would actually prefer to have multiple content managers. Eventually, graphics content can be loaded through one, entitiy content loaded through another, GUI content through yet a third. Maybe even have multiple content managers in the scene manager, one per "area", or multiple in the graphics system. This allows you to easily dispose of a content manager when you're done with its content.
Dec 9, 2007 at 6:28 PM

shawmishrak wrote:
How can you have an entity that belongs to multiple scene managers? That seems like just asking for trouble.

You can't (or shouldn't), but if you have multiple scene managers, you would want to move from one to another.
Coordinator
Dec 9, 2007 at 6:59 PM
Who said anything about multiple managers? Just one scene manager, but multiple scenes. I don't see any reason to have an entity belong to multiple scenes, however, you can certain move entities back and forth between them.

My thoughts on processing two scenes at a time (which would happen if you were near the border between two scenes), is that you process one, and then the other, simple as that. The only problems I see is if an entity is standing right on the border of a scene. What is to determine which scene it belongs to, and if it only can belong to one, how would something on the scene collide with it? In this case it might make sense to allow the entity to exist in both scenes possibly for some purposes. I don't think graphics will care either way, it seems like it will only care what is in the render queue, and if you process both scenes, whether it is one or the other it will end up in the queue, we'd simply need to make sure we didn't put it into the queue twice.
Dec 9, 2007 at 9:14 PM

LordIkon wrote:
My thoughts on processing two scenes at a time (which would happen if you were near the border between two scenes), is that you process one, and then the other, simple as that. The only problems I see is if an entity is standing right on the border of a scene. What is to determine which scene it belongs to, and if it only can belong to one, how would something on the scene collide with it? In this case it might make sense to allow the entity to exist in both scenes possibly for some purposes. I don't think graphics will care either way, it seems like it will only care what is in the render queue, and if you process both scenes, whether it is one or the other it will end up in the queue, we'd simply need to make sure we didn't put it into the queue twice.

The problem here is that you certainly do not want to update it twice as well, also a entity can only belong to a single scene, it might be moved but not exist in more than one.

Physics also cares much about currently loaded entities, so wwe can just duplicate it.
Coordinator
Dec 9, 2007 at 9:21 PM
Well something I haven't looked into is processing everything at once in the scene manager. Physics could go through all entities in the world by getting them from the scene manager rather than the scene. I'm not sure if there are performance implications. The border between scenes is mostly for loading, but I can foresee things like A.I. not letting certain enemies through scene boundaries, while letting others through.

The more I think about it, the more work I see being done in the scene manager rather than a scene. I see the scene as a container that holds information about things entities, sky, weather, boundaries, etc. But when it comes time to process things like physics, AI, or even rendering, that could be done all in one pass, treating all the loaded scenes as a whole.
Dec 9, 2007 at 9:27 PM

LordIkon wrote:
Well something I haven't looked into is processing everything at once in the scene manager. Physics could go through all entities in the world by getting them from the scene manager rather than the scene. I'm not sure if there are performance implications. The border between scenes is mostly for loading, but I can foresee things like A.I. not letting certain enemies through scene boundaries, while letting others through.

Physics will not touch the entities in any way, this would be too expensive, instead entities which should be controlled by the physics engine will register an actor which the physics engine works with. This will limit the amount of data presented to the physics engine and remove the pesky Property overhead from the physics engine.


LordIkon wrote:
The more I think about it, the more work I see being done in the scene manager rather than a scene. I see the scene as a container that holds information about things entities, sky, weather, boundaries, etc. But when it comes time to process things like physics, AI, or even rendering, that could be done all in one pass, treating all the loaded scenes as a whole.

When standing with the SceneManager the dev shouldn't be concerned about implementation, bacially he should just invoke Update/Draw and the manager does the right thing.
Coordinator
Dec 9, 2007 at 10:32 PM
Agreed on both counts.
Dec 18, 2007 at 11:01 PM
Edited Dec 18, 2007 at 11:01 PM
Hijacking this thread ;)

In another discussion (Question)

LoadIkon wrote:
The StaticEntity class will likely be the class that does not require a model, or rendering. I've actually put comments to this effect in the code. I believe entities with models will inherit from StaticEntity, and then (optionally) they'll have an physics model, or actor.

Particle emitters, sound emitters, would be things that would be static entities.


I don't like the word static for these entities. There is nothing static about sound of particles. Also why would they not simply inherit from Entity (Sound) and DrawableEntity (Particle)?
Dec 18, 2007 at 11:07 PM
I thought we were doing away with the DrawableEntity, PhysicsEntity, etc. classes? Composition instead of inheritance would work better in this case, I think.
Coordinator
Dec 18, 2007 at 11:11 PM
Well at least on the physics part I was talking about composition, as they could optionally have a physics actor. However I'm not really sure how to do rendering. If it has a model we could assume it needs to be rendered, unless its visibility is set to false. There may be conditions I haven't thought of where that wouldn't work.
Dec 18, 2007 at 11:13 PM
Ah yes, I still got my head stick into the drawable/nondrawable, but of cause this is not really an issue using the rendering queue.
Dec 18, 2007 at 11:19 PM
I dont see it being an issue. A node either has a geometry container attached or it doesn't. If it doesn't, you can just hardcode a IsVisible=false property and do nothing in the render queue query method.
Dec 19, 2007 at 9:44 PM
Hijacking again :)

StaticEntity - Can someone explaing why this is called static?
Dec 19, 2007 at 10:23 PM


Sturm wrote:
Hijacking again :)

StaticEntity - Can someone explaing why this is called static?


I too would like to know.
Coordinator
Dec 19, 2007 at 10:57 PM
Seriously, who chose that name? Oh wait, that was me.

I pictured static as a basic entity unaffected by physics, that didn't need to move, but may still need to render if it has a model, and would still update (for particle emitters and sound emitters).

This was before we had any talk of a physics actor, or an entity that was or wasn't renderable.

We can change it if we need. I just needed some kind of entity for the camera to attach to, and I believe the BaseEntity class should be abstract.
Dec 20, 2007 at 2:36 AM
Yes would be nice if we would change the name, maybe ModelEntity as it's hooked directly to a model? Also the StaticModel should be renamed to something different I quess, as there is nothing forcing staticness on the model loaded?


LordIkon wrote:
Seriously, who chose that name? Oh wait, that was me.
We can change it if we need. I just needed some kind of entity for the camera to attach to, and I believe the BaseEntity class should be abstract.


I'm still not all with that, simply because a Camera should be a entity, which should be able to float by itself.
Dec 20, 2007 at 3:03 AM
The StaticModel name is derived from it not having any animation data, i.e. its movement is static. Eventually there will be a SkinnedModel/SkeletalModel class(es).