Skeletal animation system minor issues and quirks

I am currently trying to create a working Blender->jME skeletal animation toolchain, and ran into the following weirdnesses of the skelanim system so far:



  • BoneAnimation has a constructor that takes a Bone as input which is never used

  • BoneTransform.update contains the following code, which spams info logging with (fps*bone count) messages by default. Looks like debug info that is no longer needed to me, could that be removed?


        logger.info(bone.getName());
        if (bone.getName().equals("Bip01-node")) {
            logger.info("BIP 01");
        } else {


    [li]The (fps*bone count) string comparisions obviously don't help the framerate for complex skeletons, is that still necessary?
  • The end keyframe in a BoneAnimation, as set with  BoneAnimation.setEndFrame, is never actually shown - so you  basically have to set index + 1 as your end frame to make the animation show up as intended. Easily worked around, but of course the workaround will break if this is ever fixed in the future...



Can anybody confirm/add to/comment on the list?
BoneAnimation has a constructor that takes a Bone as input which is never used


Id also be interested in knowing what this bone is for, just incase Im doing my animations incorrectly Id like to know.

The end keyframe in a BoneAnimation, as set with  BoneAnimation.setEndFrame, is never actually shown - so you  basically have to set index + 1 as your end frame to make the animation show up as intended. Easily worked around, but of course the workaround will break if this is ever fixed in the future...


I can confirm this. Actually I also have a problem trying set my endframe to the last frame, it gives me this error:

SEVERE: Invalid endframe index (21). Intialized to only have: 21 keyframes.

So basically in order to solve this I have to add a frame with false information then set the index+1 in order to see my last frame. Unless I am initializing my animation incorrectly...though it works :)

BoneAnimation has a constructor that takes a Bone as input which is never used


Correct, legacy.

# BoneTransform.update contains the following code, which spams info logging with (fps*bone count) messages by default. Looks like debug info that is no longer needed to me, could that be removed?

Correct, needs to be removed.

#    The end keyframe in a BoneAnimation, as set with  BoneAnimation.setEndFrame, is never actually shown - so you  basically have to set index + 1 as your end frame to make the animation show up as intended. Easily worked around, but of course the workaround will break if this is ever fixed in the future...

Yeah, this is a bit of a design flaw, needs to be looked into for the best solution.

More interesting stuff:


protected void simpleInitGame() {
        Bone bone1 = new Bone("Bone01");
       
        int[] verts = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23}

        float[] weights = new float[] {
            1, 1, 0, 0,
            1, 1, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0,
            0, 0, 0, 0
        };

        SkinNode mySkin = new SkinNode("test skin");
        mySkin.setSkin(new Box("test", new Vector3f(0, 0, 0), 2f, .5f, .5f));
        for (int x = 0; x < verts.length; x++) {
            mySkin.addBoneInfluence(0, verts[x], bone1, weights[x]);
        }
       
        bone1.updateGeometricState(0, true);
        mySkin.normalizeWeights();
        mySkin.regenInfluenceOffsets();
       
        mySkin.setSkeleton(bone1);
       
        Node modelNode = new Node("model");
        modelNode.attachChild(mySkin);
        modelNode.attachChild(bone1);
        rootNode.attachChild(modelNode);
}



The above will make one side of the box "vanish" mysteriously. I'd guess from my other experiments that it's still there, just the vertices aren't where they should be.
Playing around with the influence array a bit will displace other vertices sometimes, setting all influences of one face to the same value however works just fine.
Note that nothing in the scene is moved in any way, the Bone doesn't even have an animation. I think the vertices should just remain in place in that case, or am I missing something?

About my previous post… could the problem be related to shared vertices?

Hmm. I tried the same for non-shared vertices, but to no avail. Something's not right with skinning, and I can't figure out what it is.

Mojo, is there any chance you can look into this?

If I manage to get on with this, I will try and add animation mixing and blending next, and would of course be happy to "donate" that.

A little progress with animation mixing, but also another problem I can't find the cause for. It cannot be illustrated in a screenshot, so I made a demo.

http://wwwhomes.uni-bielefeld.de/krabien/jmestuff/jME_Skel.zip contains windows and linux run scripts, dunno if the linux one will work for mac. You can set animation "idle" or "wave", and the skeleton idles or waves. But if you set "idle", and then select "wave" and press "mix" instead of "set", you'll see both animations fighting for control of the right arm bones.

I have no idea about the reason for that. The two animations are optimized, and the "wave" animation only animates the bones of the right arm. I created a custom AnimationController subclass with an overridden update() method:


    public void update(float time) {
        super.update(time);
        if(mixAnimation != null){
            mixAnimation.update(time, getRepeatType(), getSpeed());
        }
    }


As far as I can see, this should just update the active animation, and after that apply the mixAnimation the same way. But it doesn't. Try yourself, and you'll see what I mean by saying the animations are "fighting" for control.

The problems with skinning mentioned in my last posts are still there, and I am still just as clueless in that regard.

im assuming collada format will have the same problem since it also uses bone animation…



waiting for some developers to fix this~ :expressionless:

I don't usually bump, but I think this thread might have been overlooked or forgotten…

I'd file some bugreports, but first I'd like to make sure that I am not seriously misunderstanding how the animation classes are supposed to work.

It never hurts to file a bug report, even if it turns out to be nothing.

I found some more time to look into the skel-anim problems and have animation mixing working (at least in RT_WRAP, have yet to test it for other repeat types).

The "culprit" causing the "control fighting" described above was a check for an easy quit in BoneTransform.setCurrentFrame():


    public void setCurrentFrame(int frame) {
        if (oldFrame == frame) {
            return;
        }
        oldFrame = frame;


Which obviously didn't go well with animation mixing the way I implemented it. I removed it and did not notice a measurable fps drop with a reasonably complex humanoid skeleton.
Shall I test a bit more and then post my patch for BoneTransform enabling empty (null) transforms and animation mixing, or should I work on and post the full package once I finally manage to implement animation blending? (Might be a while though!)

I just realized I should link the bug I posted about this.



Bug filed Dec. 6: https://jme.dev.java.net/issues/show_bug.cgi?id=267