Creature Animation

Everything about development and the OpenMW source code.
User avatar
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland

Creature Animation

Post by lgromanowski » 15 Aug 2011, 09:41

jhooks1 wrote: I tried the same method that I used to animate NPCs on creatures. Right now it crashes when you enter a cell with one or more creatures. This method did not crash with NPCs, but it did not look pretty either (see NPC thread for video). The code is in the animation branch on github.

I am not sure what is wrong, hopefully I can figure this out. Animation is going to be one of the hardest features of OpenMW to implement. I think we may need multiple people working on this to get creatures and NPCs animated properly.
jhooks1 wrote: Problem 1:

In ogre_nif_loader.cpp the last line of loadResource must be as follows

Code: Select all

 // set skeleton
  if (!skel.isNull())
This is for NPCs or creatures to be animated. I can tell the creatures are running through the animations, can see the time is being added to them in the log. When I get close to the creature though, we get a crash before we see them getting rendered.

Problem 2:

Another problem is that some cells that will crash immediately when the previous code is in place. One cell with this problem is "milk"

To fix this I used (and this is what we have set up in the Attempt (crashes) commit))

Code: Select all

if (!skel.isNull() && mesh->isLoaded())
This breaks the cells that have animation though, because the skeletons don't get linked. I need to figure out a compromise between these two.
jhooks1 wrote: mesh->_notifySkeleton() is what is behind the crashl, not the animation. For some reason it makes creatures unrenderable and crash openmw. I think there may be something wrong with the way we are handling skeletons.
sir_herrbatka wrote: That was a risk we all knew.
jhooks1 wrote: I was wrong, some creatures work some don't. I tried Ainab and saw an ash zombie being animated. I will post a video soon. I think the creatures that crash openmw do not have the root bone set correctly.

EDIT: What is happening is some NiNodes are being encountered but the root bone has not been seen yet, thus there is no skeleton yet. The nodes are not revisited, so they never get attached to the skeleton
jhooks1 wrote: I made the nif loader look for a bip01 by iterating through all the records before it calls handleNode. If a bip01 is seen a skeleton is created. I thought this would solve the skeleton link crash but it did not.

For now I am just going to focus on the creatures that do not make openmw crash. Right now the same problem is occurring that we had before with NPC animations, knees do not bend etc.

I think this problem is because Morrowind bones inherit transformations from their parents. The existing code in handleNode():

Code: Select all

    // Apply the parent transformation to this node. We overwrite the
    // existing data with the final transformation.
    if (trafo)
        // Get a non-const reference to the node's data, since we're
        // overwriting it. TODO: Is this necessary?
        Transformation &final = *((Transformation*)node->trafo);

        // For both position and rotation we have that:
        // final_vector = old_vector + old_rotation*new_vector*old_scale
        vectorMulAdd(trafo->rotation, trafo->pos, final.pos.array, trafo->scale);
        vectorMulAdd(trafo->rotation, trafo->velocity, final.velocity.array, trafo->scale);

        // Merge the rotations together
        matrixMul(trafo->rotation, final.rotation);

        // Scalar values are so nice to deal with. Why can't everything
        // just be scalar?
        final.scale *= trafo->scale;
I think something similar to this needs to be done with the Animation tracks.

One way I can think of now are applying an ancestor's NiKeyFrameData to all descendant bones, the data for one ancestor would be contained in one Animation object. Then these multiple animations could be blended.

Another way would be to make a custom animation system.

I am going to look at the NifSkope source code and see if I can figure out what they did to handle animation. If I can find the relevant code maybe it can be applied to openmw.
jhooks1 wrote: I haven't worked on openmw much. I am looking at the NifSkope code, mainly the gl folder, which I think contains all the relevant code for animation. Still haven't made much sense of how this code correctly animates nif models and what approach we should take.

Here is the video of the ashghoul that I forgot to upload
jhooks1 wrote: I got tired of looking at the nifskope source, so I tried the alternate option of the blending method I mentioned above. It did not work properly though.

At this point I think we are going to have to switch from ogre's built-in animation system to something custom. Looking at nifskope's source again may give me more clues about what needs to be done.
Zini wrote: @jhooks: It looks like you are stuck with the animation system. Going for creature animation was the logical decision after you had acquired experience with the problem during your work on NPC animation. But actually creature animation is low priority feature. We are in no hurry to finish it. Maybe you would like to take a break from animation stuff and try something else for a while?
jhooks1 wrote: That is probably a good idea, I will look at the roadmap and see what I am interested in working on.
Zini wrote: Okay. Let me know if you need assistance with finding something.

On the current roadmap, finishing these would be particular helpful:

But any other unclaimed task on that list would be okay too. If you don't find anything there, we can also try to add a new task to 0.11.0 from the rest of the list (though a larger number of these have prerequisite tasks that haven't been completed yet).
jhooks1 wrote: So right now resources such as nifs must be loaded from bsas, and can't be loaded from a separate file?

That doesn't sound too hard to fix.

I may divide my time between this and a custom animation system, or I may just work on this new task. We'll see.
Zini wrote: Actually, I think it does work on Windows. The problem is the difference in file systems. The best solution is to make a new Ogre Filesystem class (derived from the existing one). We probably should scrap the file finder component and re-route sound resources through the Ogre resources system. Also the situation where a file exists in a bsa and in the regular file system needs to be handled (the one in the file system takes precedence).

If you want to discuss this further, you should open a separate thread though.
jhooks1 wrote: In the current state nothing happens when rotating and translating creature bones.

I think that the code in handleNiTriShape() that applies the NiSkinData to the NiTriShapeData needs to be run again each time we make a transformation. This means that the submesh buffers will need to be overwritten.
best regards,