Animation gets stuck between poses after BeginPlay only

Versy · 4日前

This is an odd one.

I have Idle play automatically on BeginPlay, but then any animation that I transition to (either Walk or Run in my case) gets "stuck" when it's supposed to go back to Idle. The character basically freezes mid-walk and then does the Idle animation but with the legs mid-stride, if that makes sense.

Once you "break out" of this though by going back and forth between a couple more animations it goes back to normal and can't be reproduced during the rest of the play session.

The only thing that's ""fixed"" it is by swapping animations at the start of BeginPlay with some Delays before going into my state machine to do the actual animation transition logic. I don't know why that works but it does.

Does anyone have an idea for a non-hacky way to actually fix this? I don't think it's the actual transition logic because I've tried it three different ways and they all do this, so I must be missing something. It seems to have something to do with the mixtimes between animations, but ONLY ONCE after the game starts and never again. Any help appreciated!

Misaki · 4日前

Versy When a skeleton's animation gets stuck, it is often due to the animation being repeatedly re-set on the same track.
From the screenshot you provided, it is unclear exactly how this occurs, but you may be able to work around it by inserting a Branch node.

For example, as shown below, the Spine -> Animation -> Get Current node retrieves the TrackEntry for a specific track, and the Spine -> Track Entry -> Get Animation Name node obtains the animation name. If the retrieved animation name does not match the next animation to be set, the Set Animation node will be executed:

Could you try ensuring that the same animation is not set consecutively to see if that clears the stack?

Versy · 4日前

Misaki

SetAnimation shouldn't be getting called every tick, no. I currently have SetAnimation only being used On State Begin in my state machine, and then bools controlling whether it can transition to the next state, which are also only in On State Begin.

I don't think it's setting the same animation every frame (I did make that mistake in the beginning) since that results in the animation being stuck on frame 1. With this problem, as you can see from my video below, it will start to play Walk when the character moves, but then if Walk is let go, it plays Idle "on top" of the frame that Walk stopped on.

Setting all animation mixtimes to 0 stops the problem. But, of course, that's not a solution.

Again, you can see eventually after a few animation transitions the problem stops. Which is why my "hack" is to just do that a few times at BeginPlay, and then all animations work fine. It's not a "real" solution though, I just am not sure what's going on.

Misaki · 4日前

Versy Thanks for the additional clarification. It certainly looks like this is not a problem with the animation being applied repeatedly, but rather a problem with poses that should be reset not being reset. Could you please email us a minimal UE project that can reproduce this problem?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

Versy · 4日前

Misaki Alright, slightly embarrassing, but I've isolated the problem to a modification to SpineSkeletonAnimationComponent.cpp that I had someone do for me in order to get a specific framerate on my animations. I thought to check this before but completely forgot.

I'm not the coder, but I believe what this is doing is only updating the skeleton on a lower interval instead of deltaTime, to mimic a low framerate. But that is likely causing updates to be "caught" in the middle.

I know this is probably out of your support range because it's a modified feature, and I assume a faux "framerate" option like this isn't planned to be added to the runtime, so if you have any idea if there's a way to get this to play nice with the skeleton update please let me know!

Misaki · 4日前

Versy I'm glad you were able to narrow down the problem to some extent! However, the code you showed us does not seem to be wrong, would you still be willing to email us a minimal UE project that can reproduce the problem? Then we can look into it in more detail.