Thanks for the question. While checking the shader code for Linear vs Gamma color correctness, I noticed some issues that shall be fixed in 4.0 anyway. So I started an overhaul of all shaders, after that they shall be compatible with Linear color space in both PMA and Straight alpha vertex colors. I hope it will be done in the next few days.

Issue ticket for reference:
https://github.com/EsotericSoftware/spine-runtimes/issues/1301
I will let you know once it's done.

foriero escribió

Great. Does it mean that in Linear Space the PMA textures with additive attachments won't produce extra draw calls?

You should still use Straight Alpha Textures when in Linear color space, you should just enable Advanced - PMA Vertex Colors at the SkeletonAnimation component. PMA Vertex Colors is what allows additive Slots to work in a single draw call (the Additive slot info is passed to the shader via the PMA vertex color). Actually the Premultiply alpha atlas textures mainly improve mipmap generation in Gamma space (but ruin it in Linear space), and would allow for texture-based additive blending if you edit the texture after it has been exported from Spine (paint the alpha channel black where you want it to be additive, which is rarely done by anyone).

I'm afraid PMA atlas textures in Linear space are not something that we can fix easily.
I'm sorry that these things can be very confusing. Once the shader updates are done, I will update the spine-unity docs pages so that they hopefully explain things in a clearer way.

foriero escribió

The issue with the mushroom is that we have six additive attachments there each producing an extra drawcall.

For 6 additive attachments you have successfully chosen the worst possible draw order .
If you could change the draw order in a way that it's not interleaved as much, you could reduce draw calls of course (e.g. Additive back attachments, Normal attachments, Additive front attachments would take 3 draw calls instead of 11), don't know if that's feasible with your art though.

foriero escribió

If six mushrooms producing sixty drawcalls then linear space is out of question.

Gamma space will most likely provide for an easier setup with fewer pitfalls. It depends on whether you really want (or need) linear blending and linear lighting gradients, which will also be a question of art style and the result that you want to achieve. Linear space will provide for better post processing effects though, so it might be worth the hassle. Anyway, we will do our best to improve the shaders as much as possible so that you can use Linear space with ease .

foriero escribió

One observation. Additive attachments do not work with URP 2D LIGHTS.

Then I would guess that you're using an old URP package, this should be fixed on 2021-03-04, see this issue ticket and commit: https://github.com/EsotericSoftware/spine-runtimes/issues/1850
Or maybe your project is misconfigured using a 3D URP renderer, as your other asset parts appear black .

foriero escribió

Harald escribió

Then I would guess that you're using an old URP package, this should be fixed on 2021-03-04, see this issue ticket and commit [...]

I'm on 2021.1f1 and shader set to URP/Spine/2D/SpineLit. I'm afraid it is a bug. :-)

I'm not talking about the Unity version. This is the date when the commit was pushed and the URP packages have been released containing this bugfix. So the question is: Are you using this spine URP shaders package?

By URP/Spine/2D/SpineLit I assume you meant URP/Spine/2D/Skeleton Lit right?
While Unity 2021.1 is not yet supported, it still works on my local setup. See this screenshot:

Please also check whether you've enabled PMA Vertex Colors at the SkeletonAnimation component.

That's strange. Could you then please send us a minimal reproduction Unity project, as a zip package to contact@esotericsoftware.com?

Thanks for sending the reproduction package.

After having taken a look at your reproduction package and seeing additive slots working as expected, I think I now understand what your expectations are vs what the implementation actually does. PMA additive slot behaviour has been fixed so that it is not lit first and then writing the lit color to the target buffer as additive color, but it always writes unlit texture.rgb * vertexcolor.rgb to the target buffer. Additive slots have emissive qualities, which would not make a lot of sense to require a light close to it to make it visible. Now I assume that you expect any nearby 2D lights to make the additive color even brighter than it is. Does this explain the situation?

foriero escribió

Please ping me here once your overhaul has been completed. Appreciate your work. Thanks.

The linear color space issue ticket has just been completed!
New 4.0-beta packages (spine-unity, URP and LWRP shaders packages) have just been released:
Spine Unity Download
Any feedback or problem reports are highly welcome as always!

foriero escribió

But if it is kind of 2D light it actually needs to work that way. I mean you should see the impact of the light on the objects around. Otherwise the implementation as it is does not make sense, does it?

I guess I don't quite understand. What I was saying is that the 2D lights should light "passive" reflecting parts normally, but they should not light emissive parts. The emissive parts are lighting the surrounding environment already, so it should not require a second light to lighten the environment.

What did you mean does not make sense? Could you perhaps describe an example use case?

I just noticed that the terminology I used was very unfortunate. I was using "emission" from an older time period where emissive pixels were added to the scene on top (as an additive or "screen" overlay in Photoshop), but not multiplied with the scene in any way like realtime GI or anything like that (as a light would be multiplied with the albedo/diffuse color of the scene).

Harald escribió

The emissive parts are lighting the surrounding environment already, so it should not require a second light to lighten the environment.

Here I was sloppy with the wording: Instead of "lighting the surrounding environment" I should have written "brightening the pixels below it". You are right that this will not influence the environment like a light would, it just makes the area additively brighter, but will not replace a light and cannot bring out details again in an unlit background.

The intention is to have the attachments with additive blend mode separately controllable (making them brighter or darker) from a separately placable light that affects the scene. So you can e.g. make the additive texture very bright, but at the same time have the light intensity low to not mess up the contrast.

While talking about it, I think we should add a material property HDR color Additive Color where you can tweak both the color and the intensity of all your additive attachments at once.

I see your point, thanks for the input. I will add a parameter back in that allows to switch between lit and unlit additive blending behaviour. This should bring back easy control and also allows for separate tweaking, if that is desired.

@[borrado]
The parameter Light Affects Additive has been added to all lit shaders (including URP and LWRP shaders). I will add the mentioned Additive Multiplier HDR color material property in a separate release.

From the changelog:

changelog.md escribió

Additive Slots have always been lit before they were written to the target buffer. Now all lit shaders provide an additional parameter Light Affects Additive which defaults to false, as it is the more intuitive default value. You can enable the old behaviour by setting this parameter to true.

Updated 4.0-beta packages are available for download here as usual:
Spine Unity Download
Also be sure to update the spine-unity core package as the shared Sprite shaders GUI resides there.