   Now where did I put my skeleton...?
  In my engine, I have a component-entity system.  An entity can become renderable by adding a renderable component.  The renderable component contains a reference to a mesh object (amongst other things) which is used when the renderable component is rendered.  Now that I've introduced a relatively self-contained skeleton object, I was wondering what thoughts anyone had on where this might live.Conceptually, it might make sense to have the mesh store a reference to the skeleton.  But a mesh may be a solid thing like part of a building or a fallen tree, in which case a mesh with an unused reference to a skeleton feels like it's breaking the component-entity model somewhat.  So should I add the skeleton object as a component of the entity or not worry about the unused reference and store it within the mesh?  Thing is, my 'native' mesh code (which currently just adapts the DirectX9 mesh classes) is inside my graphics library (the game library accesses objects in the graphics library via their interfaces only).  The graphics library doesn't really lend itself to the maths involved in the pose calculation and animating processing within the skeleton.  I'd prefer my skeleton to reside in my animation library (for obvious reasons), so making it a part of the mesh feels logistically wrong.  The only output from the skeleton object at the moment is a palette of matrices representing the current pose which gets passed to the skinning shaders.When rendering the entity, a simple check to see if it has a skeleton component and a call to get its computed pose matrices might work but does it sound like a bit of overkill?  I appreciate I've probably answered my own question but it would be good to get someone else's views...   
Quote:Now where did I put my skeleton...? I sure hope not in the closet [grin]Obvious pun aside, I can only chip in my thoughts on how my XNA code is taking shape at the moment. XNA has some structure predefined, which I'm keeping around because it just makes sense. Instead of a Mesh, XNA works with a Model as the base object. This Model object contains a collection of Mesh objects which roughly match your typical DirectX mesh. I think this is mainly to support the FBX file format, which allows multiple meshes to be stored in a single file. From what I've seen this conceptually replaces the mesh/subsets idea in DirectX, although that is also still supported.The Model object also holds a collection of Bone objects, representing the skeleton. This collection is defined regardless of whether the model has skinning information. If skinning information is available, the collection contains your typical skeleton. If not, the collection contains a 'bone' for each mesh, representing the transform from the origin in model space 1. This makes the Bone collection conceptually fit in as a component of any model, skinned or not.Next up XNA uses an AnimationPlayer to store animation keyframes and compute the palette of matrices representing the current pose. The AnimationPlayer also contains a copy of the skeleton hierarchy and stores the bindpose information. I think this is also conceptually sound, since the poses computed by the AnimationPlayer are tied to the skeleton, but could potentially be applied to any model with the same bones, which could be useful for instancing. This is where the XNA structure ends (the skinning code is just a demo sample after all) and you're left with a Model and an Animation player. This is already a rather good split between graphics & animation and roughly matches your mesh/skeleton split, but with different terminology. My challenge is actually putting it together properly, along with a pile of other features I'm trying to fit. I'd like to go with an SkinnedModel subclass of Model that comes with an AnimationPlayer so it can render itself, much like your setup, but unfortunately the XNA Model class is sealed so it cannot be extended. Hmmm, looks like I've got a bigger design problem than you [smile]  1)  This is an incredibly useful feature to have, since it enables elegant 'local' mesh transforms without needing further information. For example consider you want to rotate a cannon mounted somewhere on a ship around the local 'up' axis for aiming. Without knowing the position of the cannon on the ship (ie in model space), you can't construct a rotation matrix to do this. Those fake bones however exactly describe this position and can handily be used to transform the cannon to its local space, rotate it there and move it back to model space.;Quote:Original post by remigiusI'd like to go with an SkinnedModel subclass of Model that comes with an AnimationPlayer so it can render itself, much like your setup, but unfortunately the XNA Model class is sealed so it cannot be extended. Hmmm, looks like I've got a bigger design problem than you Why not having the SkinnedModel with a Model* and an AnimationPlayer* instead of extending Model? (which would be the right thing to do if you could...);Quote:Original post by ArKano22Why not having the SkinnedModel with a Model* and an AnimationPlayer* instead of extending Model? (which would be the right thing to do if you could...)That's the backup plan. Conceptually I think the SkinnedModel is-a specialized Model, so in my mind a subclass would be a better fit. Since that's not really an option though, Model* and AnimationPlayer* will probably be the route I'm taking anyway. Out of curiosity, why do you consider this the right way?