Sorry for the inconvenience!

Tautvydas написал

The same method on spine 3 used to call .Initialize() only for specific renderers (those who had null Materials).

Your described difference of the removed material == null check and only updating certain skeletons was a bug actually, which was tracked under this issue ticket: https://github.com/EsotericSoftware/spine-runtimes/issues/2066
The problem was that all SkeletonDataAssets of a scene were reloaded, but not all dependent Skeletons were updated, with leftover stray references to old Attachment objects, leading to e.g. the bug of the issue ticket above. So the change was a bugfix.

The observed delay would however be something that we would really like to improve. Which version of the spine-unity 3 runtime have you been using before updating to 4.1 (I assume you updated to the latest 4.1 version)? Please always be as precise as possible when mentioning version numbers, to save some unnecessary questions and time.

You mentioned having 40 active Spine objects in your scene: How many different SkeletonDataObjects (skeleton types) are they using in total? The question is whether you see the delay because of 40 skeletons being re-initialized and only e.g. one or a few SkeletonDataAssets being re-initialized, or because of 40 SkeletonDataObjects re-reading the shared data. Since you only mentioned "upgrading from Spine 3" it could be another code modification and not the one removing the material == null condition.

Since ReloadAllActiveSkeletonsEditMode is relevant only when SkeletonData has been (accidentally) modified during play-mode, we have just added additional Spine Preferences setting Reload SkeletonData after Play which can be disabled to avoid reloading every skeleton's SkeletonData.

From the changelog:

changelog.md написал

When enabled, the shared SkeletonData of all skeletons in the active scene is reloaded (from the .json or .skel.bytes file) after exiting play-mode. You can disable this setting to avoid the reloading delay if you can ensure that there are no (accidental) modifications to the shared SkeletonData during play-mode (otherwise it would carry over its effect into subsequent plays). Defaults to true (the safe setting), which maintains existing behaviour.

New 4.1 and 4.2-beta spine-unity packages are available for download here as usual:
spine-unity Download
Please let us know if this resolves your issues as well. Thanks for reporting!

Tautvydas написал

We've moved from spine-unity-3.8-2021-01-08.unitypackage to spine-unity-4.0-2022-07-19.unitypackage.

Thanks for the precise version information, this always helps a lot! Please note that if you want to stay on Spine 4.0, you need to integrate the 4.1 changes manually. In the above case, you would only need to integrate this commit in your spine-unity 4.0 runtime. You could also create a hard-coded version by commenting out the call to ReloadAllActiveSkeletonsEditMode completely, instead of adding the switch via a Preferences setting.

Tautvydas написал

Regarding the Reload SkeletonData after Play setting in Spine 4.1, could you please expand on this part:

"relevant only when SkeletonData has been (accidentally) modified during play-mode"

What are the cases for these accidental modifications? E.g. if we only use the basic API like SetAnimation, ClearTrack, SetToSetupPose, Update etc. is there still a chance for these modifications to happen from spine internal system? Or this only happens if the user does some SkeletonData modifications via script during play-mode?

SetAnimation, ClearTrack, SetToSetupPose, Update and similar methods all don't modify SkeletonData, no internal method will modify it either.

SkeletonData is only modified by directly changing it via scripts during play-mode, e.g. by setting slot color of the shared SlotData instead of the instance Slot, which is typically unintended (due to misunderstanding the Spine API). So if you use the Spine API in the standard intended way, you never modify SkeletonData.

You're very welcome!