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.
I made a bunch of changes in apps/openmw/mwrender/animation.cpp
because the scope brackets didn't line up in a bunch of places
npcanimations.cpp & creatureanimations.cpp were the same kind of
thing
This is a fix for segfault:
==8683== Process terminating with default action of signal 11 (SIGSEGV)
==8683== Access not within mapped region at address 0x0
==8683== at 0x59DFE4: MWRender::Animation::handleShapes(std::vector<Nif::NiTriShapeCopy, std::allocator<Nif::NiTriShapeCopy> >*, Ogre::Entity*, Ogre::SkeletonInstance*) (animation.cpp:503)
==8683== by 0x5A4ECE: MWRender::Actors::update(float) (actors.cpp:134)
==8683== by 0x5937A9: MWRender::RenderingManager::update(float) (renderingmanager.cpp:168)
==8683== by 0x629AD6: MWWorld::World::update(float) (world.cpp:705)
==8683== by 0x68B022: OMW::Engine::frameRenderingQueued(Ogre::FrameEvent const&) (engine.cpp:157)
==8683== by 0x51F9574: Ogre::Root::_fireFrameRenderingQueued(Ogre::FrameEvent&) (in /usr/lib/libOgreMain.so.1.8.0)
==8683== by 0x51F964F: Ogre::Root::_fireFrameRenderingQueued() (in /usr/lib/libOgreMain.so.1.8.0)
==8683== by 0x51F9681: Ogre::Root::_updateAllRenderTargets() (in /usr/lib/libOgreMain.so.1.8.0)
==8683== by 0x51F98CF: Ogre::Root::renderOneFrame() (in /usr/lib/libOgreMain.so.1.8.0)
==8683== by 0x51F990C: Ogre::Root::startRendering() (in /usr/lib/libOgreMain.so.1.8.0)
==8683== by 0x68A669: OMW::Engine::go() (engine.cpp:408)
==8683== by 0x51CECB: main (main.cpp:254)
==8683== If you believe this happened as a result of a stack
==8683== overflow in your program's main thread (unlikely but
==8683== possible), you can try to increase the size of the
==8683== main thread stack using the --main-stacksize= flag.
==8683== The main thread stack size used in this run was 8388608.
when doing 'coc "seyda neen"' when animations are enabled
(Animation::animate member variable is set to 1).
