Bug on the skinned meshes

[Mel]

I have found an inconsistency between the EJUOR_READ and the EJUOR_CONTROL modes of the skinned meshes.

Tracing all the process, the skinning works properly, but the update of the bone nodes doesn't happen correctly on the EJUOR_CONTROL skinned meshes. Taking a peek to the code of the getMeshForCurrentFrame() method of the CAnimatedMeshSceneNode class, in the file CAnimatedMeshSceneNode.cpp, in the source directory, there is a conditional that is executed when the mode is EJUOR_READ:

Code: Select all

 
        if (JointMode == EJUOR_READ)//read from mesh
        {
            skinnedMesh->recoverJointsFromMesh(JointChildSceneNodes);
 
            //---slow---
            for (u32 n=0;n<JointChildSceneNodes.size();++n)
                if (JointChildSceneNodes[n]->getParent()==this)
                {
                    JointChildSceneNodes[n]->updateAbsolutePositionOfAllChildren(); //temp, should be an option
                }
        }
 

There is a "slow" comment on it making it to note that the updating of that scene node is slow when that happens. The next code is another conditional that triggers when the mesh is controlled using EJUOR_CONTROL mode.

Code: Select all

 
        if(JointMode == EJUOR_CONTROL)
        {
            // For meshes other than EJUOR_CONTROL, this is done by calling animateMesh()
            skinnedMesh->updateBoundingBox();
        }
 

Taking a peek to the "animateMesh()" method, there is no place where the jointChildNodes are ever updated. This results in that the child nodes aren't updated properly, and thus, they have to wait for the scene tree to progress until it reaches them, causing them a small delay because of an improper update of its transformations.

Adding that same code to the EJUOR_CONTROL conditional solves this, and, although it is marked as slow and temporary, it is also convenient, The function updateAbsolutePositionOfAllChildren() doesn't diference nodes, and thus the childs (bones or not) are updated correctly, and their rendering happens on the expected place, instead of the place that they had been the previous frame.

Code: Select all

 
        if(JointMode == EJUOR_CONTROL)
        {
            // For meshes other than EJUOR_CONTROL, this is done by calling animateMesh()
 
            //---slow---
            for (u32 n=0;n<JointChildSceneNodes.size();++n)
                if (JointChildSceneNodes[n]->getParent()==this)
                {
                    JointChildSceneNodes[n]->updateAbsolutePositionOfAllChildren(); //temp, should be an option
                }
 
 
            skinnedMesh->updateBoundingBox();
        }
 

While in the search of a better option, this modification solves this problem.

For the Skinned meshes, maybe their children nodes should be rendered BEFORE the skinned node because this would force the nodes to update, and maybe the scene traverse wouldn't suffer much, because this can be done locally in the skinned mesh node scope, and when the regular flow of the scene traverse wouldn't be affected too much.

[hybrid]

Yeah, sounds reasonable. I guess that Luke simply stopped right in the process of finishing all these modes. But I would prefer to defer this fix a little bit into a bugfix release for 1.8 or even for 1.7, and have some time to check these things before releasing it publicly.

[Ruxify]

I realize this is an old bug, but it's something that REALLY needs fixing. Until I found this thread, this bug caused me a LOT of grief and frustration, therefore I worry for others that may also encounter this bug.

[kevin_shanghai]

thanks for this bug report, i also encountered it.

[CuteAlien]

Yeah - I also wish we had someone working on the animation system. But since Luke stopped committing no one really has shown interest in taking it over. People generally prefer writing new animation systems from scratch instead of maintaining something someone else wrote :-(

[kevin_shanghai]

okay,
how should i upload the model files? i don't know how.

[CuteAlien]

Use some file-upload service on the web. They are all pretty horrible and full of misleading advertising - but unless you have an own server it's probably the only choice.