Keyframes from AnimationGroup with weight 0 not ignored

Bugs
,
1

Hello!

I have an glb file with 3 Animation Groups, they all target the same armature.
Only one of them has keyframes targeting the position, the others are just targeting rotations.

When I now set the weight of the only animation with the position animation to 0 the translation is still applied.

I have created an Playground with our glb file and a sample, I have also attached the glb file as a zip.

You can test this behaviour in the playground by changing the currentFrame of the “falling” animation in the inspector.

clippy_Broken.zip (8.9 KB)

1 Like
2

currentFrame in the inspector appears to be forced to move
The frame movement for basic animation operation appears to be operated by weight.
“falling” appears to work for both position and rotation.

1 Like
3

As @11128 said, changing the frame in the inspector uses AnimationGroup.goToFrame, which does the change even if weight is 0. weight is taken into account during regular animation replay only.

2 Likes
4

Sorry, I guess I have not really explaned the problem good enough. The changing of the currentFrame was just a test for myself to find out where the prolem is coming from.

The real problem is that the character should be in the origin (0,0,0) when the weight of the falling animation is set to zero. Because the armature is in the center and the other two animation have no keyframes set for position.

5

The y value of the model’s child Armature is about 6.169 (percentages are different in the tool).
In other words, the animation (keyframe) is set as y goes down from 6 to 0.
If you change it from 0 to -6 it will display correctly for the 0 value of world.

1 Like
6

How did you look this up?
In blender (where it was modeled and animated) this armature is in the origin and when exported without the falling animation it is also in babylon in the origin. So my best guess was that the armature is correct but the animation still applies some translation to it even when the weight is 0.
So maybe we do something wrong with the exporter?

7

The value itself was checked in the inspector hierarchy and appears to be related to the local
and world space for animation work before exporting from blender.(We had a similar experience to this with our 3D model team)
however even after working on this, if the same thing happens repeatedly,
it looks like a different problem.(example: It is true that the postion moves when animation is executed.
A problem where the final origin changes due to the local postion being changed just by working on the animation)
Can you add an animation that moves diagonally downwards to the model?

1 Like
8

Hello!

Thanks for the answers, I just now understood what you were saying in the second to last answer.
The falling animation works just as expected. it should fall from 6 to 0. So the falling animation works just fine.

Our problem is that after changing the weight of the falling animation to 0 (so it should not influence the armature in any way) the armature is still at an y value of 6. But that should be zero. Because the falling animation should be “disabled”. Or did I misunderstand what the weight does in that case?

9

I tested a few things.

  1. Containing the value 6->0 only as a keyframe.
  2. Animation of attaching and moving bones.

We stopped each animation and forced the initial value to be 0.
Even if no animations are triggered (except weights or animations on load)
The initial value is already mapped to 6 at frame 0.

Also, the weight is controlled for the value between each frame movement, but it does not seem to be in the form of removing the value itself at 0 frame.
This has already been mentioned : Keyframes from AnimationGroup with weight 0 not ignored - #3 by Evgeni_Popov

image
image1275×498 31.8 KB

So the conclusion is
Controlling by weight does not seem to work as is, and giving the opposite value of the already mapped initial value (but this causes a defect in local space) also seems to cause problems.

1 Like
10

So, do I understand you correctly that this is a bug in babylon?

For now we just add position keyframes to the other animations as well thats makes the problem go away. But that is work and can easily be forgotten.

Is there a workaround that we can do in code?

Thanks anyways!

1 Like
11

Since the weight was intended to be a mixed use of various animations, it seems that various opinions are needed to judge this as a bug.
Rather, I am more suspicious of the fact that the initial value changes even though the animation is not activated.
Is this a problem only with glb and gltf, or is it a rule for the overall model?

A simple workaround would be to create a keyframe in the idel state, but you are aware that it violates what you want.

Generalization seems to require more manual work than the amount of model modification because there are “unknowns” depending on the structure of the model.

1 Like
12

The initial position of the armature, without any animation, is 6.17. See this PG, where I removed all animations after they were loaded, to make sure they didn’t interfere:

If you look at the Armature node in the inspector, you will see that the Y position is 6.17. If it should be 0, then it’s a problem at export time.

You can also check it if you transform the glb to gltf and look for the Armature node in the file:

    {
      "children": [
        5,
        2
      ],
      "name": "Armature",
      "rotation": [
        -0.19885993003845215,
        0.58295583724975586,
        -0.492531418800354,
        0.6148415207862854
      ],
      "translation": [
        0,
        6.16932487487793,
        0.4978981614112854
      ]
    }

The Y value for “translation” is 6.169.

2 Likes