• Bugs

  • Starling 2.0 + Spine 3.4 bugs

Dear Spine Creators and Spine Community,

Several weeks ago my team started using Spine to create animations for our mobile game project.

After creating several animations and playing them in Starling runtime we found some issues:

  1. Sun animation don't have top layer.
    Animator:

    Runtime:
  2. Clouds - Snow animation plays incorrect in runtime. Also transparent snowflakes become black.
    Animator:

    Runtime:
  3. Volcano. It has four animations. When "smoke_split" plays and I run other animation e.g. "idle" - lava pieces remain on the screen.
  4. Pond. It has three animations. Storm plays perfect. Idle halfway. Breeze don't play at all.

Spine animations sources:
https://dl.dropboxusercontent.com/u/3956959/SpineAnimator.zip

Starling player project with spine export:
https://dl.dropboxusercontent.com/u/3956959/SpineAnimationPlayer.zip

Hope to see solutions soon.
Thanks.

Related Discussions
...

#3 sounds like it works correctly. See here: Using Spine Runtimes

The others sound like bugs, badlogic will take a look ASAP.

Nate,

Thanks for quick reply.

Seems setToSetupPose works fine for #3

Hi,

hm, I can't reproduce the issue with the Clouds - rain animation on my end. Could you also send me the breeze animation? Could you also make a video of how Clouds - rain behaves on your end? I've reopened the issue on GitHub.

Thanks,
Mario

Mario,

Spine animations sources:
https://dl.dropboxusercontent.com/u/3956959/SpineAnimator.zip

Starling player project with spine export:
https://dl.dropboxusercontent.com/u/3956959/SpineAnimationPlayer.zip

Breeze animation export (Pond skeleton): SpineAnimationPlayer.zip/SpineAnimationPlayer/bin-debug/spine_assets/pond/
Breeze animation project (Pond): SpineAnimator.zip/SpineAnimator/pond/

Clouds - rain video:
https://dl.dropboxusercontent.com/u/3956959/clouds_rain.mov

Timing:

Please, tell me if I missed something.

Perfect, thanks! I'm looking into it now.

I was able to reproduce this. I have no idea why it is happening. The rain drops have keyed color + alpha. All the calculated values are correct. I'll keep digging, but this might be an issue in Starling (though I can not see how).

I've plotted the color + alpha values for all droplets over time: https://gist.github.com/badlogic/646554de85174e1eb792333aafeb3b39 The values are definitely correct. I'm at a loss why some droplets occasionally flicker.

Could you maybe ask on the Starling forum if people have seen similar effects?

Dug a bit into Starling's source code. This is the code responsible for setting the color+alpha on a vertex. Nothing looks suspicious: https://github.com/Gamua/Starling-Framework/blob/master/starling/src/starling/rendering/VertexData.as#L823

If I keep the alpha of the droplets at 1 (fully solid), no problem arises. I have a feeling that the premultiplied alpha calculations in Startling's VertexData may have a problem, but I don't see how, the code looks like it should.

Thanks! I'll chim in on the Starling forum as well. I'm still puzzled about why this is happening. We'll figure it out, could just take a bit.

Hi Mario,

I just created simple project and set only two waves in breeze animation.
And I see the bug. Attachments in slots have the same name - "v".
I set different name like "vv" and bug is gone.

Json export example:

"slots": [
   { "name": "v7", "bone": "wave2", "attachment": "v" },
   { "name": "v8", "bone": "wave3", "attachment": "vv" }
]

Bug:

"slots": [
   { "name": "v7", "bone": "wave2", "attachment": "v" },
   { "name": "v8", "bone": "wave3", "attachment": "v" }
]

Could you check this?

As far as I understand Spine Editor allow to add image attachment in slot with the same name. So is it bug or no?

Two exports: https://dl.dropboxusercontent.com/u/3956959/breeze-export.zip

Oh, that's a great find! I'll look into this today using your sample project. Thanks for helping digging into this!

OK, this looks more and more like a Starling issue. If both attachments in the slot have the same name, they also share the same image in the atlas. At rendering time, Starling seems to do something to the shared image if one of the attachment's has an alpha value of 0. I'm digging into the Starling sources now to try to figure out what's wrong in there. My guess is their automatic pre-multiplied alpha stuff goes a bit bonkers.

I found and fixed the issue. A region attachment on a slot has a reference to a Starling Image. A Starling Image is essentially a container for a texture and a mesh. When two slots share the same region attachment, they fight over setting the color on the Image's mesh, which leads to the effect you saw. Fixed by giving each region attachment it's own Image instance.

Please get the latest swc files from the runtime repository and report back if this fixes all your issues!

Thanks a ton for helping with debugging this issue, I was about to cry 🙂

I put the latest library and all animations work perfect.

Thanks for great support!

Awesome! Thanks for all the help from your end, couldn't have done it without you.