FCSW_Ben

Hi everyone, I either don't understand how animation tracks work or we've discovered a bug in the C++ runtime. When we add a second animation track, any keyed bones should supersede the transforms of the track below it. This works in the editor, but doesn't work in the game itself. Has anyone else encountered this and can tell me what we're doing wrong?

Video of the Spine editor vs the C++ runtime:
https://www.dropbox.com/s/gtyawo9s2us7j17/trackentry_alpha_bug.mp4?dl=0
We're making complex games almost entirely in Spine! Consider signing up for the closed alpha of our latest Project: https://www.exceptionullgames.com/knockout.html
Аватара пользователя
FCSW_Ben
  • Сообщения: 38

badlogic

Hard to tell what might be going on just looking at the video. Could you maybe send me a short piece of repro code that I can add to our cocos2d-x example project, including your assets, so I can debug it locally?
Аватара пользователя
badlogic

Mario
  • Сообщения: 2065

Nate

Do you see the problem using the Skeleton Viewer?
Skeleton Viewer
If so, likely the spine-cpp runtime is working as designed and if you provide your skeleton JSON then badlogic can reproduce the problem and tell you why it behaves as it does. If it only occurs with spine-cpp runtimes, then badlogic will need code that reproduces the problem.
Аватара пользователя
Nate

Nate
  • Сообщения: 9241

FCSW_Ben

Yes, the behavior between the cpp runtime and the spine viewer are the same. This leaves only the Spine Editor working in the way your documentation describes. Here are some files you can play with:

https://www.dropbox.com/s/le0jbx35wniaaz5/blocking_layer_bug.zip?dl=1

To reproduce:
Add idle to layer 0
Add a blocking animation to layer 1, 100% alpha

Expected behavior:
Track 1 keys should override affected bones in track 0. Applying Animations - Spine Runtimes Guide: Tracks

Behavior observed:
Track 1 seems to be additively applied to track 0.
We're making complex games almost entirely in Spine! Consider signing up for the closed alpha of our latest Project: https://www.exceptionullgames.com/knockout.html
Аватара пользователя
FCSW_Ben
  • Сообщения: 38

Nate

Thanks, that helped. It was confusing at first, as I see the behavior you described. I simplified the project and then noticed that layer_idle_l_add_block_bl has only 1 timeline (it should have 4 in the simplified project). The export has animation clean up enabled, which removes keys that appear to be unnecessary. If you select your animations and run Clean Up in Spine then you'll see the same behavior in Preview.

Clean Up sees the keys that set the boxing glove color to transparent, sees that the color is already transparent in the setup pose, and so removes the keys that would normally be unnecessary. When playing animations on multiple tracks, special care needs to be taken so keys in the higher track animations are not removed with Clean Up.

Sorry you ran into that gotcha. I suggest not using Clean Up for now. We need to make some improvements so you can design animations for tracks and still use Clean Up. Eg, maybe you can lock a key so it won't be removed automatically, or maybe you can mark an animation for use on higher tracks so Clean Up will adjust the rules it uses to remove keys. I've created an issue to track these improvements:
https://github.com/EsotericSoftware/spine-editor/issues/461

BTW, you seem to be hiding attachments using transparency a lot. Sometimes you need to do this to fade images in/out, but you should know that drawing an image with zero alpha still goes through the GPU and counts against your fill rate (the maximum number of pixels you can draw each frame). It's better to hide attachments when they no longer need to be visible. You can still fade them out, you'd just also set a key on the slot so the attachment is not visible at all once the alpha is zero. Alternatively, if you stick with hiding via transparency, you should make sure that the renderer you are using at runtime checks the slot's color and skips rendering the attachment for the slot when the alpha is zero.

While reviewing your project I found two bugs with ghosting that are unrelated to your problem above, so we have a few other things to fix too! :nerd:
Аватара пользователя
Nate

Nate
  • Сообщения: 9241

FCSW_Ben

That makes a ton of sense now that you mention it. Thank you!!! I'll hold off on the cleanup option for now.

I had been using transparency to hide slots as I had no idea attachments could be keyed like that. Certainly, there is no key icon next to them and visibility toggle on the slot itself doesn't produce a key. (Manually keying seems to instead key the attachment within and leads to export warnings.) Thank you for pointing this out as well! I don't have any immediate UI suggestions that could make that more intuitive or consistent, but I can make a new thread on that matter if I think of some.
We're making complex games almost entirely in Spine! Consider signing up for the closed alpha of our latest Project: https://www.exceptionullgames.com/knockout.html
Аватара пользователя
FCSW_Ben
  • Сообщения: 38

Nate

Ah, yeah that has been one of a few slightly unintuitive parts of the Spine interface for a long time. The key icon for attachment visibility is next to the slot, but you change the attachment visibility by clicking the dot next to each attachment.

We have an issue to address the usability of keying attachment visibility:
https://github.com/EsotericSoftware/spine-editor/issues/149
You are welcome to comment on the issue there, though you'll need to sign up for a free GitHub account if you don't have one. With a GitHub account you can subscribe to issues so you receive emails when there is activity, which is nice. Otherwise we can discuss any ideas you have for improvements here on the forum (in this thread or another) and then add them to the issue afterward. The key you might see next to an attachment is to key the attachment's deform (meshes, paths, bounding boxes, and clipping attachments only).

If you haven't found it yet, you can check out our roadmap, which gives a nice high level view of the GitHub issues:
Spine Roadmap
Аватара пользователя
Nate

Nate
  • Сообщения: 9241

FCSW_Ben

Good news, the cpp renderer treats slot opacity of 0 as skippable. :)
Region visibility control is still better, though I'm struggling to incorporate it into my workflow.
We're making complex games almost entirely in Spine! Consider signing up for the closed alpha of our latest Project: https://www.exceptionullgames.com/knockout.html
Аватара пользователя
FCSW_Ben
  • Сообщения: 38


Вернуться в Runtimes