I haven't done anything with shadows so I can't help with that part, but in your 2nd gif, when you enable Write to Depth you need to add a bit of Z-spacing between your images when they are rendered. You add the Z-spacing on the Skeleton Mecanim component (check out the Warning popup on the Skeleton Mecanim component in your gif when you clicked the Write to Depth checkbox). That will fix the flicker.

pizzamom написал

My first issue is from rotating my spine model 180 degrees along the y axis. It's casting a shadow on top of the model now and I'm not too sure if there's something I can do about that.

Unfortunately we could not reproduce the first issue you are showing. This would be easy to explain if the Universal Render Pipieline/Spine/Lit shader was used (where you have to enable Double-Sided Lighting), but not for the Universal Render Pipieline/Spine/Sprite shader. I assume that your downloaded version of the urp-shaders package is quite recently downloaded from the download page, right?

If this is still relevant for you, could you please send us a minimal Unity project that still shows the error, as a zip package to contact@esotericsoftware.com. Then we can have a look at it.

pizzamom написал

I switched to URP for a couple of reasons and one of them being I want to receive shadows on my spine models. I was reading that "write to depth" was the setting I was looking for but it's causing me some weird layering issues.

Jamez0r написал

in your 2nd gif, when you enable Write to Depth you need to add a bit of Z-spacing between your images when they are rendered.

Thanks @Jamez0r for answering!

@pizzamom Please note that there is a red exclamation mark showing up with the message "Warning: Z-Spacing recommended.." next to it, also seen in your GIF. Whenever you see such a warning, it has been added by us to warn you about most likely incorrect settings, and describing what you should do to correct the situation. This is what Jamez0r suggested above.

Yes, Z-Spacing is not really a great option if you want to rotate the character around (typically you would scale a character to flip via e.g. skeleton.ScaleX = -1). Using Z-Spacing with rotation, you would then need to set positive instead of negative Z-Spacing programmatically via script when facing away.

Nevertheless we would recommend to not use Write to Depth and no Z-Spacing. Instead it would be advisable to fix the first issue instead, making the backside correctly lit. As mentioned, you can send us a minimal reproduction Unity project to have a look at what's going wrong.

Thanks for sending the reproduction package.

I just noticed that there were two problems on our side:
1) The URP/SkeletonLit shader not receiving shadows as the respective code is missing, now tracked under this issue ticker:
https://github.com/EsotericSoftware/spine-runtimes/issues/1840
2) The URP/Sprite shader disabling the "Receive Shadows" parameter when "Write to Depth" is disabled, although it would work without writing to the depth buffer. I have just published a fix for this second issue:
https://github.com/EsotericSoftware/spine-runtimes/issues/1839
A new 3.8 unitypackage is available for download where the "Receive Shadows" parameter can be enabled independently (note that the spine-unity core package needs to be updated, not the URP extension package).
So you might choose to switch to the Sprite shader now, or wait for the second bugfix.

You can find the updated 3.8 spine-unity unitypackage download here as usual:
Spine Unity Download

I will follow up here on the forum when the second issue has been resolved as well.
Thanks for reporting!

Answering your question received via email here on the forum so that others can benefit as well:

pizzamom написал

glad I could bring some attention to these! I'm trying the 3.8 package now and the lighting is working, although it's a similar issue to my original post where when flipped the shadow is cast on the sprite.
Is there something similar to the double-sided lighting feature used on the skeleton-lit shader?

Regarding URP/Sprite shader and rotation:
It indeed seems that when Receive Shadows is enabled and although fixed normal in screen space is provided, it casts a shadow on itself (perhaps shadow bias going in the wrong direction). When no normalmap is assigned, it seems that the backside is not lit at all.

It seems that not many are using the URP shaders with 180 degree rotation (instead of negative scale).
I have created a new issue ticket here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1842
Thanks again for reporting!

You can subscribe to the issue ticket. As soon as a unitypackage has been released I will post on the respective thread (which means here) as well.

We can gladly announce that both of the URP issues have now been resolved:
SkeletonLit now receives shadows, and skeleton rotation is no longer problematic for receiving or casting shadows.
Along the way we have also improved the shader code:

Changelog.md написал

URP and LWRP Sprite and SkeletonLit shaders no longer require Advanced - Add Normals enabled to properly cast and receive shadows. It is recommended to disable Add Normals if normals are otherwise not needed.

You can download the latest URP and LWRP packages for the 3.8 runtimes here as usual (4.0-beta packages will follow in the next few days):
Spine Unity Download

It is also recommended to update spine-unity since we have removed a no-longer correct warning message stating "Add Normals required for URP shaders".

Please let us know if this resolves the issues on your end as well.
Thanks again for reporting!

Sorry to hear that. Are both characters setup to cast and receive shadows? Which shader are you using on both characters now ?

Thanks for the additional info.

After some analysis it seems that the Universal Render Pipeline is in general behaving a bit strangely in this regard. I was able to re-create a similar situation with Unity's own Universal Render Pipeline/Lit shader used on two skeletons and one grey cube, as shown below. The skeletons have normals generated, one is rotated so that the front is facing the light and one is rotated so that the back is facing the light, thus being black.

In game view it incorrectly looks like this:

In Scene view it looks like this when the camera is slightly positioned to the left, so that the black skeleton is treated as in front of the other skeleton, as it's closer.

It looks correct in Scene view when orbiting the camera to the right, so that the black skeleton is treated as behind the other skeleton:

So the conclusion from this is that it is not related to shadows, but to how objects in render mode "Transparent" (which test their depth against the Z-buffer, but usually don't write to it) are drawn. Unfortunately I know of no programmatic solution for this problem that we could provide. The solution would be to ensure that there is always a bit of spacing between models, as you would normally do to prevent Z-fighting when having depth write enabled.