What is the benifit of having...

[c_olin]

... Entities AND scene nodes? Because for every entity you have to have a scene node right? Why not have a node inside of the entity class?

Just a thought...

[monster]

yeah, but you don't have to have an enitity for every scene node, and you can have more than one entity per scene node

[c_olin]

True statement, but wouldn't it be equivilent to have an 4 entities in one node than to have an Entity with an internal SceneNode and just have one main entity and add 3 children?

[monster]

possibly, but why would that be better? for starters you'd have an additional transformation between the main entity and it's children - conceptually all 4 entitties are in the same place, so why should you represent them as one entity in one place and 3 others in (potentially) 3 different places

[sinbad]

The other major reason is that it keeps the inheritence graph of SceneNode (which is a spatial class) and Entity (which is a world instance class), completely separate, allowing them to be specialised independently. Without this concept you end up with a horrible class hierarchy when you try to specialise scene management structure AND world object types. Some engines use concepts like 'EntityNode' and 'TerrainNode' - which I think is a major design mistake. What happens when you want to specialise a node BOTH because of the object type, and the scene partitioning approach? You're buggered, that's what - you end up with the cartesian product of the combinations like BspEntityNode, OctreeEntityNode, BspTerrainNode etc, or you have to try to wrap them in each other which doesn't really work well.

Spatial structure specialisation and world object specialisation are separate design concepts and our structure recognises that.

[c_olin]

Thanks for the reply... You made a lot of good points but I still disagree to an extent. Because for example: I'm going to write an "EntityFactory" for my game, and have a class hierarchy of different types of entities, IE "Triger" or "SpawnPoint" or "ClientPlayer" or even "Light". So in my "EntityFactory" I need to have a list of entities as well as a list of nodes? It seems logical to me to create the first generic entity class which all other entities are based on with it's own scene node.

I wrote an "EntityFactory" for the Irrlicht Engine awhile back and I included a scene node for every entity. It worked out fine.

I'm not doubting your knowledge, obviously you know what you are talking about. But it still seems like it's a better way. I would greatly appriciate it if you can talk me out of this because I don't want to do anything that can be done better, and not do it the better way.

BTW I'm not critasizing your engine design, it's good that SceneNode and Entity are seperate but it seems to me that at one point they need to meet.

[leedgitar]

It may have worked fine, but what is the justification for going that route? In Ogre, it is easy to attach arbitrary objects to a Scene by associating your own object with a MovableObject via setUserObject(). I've done some small examples where I have my own custom class heirarchy which is totally independant of the engine's class heirarchy. The base "GameObject" class has a link to a scene node which is automatically assigned to it by a factory. The GameObject gets notified of the scene node assignment and stores it off, and all helper methods (like move, rotate, etc) all operate on the underlying scene node. The Entity that represents the game object has a link to to game object via setUserObject(). Since that link is there, engine features such as scene queries and what not can be used to grab your objects, because scene queries return movables, which you can use to grab a reference to your game object via getUserObject() and do what you please.

Alot of times, containment can be a simpler and more flexible solution that inheritance.

[Kencho]

BTW I'm not critasizing your engine design, it's good that SceneNode and Entity are seperate but it seems to me that at one point they need to meet.

That point is where I would create a wrapping class that would "batch" both the entity and the scene node

BTW: You mention an entity "Light"... That's not the same as an entity in Ogre

[haffax]

I'd vote for the wrapper class, too. I'm currently reworking our code. We used a similiar approach you, c_olin proposed. But this lead to a really ugly class hierarchy with multiple inheritance, that was very difficult to expand.
Now we'll have a class called Actor that contains references to the SceneNode, the MovableObject, the OgreOde::Geometry and the GameObject it represents. This class contains many useful high level functions that do the dirty work in the SceneGraph for us.

This approach doesn't hinder you from creating useful factory methods. For instance we have:

Code: Select all

Actor* ActorManager::createMeshActor(const String& name,const String& meshname, GeomType geom, Ogre::Real density)

This creates a Entity, a Geometry of the givien primitive type (e.g. a capsule) and an OgreOde::Body if density is greater than 0. The factory method then decerns the geometry's parameters through the mesh size infos. It wraps everything neatly into an Actor instance and registers it in our Actor registry.

Many different factory methods are thinkable, but you can also manually create it for maximum flexibility.

[c_olin]

Thanks for all of the feedback. Actualy before I posted here I had already started a wrapper. What it made me interested why Entity and SceneNode were not together.