Davide

Oh my god... it works! Not your fault, to be honest, it originally said Step in my code but I must have missed copying it over to the new plugin. As you can see in my post above where I originally noted the slowdown, but then that begs the question, if that was there when I noted the slowdown... then... how did the slowdown initially happen? It's possible the screenshot I took was from my old plugin, not the new one, so I didn't actually have Step back. No idea.

Anyway, thank you so much for your patience on this. This has been mind-bending for me, haha. As I said before I'm not a programmer, and I apologize, if I was I probably would have been able to spot this error a lot sooner. I appreciate both of your guys' help, true heroes!

Thank you again, all's good now, no more animation mix problem and also improved disableInterpolation calculation!

Have a great weekend!!

Davide

Update: here's some additional information:

I just tested the project on another machine. (specs below)

The problem is reproducible on this other machine, so it's not just my PC.

Also, I just discovered that adjusting the Discrete FPS changes the animation playback speed not the "FPS" in the animation sense.

Expected behaviour: the animation would play normal speed but only show a different frame / pose every X FPS based on Discrete FPS (like non-interpolated hand-drawn animation).
What's happening: the animation is playing slower or being "time-stretched" based on the Discrete FPS. You can test this by setting the Discrete FPS to 60 or higher and the animation plays normally.

It is almost like the way the code is being interpreted is completely different between the new and old plugin version.

Hopefully we're getting closer to cracking this, I think this should give you a lot of new insight!

Davide

I'm going to try one more time with a fresh copy of the runtime downloaded. Here are my exact steps (using UE 5.4.4):

• redownloaded spine-runtimes-4.2.
• copy the folder spine-runtimes/spine-cpp/spine-cpp to the spine-runtimes/spine-ue/Plugins/SpinePlugin/Source/SpinePlugin/Public/ folder (as per documentation).
• copy spine-ue folder to my projects folder and rebuild project.
• realized that I was accidentally using UE 5.5.4, switched to 5.4.4, project won't open.
• opened an older version of the spine-ue sample project, copied the new plugin into that project and modified code. Slowdown is present.

• copy spine-ue folder to my projects folder and rebuild project again but keep it in 5.5.4 this time.
• Project runs normal without modification, okay let's add the modified code (same as above). Rebuild.
• Same issue, either it doesn't disable interpolation at all OR its slow motion.

When if (FramesToSimulate == 0) return; is present:
Character animates normal speed without disable interpolation checked. BUT, if you check disable interpolation the slowdown is present.

When if (FramesToSimulate == 0) return; is removed:
Character animates normal speed and disable interpolation checkbox does nothing at all.

And I tested it in both 5.5.4 and 5.4.4 so it's something to do with the way that code in particular, I guess on my machine in particular, is running (if this isn't happening for you guys). Is it possible if (FramesToSimulate == 0) return; causes some weird issue on certain hardware?

Either way something with this new plugin I cannot get it to work. I assume the code I pasted is correct and if (FramesToSimulate == 0) return; is in the correct spot?

But yeah I'm at a loss, I've tested this every which way, on two UE versions. It does this no matter what with the new plugin copy. You said before you pushed a fix for animation mixes to the runtime, did you perhaps change the way animation is calculated or something that might have affected the way it plays back on certain hardware? If you can disable interpolation on your end with the current plugin version but I can't then it has to be some sort of hardware thing... That's the only thing I can think of... UE5.5.4 I just downloaded too so I didn't make any engine settings changes either, it should be completely default.

If you have any other ideas please let me know!

Davide

Hello again! Sorry for the gap in response, had to step away from dev for a bit. Got a chance to test this.

So, good news and bad news after some further testing... The good news is as you said

if (Step <= 0.0f) return;

seems to fix the animation mixing problem. I didn't actually realize that fix worked because I was using the updated runtime you mentioned, which is causing this slowdown issue.

I discovered if(step) only works on my older version of the runtime. And on the newer version you mentioned, this code actually seems to CAUSE the slowdown (at least on my PC as you reported it's not reproducible). And I realized my disable interpolation code doesn't work at all on the new plugin version for some reason.

I did some more tests with the exact same project file (the spine-ue demo I grabbed from the updated runtime folder):

Old plugin / Modded w/ my original code: my original issue exists
Old plugin / Modded w/ (if (step) return): everything works
New plugin / UNmodded : no slowdown, but obviously no disabled interpolation
New plugin / Modded w/ my original code: disable interpolation doesn't work, BUT no slowdown
New plugin / Modded w/ (if (step) return): disable interpolation doesn't work, slowdown
New plugin / Modded w/ your code in latest reply_: disable interpolation doesn't work, slowdown

So both if(step) and that new code you sent both cause slowdown, but my old code doesn't do anything at all.

Here are my PC specs if you think that might matter:

Since the code you sent works on the old plugin I'll use that for now, I'm not anywhere near release so it's not a huge issue at the moment for testing. But, of course, this will be an issue in the future with updating. If you have any idea what may be going on with the new one please let me know! Hopefully I'm not overlooking something simple lol. I'm happy to send any files or projects over and I appreciate your looking into this.

Davide

Thank you so much for the update and the advice!

I downloaded the new runtime and copied my code over to SpineSkeletonAnimationComponent.cpp again, but now the animation speed itself slows down, not the "framerate". Even without the if (Step <= 0.0f) return; it's doing this. A bit hard to tell from the GIF but it's just playing all frames in slow-motion now, not skipping frames.

Did something change significantly in this update that changes the way the animations play so that the code I have won't work anymore?

If it's perhaps an oversight on my end please let me know!

Misaki Thank you, and that's totally fine. I have my strange "workaround" for now, and plenty of other things to work on. Cheers!

Misaki Yes that's correct! Apologies I meant to mention the level. This is indeed the issue I'm experiencing. Please let me know if you figure out the cause!

Misaki Sure thing I'll do that now! I put the code in your Spine example project file and it produces the same issue. Thank you for looking into it!

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

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.

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!

The only downside to this is that the physics doesn't continue through the "flip" (the ears would flop when the character turns which looks really good), so flipping the skeleton is the ideal solution but then allowing flip of individual bones (to fix the hoodies strings going the wrong way for example).

I poked through all available functions and found Get Bone World Transform, which made me think I could use scale on that to flip a single bone (the ones with Wind physics). Unfortunately, there's no matching "Set Bone World Transform". I assume this is for a good reason, but wondering if there's functionality to flip individual bones in here somewhere that I'm missing.

Misaki

Thanks for the tip! Flipping the actor worked, though, I discovered this causes problems when the actor has a capsule collision component on it (because it's flipping that too)! Instead, I flipped the Spine Skeleton Renderer and that did the trick! I think I assumed it would show the back of the skeleton's draw order (which is an issue I was having earlier) so I didn't try it .

Misaki

Thank you for your response and the suggestion! I tried out ResetPhysicsConstraints() with a debug key but all it did was return the physics bones to their original position for that frame then blew the wrong way again. Which made me realize... I think this is a problem with my rig setup.

I have wind and gravity physics in Spine making them point to the left on my run animation, and I guess this doesn't get mirrored when the skeleton is flipped in engine. I'm guessing wind and gravity are no-go's if you're re-using animations? Let me know if you have any suggestions outside of manually animating these parts of the rig.

Thanks again!

I set up my character to flip direction based on the documentation (with Set Scale X) but my character's physics bones still point the opposite direction.

Any idea how to fix this? UE 5.4.4 and Spine 4.2 if it matters!

Nate
Sorry to bump this old thread, but is there an Unreal version of this code somewhere?