• Unity
  • Issue With Animated Slot Alpha + Non-PMA Vertex Colors?

  • Изменено
Related Discussions
...

Our artist is encountering an interesting issue that occurs whenever some SkeletonAnimation component's 'PMA Vertex Colors' checkbox is disabled. It seems to me that under these conditions, the Spine/Skeleton shader neglects to correctly apply slot alpha values (specifically the bug we're experiencing is that there's no change in rendered opacity even though our animations should be fading/disappearing various different attachments, & we've found our animations DO cause opacity changes so long as this toggle stays enabled).

I already have some familiarity with the ins and outs of PMA in Spine! I'm pretty sure for this project we indeed desire this checkbox to read 'false', since we're going for the Linear Color + non-PMA graphics setup (so to this end we're unchecking 'PMA Vertex Colors' on our SkeletonAnimations, exporting our Spines without PMA, and also checking the 'Straight Alpha Texture' box on all our Spine materials).

I played a little with the Skeleton shader code & was able to get what looked to me like correct color compositing. Here's the original version of the fragment shader, as it exists in Spine:

float4 frag (VertexOutput i) : SV_Target {
   float4 texColor = tex2D(_MainTex, i.uv);

   #if defined(_STRAIGHT_ALPHA_INPUT)
   texColor.rgb *= texColor.a;
   #endif

   return (texColor * i.vertexColor);
}

All I did was rearrange where we multiply in the vertexColor, like so:

float4 frag (VertexOutput i) : SV_Target {
   float4 texColor = tex2D(_MainTex, i.uv) * i.vertexColor;

   #if defined(_STRAIGHT_ALPHA_INPUT)
   texColor.rgb *= texColor.a;
   #endif

   return (texColor);
}

It's my understanding this shader supports both yes-PMA and no-PMA via employing the blendmode 'One OneMinusSrcAlpha' (the PMA-friendly one) & then in the case of no-PMA, doing the 'multiply SrcColor by SrcAlpha' step here within this frag function. I think what's happening is that the 'vertexColor' variable's alpha value (the thing we're currently animating lots!) never gets multiplied into the final rgb channels.

Part of me thinks the shader has to be fine actually, & it's us doing something incorrect elsewhere (since I and many other users have obvs been using this shader fine for years). So I wanted to ask you Spine folks for your opinion about it!

We are very sorry for the confusion! The current correct way for Gamma space as well as Linear space projects with any Spine shaders is to have PMA Vertex Colors enabled. You should only disable PMA Vertex Colors for non-Spine shaders. The Straight Alpha Texture parameter is only referring to texture input, not to vertex colors.

I have updated the documentation section, as it has shockingly not been correct, we are terribly sorry about this. Now it hopefully more clearly states:

  • PMA Vertex Colors. Multiply vertex color RGB with vertex color alpha. Enable this parameter if the shader used for rendering is a Spine shader (even with Straight Alpha Texture) or a thirdparty shader which uses PMA additive blend mode Blend One OneMinusSrcAlpha. Disable this parameter for normal shaders with regular blend mode Blend SrcAlpha OneMinusSrcAlpha. When disabled, it prevents single-batch rendering of additive slots and may increase the number of draw calls.

Unfortunately currently, selected attachment RGB colors are treated as linear colors on the input, although you have selected them as sRGB colors in the color picker. Unfortunately these changes cannot be added for 3.8 as it would break existing behaviour. We will do our best to implement these changes before 4.0 goes out of beta to provide a more consistent workflow for both Linear and Gamma space, hopefully with no more surprises about the resulting tinted color output.

The corresponding issue ticket can be found here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1301

Again, sorry for the confusion and thanks for reporting!