MakeAnimationAdditive on skeleton does not add to reference frame


On line 59, I made 1 of the animation additive relative to idle frame. If you click on ‘Play Walk’, the walk animation is added to the T-pose and not the idle reference frame. WAI ?

edited: cos I found the weirdness

Adding @Drigax

1 Like

Line 59 made the animation additive, as in now instead of setting the nodes that the joints control to an absolute value driven by the animation, the animation is now a delta relative to the frame you chose. Now you need to play the idle and walk animations blended in order to get the walk animation to appear as expected.

1 Like

You mean like this ?

Just in case, I made left strafe additive as well and edited play walk and play blend obs funcs.
Play Walk - walk should be added to idle, but the position of the bones seem weird ?
Play Blend - left strafe is blended with walk correctly, I don’t understand the arms tho ?

I’m not sure what you’re trying to do with your additive animations, do you want to blend your idle/walk animations, or use additive animation to create different animation variants? i.e crouched walk, giving the character a hunched over/hurt walk, looking up, looking down, etc…

I ask because what you’re currently doing is a bit of a strange usecase, you’re trying to add two animation deltas taken relative to the idle pose.

I’d expect such a workflow for animation modifiers to start with creating additive animation tracks relative to the TPose, and apply it such that it plays additively to some walking animation, not so much by taking an existing walking animation, and calculating its delta to another pose and playing it over the top of that pose, you know?

Lets start with understanding what you want to do, then figure out if this is the right way of doing it.

I’m trying to understand how MakeAnimationAdditive works for skeletons with animation ranges so I can properly author my own. The doc shows an example but applied to animation groups and there is no concept of reference frame (

With animation ranges, there seems to be a visual bug. For instance when you keep clicking on Play blend in the above PG (left strafe blended with walk), there is a brief show of the bones all separated and coming together (Chrome). Is this a reference frame issue ? or a problem with how the animation was authored/exported ? If you disable blending in animationPropertiesOverride, it goes away.

For my use case, I have my character walking, intersect a collision mesh, trigger an equipping anim (additive, single shot). I’m getting all sorts of weird poses when the anims trigger, ie, same as the above visual bug. And it doesn’t seem to matter what reference frame I’m using. enableBlending must be true.

In this sample, we don’t explicitly declare a reference frame through the API, which then defaults to using frame 0 of the animation as the reference frame

We can inspect Xbot.glb to get a better idea of how the animations are created:
Looking at the “sad_pose” animation track, frame 0 is the reference frame we want to use:

While frame 1 is the static pose we want to additively blend:

Do we want to additively blend this? Its definitely possible using this workflow, however you’ll have to be careful in how your animations are authored so that you calculate the correct diff. Alternatively, you can override blend your walking and equipping animations as well, with the downside of there being some animation artifacts for the bones that are static throughout the animation.

I’m unsure which playground this is happening in, can you re-link, the one in this reply doesn’t contain the animations, and the other playgrounds you modified have some additive blending that may cause strange behavior.


Just in case, I added some codes to demonstrate mesh intersection triggering the anim. Zoom out a little and you should see the weird behavior everytime the ball intersects the plane.

Thanks, this definitely seems related to Skeleton.animationPropertiesOverride.enableBlending my guess is that when we start the additive animation every frame, we’re blending with the additive animation started in the previous frames as well, causing the bones to explode out due to some previously insignificant delta position becoming significant. I’ll take a closer look to confirm.

1 Like

Thank you for looking into this ! :slight_smile: