For instance if I set an entity to be the parent of another entity and then polymorphically create one to be a PhysicsEntity and the other a RenderEntity, should this even be allowed?Because right now each UpdateForParent the RenderEntities cast their parent IEntity to a RenderEntity, take its transform and use it to calculate the transform of the entity.Not sure how to implement the PhysicsEntity into this tho.Maybe when a PhysicsEntity has a RenderEntity child, it should turn the centerof the bounding volume into a transform matrix and use it to affect the transform of the child RenderEntity and when it's a PhysicsEntity being a child of the RenderEntity, to create a transform from the center of the bounding volume of the PhysicsEntity and offset it by the parent's transform matrix?Or is it better if I just make it assert(parent->GetType() == this->GetType()); ? Which would make things easier but disallow some flexibility.
How do you handle entities which have a parent of a different type?
Crossbones+ - Reputation: 1518
Posted 23 March 2013 - 05:41 AM
I think you are taking a wrong approach to the whole entities-system. Instead of having different entities like physics, rendering etc... you probably want to have an Entity/Component system where you have a generic Entity that you assign different components to using composition. Have a read at http://www.gamasutra.com/blogs/MeganFox/20101208/88590/Game_Engines_101_The_EntityComponent_Model.php.
Then, you have two big options: Eigther you have your components act like you wanted your entities to do: Contain data and and logic, handling stuff like submitting rendering commands to your renderer etc... . The other option, that I personally like best, is to have your components be stupid POD type structs, that only contain stuff like i.e. for your render-component a pointer or ID of your mesh, a material, and an effect. You then would have systems that handle all the logic, like RenderSystem, etc... This is preferable since you avoid your problem of having to pass information between the components - systems can easily extract these without a problem. Have a look at EntityX' implemenatition, you can use this lib without any problems if your compiler supports C++11 and unless you really want to know how an EntitySystem is created and know a lot about templates/variadic templates.
Members - Reputation: 918
Posted 23 March 2013 - 07:37 AM
If you do not want to go with a full entity/component approach, you probably will need a base scene node class that has a transform, and derive both RenderEntity and PhysicsEntity from that. At the point when you implement eg. skeletal animation, you will likely need these kinds of scene nodes anyway to represent bones.
Going this route, you will then likely need a virtual function that is called when the transform changes, which actually updates the transform into the relevant (physics or rendering) subsystem.
Parented physical objects will need special attention, because usually physics libraries deal only in world coordinates and do not use parent-child hierarchies themselves. Just be sure to transform the coordinates to the correct space when handling updates into either direction (from your scene graph to the physics engine, or the other way around), and update parents first and then recurse to children.
Edited by AgentC, 23 March 2013 - 07:44 AM.
Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...