• Unity

  • Key Framing Visibility for Unity

    inglese
Related Discussions
...

This question is in regards to a problem where the keyed images' visibility works as expected inside of the Spine previewer and also the Unity previewer. Certain animated images appear fine until we switch from one animation clip to another using the same json file as interpreted by unity 2018.4.17. Then images disappear as soon as the new animation is played. Images that don't have visibility keys applied to them don't appear to be affected by this issue. Spine version is 3.8.83.

I'm not a coder but I've been setting all the keys in spine and then exporting them to .json for use with the unity-spine plugin.

So with this in mind, the problem must be related to how things are being keyframed and how the runtime code is interpreting them. Let me describe how I am keyframing the visibility of the images.

1) Turn on Auto Key

2) I scrub to the desired frame.

3) I click the visibility dot next to the mesh and a key is laid down in the timeline in either a light or dark grey keyframe symbol. (I'm not keying (clicking the visibility dot for the slot) the slot per say but a red key symbol appears next to it). Is this wrong for use with unity? It appears fine in the unity previewer. The images turn on and off as expected in the spine preview.

Thanks for any hints on this problem.

  • Harald

  • Messaggio #3
  • Questo post è in inglese

We are sorry to hear that you are facing problems. Currently we don't know of any playback problem yet in this regard. I assume you are using a recent spine-unity runtime package. If yes, could you please send us your exported assets (the three files placed in your Unity project Asset dir) as a zip package to contact@esotericsoftware.com, then we can have a look at what's going wrong.

One side note: when there are no keys of a certain timeline (visibility, rotation, etc.) set in an animation, the previous animation's state is left unchanged, it is not the setup pose which is used then.

I sent out an email to you this past Friday, thank you for your attention.

Sorry for the late reply! Thanks very much for sending the reproduction package, we received your email. We will get back to you as soon as we figured out what's going wrong and have a solution to offer.

Unfortunately we could not reproduce the problem you are describing above.

Which version of the spine-unity runtime are you using?
FYI, Since you said you are using Spine 3.8.83: the files were exported from 3.8.79 (that's not the cause of any problems however).

If you are using the latest spine-unity runtime package, could you please send us a minimal Unity project where this problem still occurs?

I'll get you in touch with our programmer. Thanks!

Our programmer emailed you a Yeti Unity package. If you turn on the IdleNakedYeti animation after running a previous animation the mouth disappears. This only appears to happen during run time. It doesn't happen in the Unity previewer or Inside of spine so we are a bit perplexed about this

We are using spine-unity-3.8-2020-01-27.unity package with Spine Export 3.8.83 PRO

  • Harald

  • Messaggio #7
  • Questo post è in inglese
JPWestmas ha scritto

If you turn on the IdleNakedYeti animation after running a previous animation the mouth disappears.

That was the missing information that we needed to reproduce the problem, thanks for the update.

Also thanks for sending the reproduction package, we received everything and can now reproduce the problem.
We will get back to you as soon as we figured out what's going wrong.

The problem turned out to be as I described in my first reply:

Harald ha scritto

One side note: when there are no keys of a certain timeline (visibility, rotation, etc.) set in an animation, the previous animation's state is left unchanged, it is not the setup pose which is used then.

Please always check such suspected causes first, we could have spent the time in better ways.
In your case there is no key at the first frame, therefore the attachment's visibility stays unchanged (disabled):

Regarding your setup: It is not a good idea to create one slot per mouth shape. You should instead have one slot mouth and then e.g. 5 different shape attachments that you can then swap out. This is also demonstrated in the Spineboy example project. One of the benefits is that it's much less error prone if you have to key a single slot than to key 5 slots.

I see mouthOhShape2 isn't in the scene's hierarchy so of course I didn't key it. But it is in the images folder. I'll try it again after removing that image. Thanks for your help.

I also see that attach:mouthOhShapeYeti has a light grey key in the spine project so I know that isn't the problem inside of the spine scene at least.

So in the Penguine scene (I sent you the exported files) you can see that I keyframed all the "beak" images on frame zero with the frown shape being turned on in the light grey key. So this is the same problem with Unity, where the beak disappears when going into an idle animation. I was thinking the same thing as you where I thought I missed a key but it appears to be there inside of spine. I'm just as annoyed by this as you are. 🙂

To simplify things I will do what you suggested and move all the beak images into a single slot and I'll report back.

JPWestmas ha scritto

I see mouthOhShape2 isn't in the scene's hierarchy so of course I didn't key it.

In the Yeti project imported back into Spine from the Json asset (via Spine - Import Data ..) I see the following:

So I see mouthOhShape2 used in exactly the problematic ExitYeti animation.

Similarly, I see missing keyframes in the imported Penguine project:

Do you also see the same missing keyframes in your original Spine project? If not, we would need to track down why they get lost upon export.

We got it! It was something to do with the "Tracks" inside the script we were using to invoke the animations. We were using Track = 1 which caused the animations to blend together in a way that makes no sense at all. Using Track = 0 fixes that track problem completely . . .so far.

So I doubt the keys were causing this particular issue but its good practice to key everything on frame 0 anyway.

I noticed that you were using Track 1, but thought that this was intended to keep subtile idle movement going on some parts of the body. Sorry for not mentioning that this was suspicious. Glad you figured it out!