@ara Also be aware that if you don't want to setup fully automated atlas texture-export scripts (while we've provided a script which should cover many use-cases here), you could via a simple script copy just the project and replace the main attachment images with their gradient images. Then you can export the same way again without the need for setting up export scripts for atlas export if you want to avoid that for some reason.

@ara My I ask what exactly you are planning to do with the gradient? If we know what you want to use it for, perhaps we can suggest a better alternative which does not need any gradients.

@ara It's not a straightforward task unfortunately. You could use SkeletonRenderer.OnPostProcessVertices to e.g. encode the location data in the unused vertex normals, and access SkeletonRenderer.Skeleton.DrawOrder to know which vertex corresponds to which attachment. This will however fail if clipping is active and is removing vertices and adding new ones.

If modifying the spine-unity source code is an option, you could also modify the MeshGenerator code to directly add location information.

A different solution would be to add a second texture atlas layer (like a normal-map) which contains only the black & white gradient. You could do this either by programmatically packing your attachments in the same layout as normal attachment images (with disabled whitespace stripping, or identical transparent areas). Or alternatively you could draw over the atlas image after it has been exported. You then however need to redo or re-arrange parts of the atlas when added attachments changes the packing layout.

@ara Please note that it's in general recommended to use binary .skel.bytes skeleton export instead of .json format, since the binary export results in reduced file size and load times.

If you have loads of skeletons that need modification, another way could be to write a custom SkeletonDataModifierAsset which upon each import iterates over all animation's Timelines and if it's a RGBATimeline, access the Frames property and check and modify the alpha value accordingly.

An even simpler fix would be to change the line frames[frame + A] = a; in Animation.cs to e.g. frames[frame + A] = a > 0.995f ? 1.0f : a;.

@ara Thanks for reporting and sorry for the troubles! It seems that you've discovered an export bug which has slipped through for quite some time, as it seems to still be present in the current 4.2-beta version. We've created an issue ticket here for you to subscribe:
EsotericSoftware/spine-editor778

Please note that bot the 4.0 Spine Editor and spine-unity runtime will no longer receive updates, so if you stay at version 4.0, I'm afraid you will need to use a workaround for the issue.

@ara No, it won't break batching then, quite the opposite - passing information via vertex attributes while using the same Material is the way to allow batching.

@ara Your observations are correct that calculateVertexColor returns a half4. To be precise, return type in code is fixed4, but fixed4 is defined as half4 for all URP shaders (e.g. here in Spine-Sprite-URP.shader).

The main Spine-Sprite-URP shader can be found here:
EsotericSoftware/spine-runtimesblob/4.0/spine-unity/Modules/com.esotericsoftware.spine.urp-shaders/Shaders/Spine-Sprite-URP.shader#L131
The relevand method call is located here:
EsotericSoftware/spine-runtimesblob/4.0/spine-unity/Modules/com.esotericsoftware.spine.urp-shaders/Shaders/Include/Spine-Sprite-ForwardPass-URP.hlsl#L173

Now the method calculateVertexColor in question is provided here:
EsotericSoftware/spine-runtimesblob/4.0/spine-unity/Assets/Spine/Runtime/spine-unity/Shaders/Sprite/CGIncludes/ShaderShared.cginc#L280

In general you can browse all the shader code and the referenced include files, it's all included with the Spine URP Shaders package and spine-unity unitypackage. Note that the URP shaders sometimes reference spine-unity core shaders like #include SpineCoreShaders/SpriteLighting.cginc which includes #include "Packages/com.esotericsoftware.spine.spine-unity/Runtime/spine-unity/Shaders/Sprite/CGIncludes/SpriteLighting.cginc"".

Most of the time it's easiest to just use a text editor like Visual Studio Code or Notepad++ which can search all files recursively in a given directory. Then you can search for the desired functions from a common top-directory.

It takes me more than 3days to find a solution for root motion, also I find this solution @ara, but unfortunately it does not work for SkeletonMecanim, it just work for SkeletonAnimation, and I finish most of work in Mecanim in my action game, so Arts can naturally complete animation with root motion in Spine Editor, I just need to add them to Unity Animator, set some parameters to translate between state.

pascalkk wrote

@MrSKiny
Thank you very much for your work，and I got some problem with it。I submit a issue on github，hope noticed and I'm trying study it.
Thanks again!

@ara it not transate spinegameobject to Sprites~

thank you for telling me that

I just can't apply Effects on EntityPostProcessor prefab.

@MrSKiny
Thank you very much for your work，and I got some problem with it。I submit a issue on github，hope noticed and I'm trying study it.
Thanks again!

@ara it not transate spinegameobject to Sprites~