• RuntimesUnity
  • Memory Issues with Loading of Atlases in Unity

Hello!

We are running into an issue with in-game memory consumption when using Spine in Unity.

When a SpineData asset is put together it can hold multiple Atlases. These Atlases are used from within the animations and because of this the Spine asset pre-loads all attached atlases. When this is also paired with Addressable Assets it is an even larger issue. We have multiple characters with Spine Data and each Spine Data asset can have 15 to 20 Atlases which are about up to 2.5 mb each. If we multiply that by 25+ characters that is roughly 1gb of memory that is being loaded as soon as the game starts up.

We've tried to work around this issue, but because all the atlases are referenced in a scriptable object and that object is delivered via Addressable Assets, everything for every character gets loaded into memory.

This user is experiencing a similar issue and has a similar request.
EsotericSoftware/spine-runtimes1890

The end result is that we need a method of On-Demand loading the atlases. We are starting to see our game crash on low to medium iOS devices due to Out of Memory exceptions, vastly due to this issue.

What are your recommendations to handle this?

Related Discussions
...

@nwalton Sorry to hear you're facing memory issues, thanks for reaching out to us.

You can find some postings on the forum (also mentioned in the three thread URLs of the ticket mentioned above) which describe in prose text how you could implement an on-demand-loading implementation based on programmatically replacing each Material's textures with placeholder textures, and then once the materials are used, loading them. It would be based on a pre-build-step replacing all your AtlasAsset's material's with placeholder dummy textures (and replacing the textures back to the normal ones as a post-build step to maintain normal in-editor behaviour).

However, since this ticket has been waiting too long already, we will start working on it right away, as it will likely benefit too many users to be waiting much longer. Please note that we can't provide an ETA, nevertheless it would likely be quicker for you to wait for our implementation, be it an experimental example implementation or a final one.