Bringing bugs to your attention.

JJuktec · 23. tra. 2013

To repay you for the help you've given me so far, here're two bugs I've discovered in the Spine C# Unity runtime along with the temporary workarounds I've put in place.

A few lines into ReadAnimation(...) in SkeletonJson.cs, the dictionary parameter is queried for the item under the key "bones". I've found that this is only valid as long as the animation includes at least one bone transformation. With the advent of our first full-frame-only animation, this was not the case and the JSON failed to load. I've gotten it to work anyway by simply adding a test for the absence of the "bones" key to skip over to the "slots" loading below.

When changing the animation of a skeleton component on-the-fly, I've found that bones are left with whatever attachment they had before the change occurred. This means that any bones that had an attachment sequence in the previous animation but that don't in the new one will be left with an incorrect attachment. Rather than dig into the code, I've come up with a crude workaround. At the point in Update() in SkeletonComponent.cs where any change to the animation name is detected and responded to (under the "Keep AnimationState in sync" comment), I've added a call to Initialize() before the call to SetAnimation(...) in the Animation State.

I hope this helps, and wasn't too obscure!

JJuktec · 23. tra. 2013

Nate · 23. tra. 2013

Thanks for the fix in SkeletonJson!

The second part is by design, if I understand correctly. If an animation changes an attachment, it stays changed. The same is true for bones, if an animation changes a bone and then another animation is applied that doesn't change that bone, the bone is unaffected. Imagine if you could set an attachment that was what weapon a character was holding. When you applied an animation, you wouldn't want the attachment to go back to the setup pose, you want the animation to leave the attachment alone. Another use case: you might use animations to change what weapon attachment is used.

You can workaround this by keying the attachments in your animation. It's always better to have fewer keys, as it is less processing at runtime, so a good way to do it is probably to restore the bind pose attachment at the end of an animation that changes the attachment. Another way to do it is to call skeleton.SetSlotsToBindPose() whenever you want the slots to be reset to the setup pose (aka bind pose). Do either of those work for you? Of course if editing the runtime as you've done works for your game, by all mean keep that and get your game done!