Versions

• Minecraft: 1.17.1
• GeckoLib: 1.17:3.0.14

Disclaimer: I'm not actually sure if this is a bug or intended behavior pretty sure this is intended behavior, but I think a flag should be introduced to prevent it. See my comment at the end for more information.

Issue:
Take 2 animations: A and B. A causes a root node to transition up 16 units from 0.0 to 2.0 seconds:

"animation.model.a": {
			"animation_length": 2,
			"bones": {
				"bone": {
					"position": {
						"0.0": {
							"vector": [0, 0, 0]
						},
						"2.0": {
							"vector": [0, 16, 0]
						}
					}
				}
			}
		}

Animation B causes the root node to rotate (the details/timing of the rotation do not matter, the main point is that B starts at the default state of the root node, which is position [0, 0, 0]:

"animation.model.b": {
			"animation_length": 2,
			"bones": {
				"bone": {
					"rotation": {
						"0.0": {
							"vector": [0, 0, 0]
						},
						"1.0": {
							"vector": [180, 180, 0]
						},
						"2.0": {
							"vector": [0, 0, 0]
						}
					}
				}
			}
		}

Given a transition time on a controller of 20, and animations added at the same time (A -> B), I would expect the animation to play out like this: cube moves up to [0, 16, 0] over 2 seconds, transitions down to the default state of B ([0, 0, 0] position), and then plays the spin animation. What actually happens is A instantly snaps to [0, 0, 0] during the transition phase, because B does not manually specify* [0, 0, 0] as a position at frame 0.0. This causes unexpected snapping when transitioning between animations.

* Note that manually specifying the default position of [0, 0, 0] in B fixes the problem.

Video Demo for the following animated code:

 private <T extends IAnimatable> PlayState run(AnimationEvent<T> event) {
        event.getController().setAnimation(new AnimationBuilder()
                .addAnimation("animation.model.a", false) // moves up to [0, 24, 0]
                .addAnimation("animation.model.b", false)); // does not specify position, but [0, 0, 0] should be assumed

        return PlayState.CONTINUE;
}

Without Specifying [0, 0, 0] at 0.0 on B
When Specifying [0, 0, 0] at 0.0 on B

I'm wondering if this is intentional to prevent issues with layered animations - which is why I think even having an explicit flag for resetting back to default would be helpful. The issue becomes problematic when animators don't explicitly reset values in animations, and then things snap when you transition around... and finding areas you would have to "manually reset" when you have a bunch of cubes is a bit of a hassle. For the flag, maybe a boolean in AnimationBuilder#addAnimation to manually set unspecified values to 0?

The main reason I think this might not be intended is because A resets to the state of B anyways, so this problem is just a matter of whether it respects the transition time. Let me know what you think.

Thanks for reading - I would be happy to help look for a solution once I know this is not some sort of an intended feature :)

Please test on the latest 1.18.1 version, 1.17.1 is no longer being updated.

@Draylar Thank you for the detailed issue report. In your video it looks like it is transitioning back to the default state, just very quickly. Have you tried changing the AnimationManager#resetTickLength? If you set that to the same as your transition length it should work fine.

@Draylar Thank you for the detailed issue report. In your video it looks like it is transitioning back to the default state, just very quickly. Have you tried changing the AnimationManager#resetTickLength? If you set that to the same as your transition length it should work fine.

That was exactly it, specifying resetTickLength fixed the issue - thanks so much! I appreciate the help.