This reverts commit 376dfed15b.
I was wrong. It's needed at least for NPCs since they're attaching multiple
animated skeletons to an object, and they all need to be offset correctly.
Would be nice to use a Node, Bone, or TagPoint instead of a hefty SceneNode,
though.
This reverts commit d6f923f274.
We don't need it for any of the NIFs we're currently handling. As long as
there's no NIF files that would break it, we should require a stationary root
if an animation wants to accumulate. If we must, a better idea may be to inject
an extra bone into the skeleton instance and make that the accumulation root.
Couple reasons for this:
* This paves the way for allowing animations specified in other skeletons to
be applied to the character (NPCs and certain creatures can have multiple
animation sources, but Ogre is incredibly strict when it comes to sharing
animations between skeletons).
* It will allow for entities to be animated based on the character's skeleton,
without having to duplicate the mesh for each skeleton it can be used on.
This doesn't impact Ogre's ability to efficiently deform skinned meshes, nor
does it get in the way of hardware skinning.
This is so the animation specifies node keyframe data based on the node's
parent. This will also be necessary for applying animations from different
skeleton sources, as they can have different binding positions (even native
.skeleton resources will need to specify animation data this way).
Animations that move a character may do so either visually or physically. An
axis' accumuluation value specifies whether the movement is visual (0) or
physical (1). Idle animations, for instance, typically don't physically move a
character, while death animations may physically move them along the X and Y
planes, but not along Z (the vertical movement is purely visual).
I think it's safe to assume all text keys are treated in a case-insensitive
manner. So far the only known NiTextKeyExtraData records are for animation
keys, which effectively are.
