- Edited
Animation Disappearing and/or Blinking
Hello Again.
So I am having trouble with an animation that seems to blink or disappear randomly. I checked through all the keys and everything that needs a key has one at frame 0.
What I have is a tileable beanstalk sprite. It has a leaf animation that spirals around the stalk. For some reason the loop will randomly blink (at the second turn when the leaf starts to spin back behind the stalk) or disappear for a second when played back in Unity. In Spine it plays completely fine. Sometimes a loop plays correctly in Unity as well, but many times the leaf will blink or disappear. Below I have posted a video from Unity, and links to some pics of the stalk in Spine. I have triple checked all my frames, but the images include a snapshot of my timeline as well just in case. I have also attached our source code.
Spine Pics:
http://sta.sh/0cihg5s1c3v
http://sta.sh/01tslw35qj2j
http://sta.sh/01tlcayb3uqd
The third light colored, thin stalk from the bottom at time 00:46, plays the loop correctly on that part of the beanstalk.
Unity Video:
Unity Code 01:
Unity Code 02:
Are you allowed to share the json and atlas files for testing with us for testing? You can mail it to unity@esotericsoftware.com
I haven't checked if this solution has been merged with the official runtime yet.
Flickering and a solution for it
Might be worth trying the changes on your end if you're in a hurry.
Is it not just happening on the draw order keys?
6 days later
Hi Pharan. 
Yes I have permission for sending the json and atlas files for testing. Should I include a link to this thread in the email to support?
Our programmer tried the flickering solution from the other thread, but unfortunately it did not solve the problem.
Hi Binary Cats.
It is happening a bit randomly, so I am not sure if it is only happening on draw order keys. However, the blink does seem to occur a lot during the second turn of the leaf loop while it is switching between leaf frames. These frames are to make the leaf look like it is turning in 3d space. When the leaf completely disappears in the middle of the loop, the animation is already passed my draw order key.
Just wondering if anybody else might be able to help or may have another thought on what the problem may be on my animation. I sent the files for testing a few days ago via support, but was hoping that I might be able to find an answer by the end of the week.
I would like to help but it looks like a unity issue. I mean, I could put it in our engine and see if it still happens. But you should know I am not affiliated with esoteric software, so if you don't want to that's fine
@LuckyRabbit
Sorry it took a while. I wonder if you found out the problem too.
But I played back the animation at a 0.1 speed.
The problem was the animation. It looks like the scale was animated between negative to positive.
So it interpolated and showed the steps in between, including the point where the scale was 0. (hence the flickering.)
The thing to realize here is that while the dopesheet shows 30 fps, Spine playback doesn't actually have "frames".
It's very much like realtime animation for 3D games. Time progresses in arbitrary chunks depending on however long it takes the computer to process a frame. it can be any weird fraction of a second, so animation times can land on "frame 26.7" or "frame 15.226".
On top of that, games also don't run at 30fps. Because of most screen refresh rates, they can normally run at 60fps. And high-end engines and hardware can drive that up to 144fps.
Here's the problematic scale key interpolation on leaves_bone at 65/30 seconds.
You need to set your scale's interpolation graph to Stepped in that instance.
And in the future, if you're animating, make sure you check your animation by holding shift while you scrub the timeline. This allows you to scrub without snapping to the 30fps of the dopesheet.
And also check it by playing it back in Spine at a lower speed. There's a Playback panel/view you can open to control playback speed.
Hi Binary Cats. That's okay I think Pharan was able to find the problem. Thanks for your help though.
Hi Pharan.
Ah, I think I see now. I come from a film background, so I am not as knowledgeable on how fps is handled for games. In After Effects, these fractions of a second would not exist, and the fractional timing issue in the standards for television fps would be handled with a frame-blending mode such as progressive scan. when I placed frames one after the other in After Effects, I never needed to change the interpolation because they would be treated as stepped keys by being next to each other. I assumed that this would be the same in Spine, and didn't realize that a fractional frame was possible. Thanks so much for all the info. I'll remember to hold the shift key when checking my frames to avoid the snapping, and make sure to check out the playback panel for future testing. :3
I think we have been doing everything at a 30 fps rate (video standard), but this would be incorrect to do if I am reading your post correctly? We our currently developing this as a mobile app. Not sure if this would change anything or not in playback speed requirements?
Okay, so I just have one more question. Is it an animation problem again with the random disappearing issue of the leaf in the middle of the loop? You can find an example of this bug between 00:44 - 00:46 in the video from my first post. (It's the second thin stalk from the bottom.) During that period of the animation, the leaf is not frame switching or scaling. The only things that are animated are the rotation and translation. Is there possibly another interpolation problem happening here or is this something different?
There aren't any "playback speed requirements". But it is playback behavior.
The difference is really that instead of "frame 1, frame 2, frame 3", there are only keys.
This means the runtime goes: "you should be this value by 1 second, and this value by 3 seconds. If the time 1.75376 seconds right now, calculate the appropriate value between those two".
Mobile is subject to the same 30 or 60fps behavior. (iOS lets you choose).
But more importantly, you'll still get those fractions of a second.
You could change some lines of code in SkeletonAnimation.cs to change this behavior.
But it wouldn't be standard behavior (and likely not as smooth-looking).
Let me check that other thing.
Judging from the code, you're actually playing 2 animations at once.
"StalkSpiral_Anim" animates the stalk on track 0.
"LeafSpiral_Anim" animates the leaf on track 1.
The thing you shouldn't be doing here is applying a slot image/attachment key for the leaf in the StalkSpiral animation.
If LeafSpiral enables it, and StalkSpiral disables it, there's a chance that leaf image will disappear until the next key.
Just remove the keys for the leaf in the StalkSpiral animation.
You can also change the Setup Pose so the leaf is disabled on setup, and the LeafSpiral animation can enable it itself when it wants to.
On one hand, I think this is a bit of a temporary bug.
But it's also good practice to separate those two animation "domains" that way:
StalkSpiral shouldn't touch the leaf animation. The LeafSpiral shouldn't touch the stalk animation.
Hi Pharan.
I think I understand everything now. I've been applying my knowledge of film to my Spine projects, and it doesn't always translate over. Fractional time isn't really an issue in that work, so I never would have thought I had to check this in the playback tests for my animations. Yeah, I wouldn't want to change the standard behavior of the playback. I will just have to make sure to check for those fractional time spots in my Spine files from now on. XD
Yup, we have two animations playing at once. Originally there were no leaf keys inside of the StalkSpiral animation. It was inserted later in development to try and fix a different issue. I can't remember the exact bug, but I think it had something to do with the leaf popping on screen in its default pose before and after the LeafSpiral loop. The leaf was actually disabled in the setup pose, but it didn't seem to be enough to fix the problem without inserting the key. Or perhaps I do not have the leaf properly disabled? I turned off the visibility marker on all the leaf images inside the leaf slot. Is there something else I have to do in order to disable the leaf by default?
I will take the key out of the StalkSpiral and see if it plays with no bugs this time around. Hoping that everything is fixed with these adjustments. If the old bug returns, I'll make sure to re-post it in this thread. It would be a shame if this is also a bit of a temp bug. I worked pretty hard on this animation, and I would be totally bummed if I couldn't get it to playback correctly in Unity. Thanks again for all your help Pharan.
(1) Glad to know this info helped. I'll be including this in upcoming documentation I'll be writing soon. It really helps that you asked these questions. I know it's not really intuitive if you come from AfterEffects or Flash, or even from non-realtime 3D animation. But it is pretty standard in 3D game animation. There's a sort of sentiment about it in game animator circles where "the frames aren't yours". It's definitely a thing you can talk about with (skilled and experienced) 3D animators for games.
(2) To disable the images in Setup Pose, you just have to turn off the visibility dot of the image/attachments. NOT the slot. (this is important. The slot visiblity dot does not affect the exported skeleton in any way. It's purely in Spine editor. I actually wish this was communicated better in the interface because it does tend confuse people.)
Beyond that, no. There's nothing else to do.
That bug you ran into (where the leaf appears when you didn't want it to) was likely the result of a leaf image key in some other animation.
If you need to turn it off or turn it on, you should let the animation "in charge" of the leaf to make the necessary changes.
Weird stuff also happens with attachments when there's mixing/crossfading involved. For this animation, it looks like you should set the default mix in the SkeletonDataAsset to 0.
(3)
It's a "temporary bug" in a sense that keys in animations on a higher track are supposed to override keys on a lower track.
This is how rotation, position, scale and FFD work.
You can also make attachments work this way by commenting out one line from the code. But that fix causes attachment keys to be several times more expensive per frame, but in absolute terms, not by much if you don't have a lot of them.
The fact remains though that keeping the concerns/domains of each animation separate is the ideal way to set it up.
Hey Pharan,
(1) Yeah it definitely helps a lot. I'll be keeping my eye out for the new docs.
(2) Okay that's what I thought, so I did have the leaf disabled properly. I don't think there was another key for the leaf visibility in the other animations prior to the current one I have removed, but it is possible I could have missed something. Or would the color override animations I have for my beanstalk like the SummerToFall animation possibly cause that issue as well? Inside that animation I have color keys for both the stalk and leaf to change from one hue to another. Should these be separated as well to a StalkSummerToFall and a LeafSummerToFall animation? This animation is set to mix and override the default colors of the StalkSpiral and LeafSpiral animations.
I am guessing the SkeletonDataAsset is something that is set in coding or is that something that I can change within the project file?
(3) Oh got it. Just have to remember to keep my animations separated from now on, and hopefully I won't get any more bugs. XD I want to make sure I am setting up my files using the best approach, so that all my animations run without errors in the future.
You will definitely see me posting questions here again as I learn more and more about Spine.