• Runtimes

  • Image switch keyframes and blending

I've got a question about image keyframes that appears to have changed over the last couple of months.

1) I've got an "Low Health Idle" animation which swaps eye images at the start and end to be "half closed" images via skin placeholder nodes of a slot
2) I've got an "Attack" animation which swaps eye images at the start and end to be "fully open" images via skin placeholder nodes of a slot

As we blend from "Attack" to "Low Health Idle" the eye images are messed up in the runtime. For the current set of data this actually makes sense to me since the start and end of each animation has image key frames that are setting conflicting data, but like all other keyframes for all the bones it feels "right" to set keyframes at the start and end, even for image data ... but maybe that is bad thinking?

So the only solution I can think of that works today is

1) "Low Health Idle" sets eyes half closed at the start, but contains no repeat eye image keyframe at the end while "Attack" sets eyes fully open at the start and also has no repeat eye image keyframes at the end.

This works, but it feel inelegant to me so I'm wondering if you guys at Esoteric have a better idea of how to not have to think about which animation interactions can have this conflicting state issue?

One idea that I'm thinking about is that if two animations are being blended, only image swaps of the animation coming in are recognized and slot or skin placeholder visibility of the outgoing animation are ignored. This feel like it could be a more "systemic" fix for such contradictions in the animation data, but you guys might have thought about what that might not be a good idea or have another way that we as content creators should approach this problem.

Thanks.

Related Discussions
...

Ah, I was talking about this use case with Nate some months ago before the changes were made.
You're right, the behavior of image switch keyframes (AttachmentTimelines in the runtimes) did change.

AttachmentsTimelines used to be applied every frame, which was terribly wasteful, slow and scaled badly. Now it uses an event-type only-switch-when-there's-a-key behavior.

The old behavior (since it applied every frame) ensured that Track 1 animation Attachment timelines always reliably overrode what Track 0 animation AttachmentTimelines looked like.
The sideeffect of the new change was that the overriding behavior only applied where there are keys. It would obey attachment changes whenever there's a key on any of the Tracks.

I think you're the first one in the forums to describe relying on the behavior but I figured it was a useful thing for some people. I definitely figured I would use it at some point too.

Right now, I can't think of a sane solution outside of actually making some changes to the runtime, instead of editing your Spine project.
But I guess if you think your animations are limited, predictable and simple enough that you can fix it with just a few additional keys, you should go for that for now.

I also can't remember if Nate described a useful solution for this use that I just forgot.

I definitely agree that a Track 1 animation AttachmentTimeline should prevent the same timeline in Track 0 to be ignored. Or it should be an option, at least, since this is how SRT (and color) timelines work.

I wonder about the implementation and if the "systemic fix" could be done without having to change anything in Spine editor.