Animation Blending broken in Irrlicht 1.8.0

[Mel]

@fmx: If handedness was a problem, then, it should be tested with both Open GL and D3D to see if there is a diference between them. From what Christian says, the problem seems to be that the animation ranges become messy, if the animations are correct, although, misplaced, then, the problem isn't with the animation blending, but the ranges.

[christianclavet]

@cuteAlien: Ok. I'll write a simple demo that you can make the goblin walk/run on a fake ground plane. I'll try to do it before next week. I'll post the link when completed.

I sincerely hope you'll find what is the problem, because that feature was really great. I really don't understand why others are not using more of this in their projects (animation blending), it make the animation changes so clean! Since I was first able to use it, that one of my Irrlicht favorite features!

If I could add details of my observations on the problem look like some bones are flipped BEFORE animating.

Animation range since first frame to a specific frame, seem to work (idle pause seem to be oriented the proper way)
Animation range from a specific frame to another frame, a bone seem to flip and then animate. (as it's moonwalking because the root bone seem to have flipped) The orientation of the bone seem to reverse (180 degree). The animation is playing properly, but a bone is being flipped somewhere.

On the goblin, it seem to affect the root bone, and on the magician, a bone in the back.

If I don't use animation blending (sniff), I don't see any problem.

[CuteAlien]

@cuteAlien: Ok. I'll write a simple demo that you can make the goblin walk/run on a fake ground plane. I'll try to do it before next week. I'll post the link when completed.

Take your time, I'm really busy this week (and likely next) anyway due to job. Sorry if this got broken, I tried to be really careful going over changes line-by-line back then, but guess I still missed something. Or maybe it's one of the other changes... but I can figure that out then.

[wing64]

Try new goblin. May be this solve your problem.
http://www.upload-thai.com/download.php ... 8df0f14354

[Mel]

I have tried the SVN 4394. with my own skinning system, and the blending works as expected. I think the problem lies somewhere in the skinned mesh construction process when the EJUOR_CONTROL is workinig. The mesh should be built somehow else.

[fmx]

I've been really busy for the past month, haven't even worked on any of my own projects let alone testing stuff in irr 1.8

Mel if you're sure that blending code is not the culprit, then the problem has to be either in the construction of B3D skeletons (joint heirarchies), or screwed up keyframe data being stored from B3D files.

looked at the Changes.txt file for B3D and this change cropped up since 1.7:

- Fix b3d loading of files with mixed mesh/bone sections

Whoever made this change might have a better idea of what happened... hopefully

i'll look into the problem closer after i'm free for christmas holidays, but next week or so I'm going to be busy as hell unfortunately

[Mel]

After i made that post, and reviewed the skinning code, i realized that the X format stores, besides the animation matrices, the inverted animation matrices, If they are present, aren't calculated. Maybe that is where the problem is?

The shader for skinning i use picks the global animated matrix and the global invert matrix of each joint to build a transformation matrix for each bone, i feed this to the shader, and that is how it works.

[fmx]

yeh you need the inverted global transformation for each joint stored as well as the initial bind-pose, that's how skeletal animation works.
So in the X loader, irrlicht uses the provided inverse matrices?
What about B3D loader?

Recalculating bind-pose matrices and inverse global transformations might seem like a foolproof way to get around the problem indefinitely, but that can potentially break all keyframe information (which would be relative to the original bindpose and inverse-global transformations before the recalculation)

So if the B3D loader is recalculating the bindpose and initial global transforms for joints, then the keyframe information would also need to be corrected, OR the loader shouldn't recalculate but use the provided matrices.

If the B3D loader ISN'T recalculating those matrices but using the provided ones, then the inverse matrices and bindpose transformations cannot be the problem...

...
yeh I should stop being lazy and just look at the source

[Mel]

The problem is that although i get how the things work, i can't really figure out the reason because of the animations break the models when rendered, using the blending system. Suposedly, the inverted matrices are also present for the normal animations and they work,

[johann_gambolputty]

Hi , so could someone finally figure out what are those empty joints in the mesh ? After loading my mesh i always end up twice as much joints that the mesh actually have. (I use panda exporter and 3ds ,max)
Also these joint have no name and i'm assuming they're safe to remove as they have no frames or weight data. This arises two questions :
- How to safely delete these SJoints ? Simply erase them from the array or i need to delete them first ?
- I'm also not familiar with the irrlicht containers but as far i can see irr::core::array has no iterators so how can i easily remove items at random positions from the array like in std::vector?

Code: Select all

std::vector<CData*>::iterator it = someContainer.begin();
 
while (it != someContainer.end())
{
       if ((*it)->Name.size() == 0)
       {
             delete (*it);
             it = erase(it);
       }
      else ++it;
}

i know i could build a temp array and push_back all items that have "Name.size() > 0" and then copy this array back to the mesh's Joint array... but thats just feels a bit hacking

[christianclavet]

Hi,

I would not recommend removing the joints that are parented. I tried that and the situation was worse. I never got the time to do a "test" application for it, but now suspect that Irrlicht doesnt like something from the mesh informations. With some other models it work fine. In the end, I only enabled the blending for the player mesh has it was ok with this mesh so far.

For the problematic meshes, when playing for example the walk animation, the character(Goblin) was oriented backward (moonwalk), then playing the attack animation, the model turned to the correct orientation for that animation. For other models (the mage), the walk animation was oriented correctly, then when attacking the model turned 180 degrees in 1 frame to attack oriented backward. When the animation blending is disabled, the orientation of the characters are not affected and everything play correctly.

The only character that play all their animations correctly now is the player character, and hope it will continue to work when I will replace the character. As for a test application, I never got the time to make it, because I would need to create a walking/attack animations with moving and would require much more work. To ones that want to check and see the exact behavior, download IRB with the source (Linux-Windows), and enable back animation blending in the source:

To enable it for the NPC: Uncomment in DynamicObject.cpp at line 2026: Current code:

Code: Select all

 
void DynamicObject::update()
{
... 
    // Call the animation blending ending loop Doesnt work in 1.8.0, need to have a patch for it in 1.8.1
    //if (this->objectType==OBJECT_TYPE_NPC || this->objectType==OBJECT_TYPE_PLAYER)
 
    if (this->objectType==OBJECT_TYPE_PLAYER) // || this->objectType==OBJECT_TYPE_NPC)
        ((IAnimatedMeshSceneNode*)this->getNode())->setTransitionTime(0.35f);

If you uncomment, the NPC will have their transition time set at 0.35; For the animateJoints it's done for the player and the NPC and doesnt affect the behavior. It's only when this line is uncommented that the NPC start to play and behave weird. Seem to be directly related on how the skeleton is created, as the behavior change from model to model.

If you still want to see how I set the animateJoint check on DynamicObjectsManager.cpp starting line 1888.

Code: Select all

//! This is used for animation blending, need to be called at each update refresh
//! Since Irrlicht 1.8 this seem to cause problems with certain models
void DynamicObjectsManager::updateAnimationBlend()
{
     for(int i=0;i<(int)objects.size();i++)
    {
        if (objects[i])
        {
            if (objects[i]->getType()==DynamicObject::OBJECT_TYPE_PLAYER || objects[i]->getType()==DynamicObject::OBJECT_TYPE_NPC)
            {
                ((IAnimatedMeshSceneNode*)((DynamicObject*)objects[i])->getNode())->animateJoints(false);
            }
        }
    }
}

Both of these are updated at each frame.
The way it's done now: (All done before doing the render)
- 1. Do a "dynamic object" update, set the transition time. one object after the other.
- 2. Do another pass, after that to animate the joints one object at a time.