[BUG]Attachment change delay

MrHoot

While testing our character (who moves in 4 directions) on our game using the XNA runtime, it seems that the time it takes to change the body attachments (which were instant before) has some kind of delay now (meaning that when our character goes from "down" to "right" for example, his skeleton changes but all his limbs still display the images for the down animation for like half a second before switching to the correct one, despite me having put checks on frame 0 in the spine editor for all attachments). This has happened since spine updated it's runtimes for IK.

Nate

Not sure what this could be. Half a second is an eternity. spine-unity uses the same code. I'd say make sure you are up to date and try to dig into the problem more.

MrHoot

We're looking more into it yet, it's probably an error in our code (since other animated npcs and such don't have such problem. But since the player character uses special stuff like being able to change weapons on the fly and things, there's probably something fucky going on. It's just weird it didn't do it before)

We found the issue ! This is how my programmer describes the problem he analyzed

basically, when you first play an animation they set the last time to -1, but every time they play the animation they make sure that the time and last time values are in range so they do time %= duration;
Now if the animation length is exactly 1, that makes last time exactly 0 and there is a check for attachment timelines that says lasttime<frame must be true. But if there is only one attachment frame at the very beginning, then frame is 0 and lasstime is 0, so it doesn't do the attachment. But when the animation goes through one cycle, there is some random amount of time left before that. So then lasttime can be something like -0.123, and that isn't divisible by 1. So it stays negative ^^

The whole thing is linked to this line of code here: https://github.com/EsotericSoftware/spi ... 3bc0c7R447

basically write, if animation duration divides one and there is only one frame at 0 then this line returns without applying the attachment timeline.
the fix is to change it from a <= to a <

Nate

Hmm. It does seem now that lastTime %= duration; is used that using -1 for last time doesn't have the intended effect (modulus makes it 0). I will see about fixing that. However, this fix just means that the attachment will be set on the second animation update when it should be the first, but I don't see how it can cause the half second delay you reported. I also don't see how lastTime can be < 0.

Firzen

Programmer guy from the project here, I guess it's more sensible if I post here myself.

lastTime

can be <0 because the

TrackEntry

constructor initializes it to -1. As well as on the second round of a looping animation this condition becomes true.

else if (lastTime > time)
lastTime = -1;

This happens after the modulo operation though.

Now if the animation duration is anything that divides 1 on the first round the modulo operation makes this 0.
If on top of that there is only one frame in the attachment timeline at exactly 0 then the

if (frames[frameIndex] <= lastTime) return;

line always returns, since

frames[frameIndex]

is always 0 and lastTime will be 0 or bigger until the

lastTime>time

condition becomes true for the first time.

That's what causes the second long delay for switchting attachments, since it only happens when the animation has looped around once, because

lastTime

is set to a value smaller than

frames[frameIndex]

for the first time.

Nate

Welcome! 🙂 Thanks for the clarification.

Events are similar and it's surprisingly complicated covering all the edge cases. I wrote pretty extensive tests for events, but it tests the timeline directly.

I'm pretty sure the -1 is needed so both event and attachment timelines work correctly. The modulo of lastTime indeed wrecks it, especially since modulo of negative numbers can vary across languages. We could do this:

if (lastTime > 0) lastTime %= duration;

This way the first time through when lastTime = -1 it skips the modulo. Would be better to do it without the extra branch, but not a huge deal. Can you verify if that fixes your delay issue?

I wrote a little test for AttachmentTimeline that uses AnimationState. It isn't much, but at least showed the problem and that the proposed solution fixes it.
http://pastebin.com/SbLuWW3D

I'm reminded of this issue:
viewtopic.php?p=15177#p15177
Attachments used to be applied every frame, but the commit linked there changed it to happen like events. The benefit is way fewer attachment look ups in the skin, the drawback is that animations in higher AnimationState tracks attachment keys won't override attachment keys in lower tracks. Not sure there is a good solution, but thoughts are welcome!

Firzen

Setting

if (lastTime > 0) lastTime %= duration;

Was my first idea to fix the issue.

I think I prefer just replacing the

if (frames[frameIndex] <= lastTime) return;

with

if (frames[frameIndex] < lastTime) return;

since it removes the edge case and in the worst case scenario applies an attachment change one time more than it should.

Both solutions fix the issue.

Not sure if there is a good solution either. It's kind of a tradeoff between performance and comfort I guess.

Having it work like events seems just fine as long the tools provide the ability to work around potential troubles in an intuitive way.

Nate

Yeah, I was worried EventTimeline needed the lastTime = -1, but it doesn't appear to. Fixed in Git, thanks!