Pharan Importing the spine-csharp and spine-unity runtimes through the git URL worked ok.
The package naming style doesn't match the other packages but that's not a huge issue.
True. Unfortunately the naming has to be spine-unity and spine-csharp in small caps with a dash in-between by our convention, as you already know. As you say, this should not be a problem.
Pharan Importing the spine unity examples through the git URL kind of disables its primary use because it doesn't allow the user to open the scenes in the package.
Yes, this limitation/bug started with a certain Unity version (I don't recall which exactly). It's documented in the FAQ here:
Why do I get the error "Opening scene in read-only package!" when opening a scene from a git UPM package?
Just copy the content over. I agree that it's not great though.
We are planning to move the Spine Examples to the Samples~ dir like with the Spine URP Shaders package here to make them installable from the main spine-unity package. We just didn't get to it yet (it requires updating documentation in several places and languages as well). Perhaps now is the time to do it though.
Pharan The colors in the sample skeletons are washed out. This is because in Unity 6 (and a couple of versions before, for some years now), new 2D projects use the Linear color space.
Linking also this forum thread here for the same discussion.
Pharan To fix the washed-out colors, this texture asset flag needs to be checked. But the spine-unity Asset Importer unchecks it by default, even if the project uses linear color space.
The easiest fix is to:
1) decide which color space to use,
2) come to the conclusion that for typical 2D projects it's Gamma color space and just switch the Unity project to Gamma space in Edit - Project Settings under Player Settings - Other - Color Space as you're showing above.
Pharan My instinct is to have the editor importer detect the project setting using PlayerSettings.colorSpace and add it as one of the Spine project preferences.
That's unfortunately not possible, and even if it were possible, its unreasonable:
1) The atlas texture has already been exported in some way, by default using PMA. If the Unity importer now programmatically detects Linear color space and assigns straight alpha presets, the atlas has already been exported incorrectly. You should get warnings which describe the incorrectly configured settings and what the solutions are in the Console though. Did you perhaps not receive them?
2) Even if settings would match up, it's not a good idea to use Linear color space in the Unity project just because it's the new default now. The unintuitive blending result confuses users all the time who are used to Gamma space blending in all other applications when preparing their assets (Photoshop, etc).
It's a good hint thought that we should likley state it more explicit to switch the Unity project to Gamma color space in the documentation.
Pharan In this context, I think having a new examples package with the atlases exported and materials configured to match the (new-ish) Unity defaults might make more sense.
The URP Shaders UPM package uses straight alpha assets in the included examples for this reason already (New URP and LWRP projects always used Linear color space as a default even earlier). It might indeed make sense to switch all included Spine Examples assets to straight alpha workflow as well. Thanks for bringing this to our attention.
Pharan It doesn't mean PMA shaders can't be used after all.
What exactly do you mean by "PMA Shaders"? The output blend mode of the Spine shaders is always PMA where possible (not at multiply and screen shaders obviously), even if you enable Straight Alpha Texture. This is so that with PMA Vertex Color enabled at the skeleton you can still use single-pass additive blending.
Pharan There's just the possible issue of not perfectly matching what the alternate blend modes look like in the Spine Editor?
I assume you mean having the Spine Editor set to Gamma color space and Unity to Linear.
Note that the Spine Editor can (and should) be configured to use Linear color space to match your Unity project.
"Not perfectly matching" is a bit of an understatement, as semi-transparent alpha blending results in completely different colors (saturation- and value-wise), and the result of "washed out" additive blending is a constant topic troubling users who (accidentally) settled on Linear color space and are either afraid of switching away from defaults or can't switch due to being late in the project or don't have the privilege to decide.
Pharan This is especially important because I think this Unity-first, Spine-second path is a more likely entry point for potential Spine-Unity users testing the runtime to see if it's nice or if they can only anticipate annoyances.
While I don't understand the "Unity-first, Spine-second" part of the sentence, I completely agree that we should get rid of any annoyances if possible. What may be a problem though is if we make Linear color space look more correct, users will notice even later that they have to decide on the color space to be used, which has a huge impact on any subsequent color adjustments. It seems that you too have the feeling that Linear color space is the better option simply because Unity made it the new default, which is a reasonable assumption.
In general, thanks very much for all your input, it's great that you bring these to our attention. We'll definitely be improving the examples in terms of straight alpha and putting them in the Samples~ directory.
