Thanks for the reply!

I tried the PMA checkbox, but it isn't set. (I use a separator, could that cause any issues?) I also use the same shader for both Spine and all other sprites in my game, however when set to the same colour, the Spine version is noticeably paler. (They are all grey scale sprites, that are then coloured in Unity.) So it is perhaps not the exact same issue as that other thread, as at grey scale the sprite actually looks correct, it's only when adding colour that it looks paler.

I don't suppose you have any other ideas of what it could be? Adding the Spine atlas as a sprite in the scene with the same shader yields the correct colouring, so I am fairly confident that something is happening inside Spine? I set the colour using:

_baseSlot.SetColor(color); // (_baseSlot is a Slot)

Is there a different way to set it perhaps?

Edit: Though I should note that by default, the atlas doesn't have a "Sprite Mode" set. Though changing this doesn't make a difference.

Hi again,

I tried removing the separator, unfortunately the paleness is still present. I can't figure out why if the sprite sheet itself looks fine, the Spine Animator is so pale?

The project space is definitely linear. I'm fairly sure that's not the issue, as like I said: the sprites colour correctly if I use the Spine atlas with the same shader. If it were a colour space issue, wouldn't the atlas and Spine have the same results?

Here's an image of the issue: https://www.dropbox.com/s/k6w82rzk4vg8hta/spine-colour-issue.png
And for completeness, this is what the sprite looks like uncoloured: https://www.dropbox.com/s/le2wltfy4kggi6r/spine-colour-issue-2.png

The top circle is the Spine Skeleton Animation. The bottom is the Spine atlas (set to multiple sprites). Both use the same shader and are coloured using the exact same colour: Color32(66, 104, 214, 255).

I'm unsure if the issue exists in the gamma colour space, as our project is massive and our textures take about an hour and a half to reimport, so I haven't had the time yet to attempt it.

When I say "same shader" I mean a material using our own custom shader. When applied to the atlas colouring works as expected, when applied to the Skeleton Animation it doesn't.

OK, so it might have something to do with the colour being applied to the mesh, as opposed to the sprites?

I finally managed to get someone to take a look at this. It is a result of the different colour spaces, however I'm not convinced that it's not a problem with Spine's Unity runtimes. (Not Spine itself, obviously.)

As I understand it, Unity's SpriteRenderer takes care of any colour space conversion under the hood. So whether you're using gamma or linear, it will represent a Sprite correctly when the colour is set. An important aspect of this is that you can use any shader you'd like with a Unity sprite, and the colour will be represented properly.

As Spine is intended to work in tandem with Unity sprites (I assume?), not doing this is not only disparate from the flow of Unity, but (if solved at the shader level) would require the use of different (or specialised) shaders to account for it. While it's not technically a "bug", I do believe it's an issue.

It can be solved at a code level, using a conversion:

static Color GammaToLinear(Color c){
    return new Color(
        Mathf.Pow(c.r, 2.2f),
        Mathf.Pow(c.g, 2.2f),
        Mathf.Pow(c.b, 2.2f),
        c.a
    );
}

However this comes with its own set of issues. For example, needing to ensure a backwards conversion is done when using GetColor(), as well as maintaining two Color values (one for Sprites, one for Spine). That seems cumbersome, and I don't believe it fits in with the flow of Unity?

But I'm open to other opinions.

I made some extension methods to manage the conversion, it works well and alleviates some of the problems I mentioned at the end:

#region Spine
      public static void SetColor(this Slot slot, Color color, bool colorSpaceConvert) {
         slot.SetColor(colorSpaceConvert && QualitySettings.activeColorSpace == ColorSpace.Linear ? GammaToLinear(color) : color);
      }

  static Color GammaToLinear(Color color){
     return new Color(
        Mathf.Pow(color.r, 2.2f),
        Mathf.Pow(color.g, 2.2f),
        Mathf.Pow(color.b, 2.2f),
        color.a
     );
  }

  public static Color GetColor(this Slot slot, bool colorSpaceConvert) {
     return colorSpaceConvert && QualitySettings.activeColorSpace == ColorSpace.Linear ? LinearToGamma(slot.GetColor()) : slot.GetColor();
  }

  static Color LinearToGamma(Color color){
     return new Color(
        Mathf.Pow(color.r, 0.4545f),
        Mathf.Pow(color.g, 0.4545f),
        Mathf.Pow(color.b, 0.4545f),
        color.a
     );
  }
#endregion

However more generally speaking, I believe Spine should attempt to integrate with Unity as smoothly as it can, which would include replicating Sprite behaviour where possible?

Hi Nate,

Thanks for the reply! Forgive me for not understanding, are you explaining why using the default sprite is akin to a normal Unity sprite?

In my attempts, toggling the SRGB setting of the sprites didn't seem to have any effect on the colour difference?