Platform: Nintendo Switch
Unity: 2019.3.10f1
Spine Runtime: 3.8-2020-04-14
Summary:
Some players are experiencing crashes that feel almost random, but they all seem to revolve around Spine use cases.
A Spine Skeleton may have completely white textures. When this is witnessed, the game may continue running for a short while but it is guaranteed to crash soon. In other cases, it crashes immediately.
A Spine Skeleton may appear with "messed up" or "glitched" textures (e.g. the character's hair appears on his shoes etc). If a precise screenshot is needed I can e-mail it to you. When this is witnessed, the game crashes shortly after.
Some details:
It is not possible to reproduce in a consistent manner. It "randomly" happens after a few, or sometimes several hours of gameplay - or, in some cases, never at all.
Upgrading Unity or the Spine runtime must be avoided if at all possible.
We use Unity UI, so it's SkeletonGraphic instances. No, we have not confirmed whether it happens with regular Skeleton renderers, but it's not really an option at this point.
Unfortunately, this isn't something we personally managed to reproduce with either dev kits or retail hardware. What we know is from user reports, but they have all been consistent in the symptoms listed above.
This is not confirmed and may be entirely wrong, but it may be ultimately crashing in UnityGfxDeviceWorker. This suspicion is just based on similar crash reports from other platforms, but it might be unrelated.
The files are "correct". That is to say, we have successfully loaded every single skeleton that the game has and also played all of their animations, so it's not a file corruption issue.
Almost nothing uses the skin system. Only one entity has its skin changed dynamically in the game, and yes that entity has had this issue as well.
We always disable "Use Clipping" for performance reasons.
These issues are not observed on neither Standalone nor Playstation 4. However for PS4 specifically, it uses Unity 2019.4.2f1. Standalone does use the same 2019.3.10f1 though, and our playerbase on it is large and has not encountered this issue on Desktop.
While it feels random, it always happens with Spine entities - perhaps a character, or an animated background, etc. Below I will describe the general workflow for, say, our characters.
When building the game:
One folder per character.
The folder contains the Spine export of said character (the atlas, the json, the generated skeleton, material, etc).
The folder itself is an AssetBundle. Therefore, one AssetBundle per character.
Generated bundles are placed in StreamingAssets.
When running the game:
When a character is needed, we read the bytes from the bundle and then load it:
AssetBundle.LoadFromMemory(byte[])
Note: does not make a difference to use LoadFromFile() instead.
Note: not tested with async loading, but it's not advisable to go async at this point.
Once the bundle is loaded, we load the skeleton:
var skeletonData = bundle.LoadAsset<SkeletonDataAsset>(skeletonDataName);
And then, once we have the skeleton, we load it into a SkeletonGraphic that's already in the scene:
SkeletonGraphic skeleton = GetComponent<SkeletonGraphic>();
skeleton.skeletonDataAsset = skeletonData;
skeleton.Initialize(true);
skeleton.AnimationState.SetAnimation(0, "idle", true);
Finally, we unload the bundle but do not unload the game objects (otherwise we'd lose the textures):
bundle.Unload(false);
Note: originally we didn't even unload it. In other words, this issue occurs regardless of unloading the bundle or persisting it, so we don't believe than Unload() is related.
When the character is no longer needed (e.g. it dies), the object is destroyed. In the future if the same skeleton is needed, the steps above are repeated (the bundle is reloaded all over again).
Note: we also tried by caching the bundles, skipping step 1.
Insights:
The game is not running out of memory, or even close to its limit.
Some skeletons use POT textures, a others NPOT. So far there is no indication that one is more responsible than the other.
Most skeletons use a texture that is at most 2048x2048. Very few ones, like large backgrounds, may be up to 4096x4096.
This is not confirmed and may be entirely wrong, but it may be ultimately crashing in UnityGfxDeviceWorker. This suspicion is just based on similar crash reports from other platforms, but it might be unrelated since they did not present the above symptoms (white textures etc).
Large skeletons might be more susceptible to the crash. I say this simply because it often happens when entering a scene with an animated background (which is the largest kind of skeleton we have).
Note: perhaps it's not because of a large skeleton, but several skeletons within the same frame.
I believe that a project upload is not necessary because you will likely not crash even after several hours, and the above snippets already outline what we're doing in general.
Thank you for the help.
Additional info, which might be relevant perhaps:
Multi-threaded rendering is turned on.
Graphics Jobs is turned off.
