• Editor
  • Spine Out Of Memory

Related Discussions
...

Hi guys,

I'm noticing the latest revisions of Spine are running into a memory problem. Is there anything we can set to not have these pop up? I can't export my JSON files sometimes due to memory. A restart fixes it, but it didn't do this in earlier versions. 😢

Can you post or send a project that runs out of memory? contact@esotericsoftware.com Even when we open large projects Spine doesn't use much memory, so we haven't been able to improve it.

3 años más tarde

Hi, we are having the same issue with the out of memory message when exporting the json file.
We used a while ago a syntax to run Spine with more memory and it worked back then.Now even this is not working anymore.Our project is 56 mb in size with a 400 mb images library.
What do you advice us to do?

Thanks in advance!
Vlad

@fns/Vlad, what version of Spine are you using? Are you packing an atlas when you export the JSON? Do you have Pretty print checked? If so, try unchecking it.

The only reason to use JSON is if you need to read the data. Otherwise you should be using binary, especially if you have a large project. Please check if a binary export succeeds.

As a last resort you can increase the maximum amount of memory Spine is allowed to use by running it this way (for example, for 4GB):

Spine -Xmx4096m

Hi Nate, we are currently still working with the 3.8.97 version because of game compatibility.We are not packing atlas and also do not have pretty print checked and yes as i said we tried maximizing Spine memory using -Xmx1500m.

We should talk to the programmers regarding the use of binary type as you said.Till then i will try a few things recommended by you and come back asap with a reply to this.

Thank you!
Vlad

Ahh, OK. Binary is definitely better, for faster export, smaller file size, and faster loading speed. There is also no reason to stop at 3.8.97, you should use 3.8.99. It will work with the same runtimes you are already using.

2 años más tarde

Sorry for the necro, but I don't think posting a new thread for a 3.8.99 version issue would be better, heh.

My project is also really big and complex after years of adding all sorts of images, animations, constraints, etc. And I also can't upgrade to 4.x anytime soon.

Now I'm getting Out of Memory errors when exporting. Not always, only after working with the project for a while.

I'd export to binary if that solves the issue, but my problem is that I'm using a json version in Unity to extract information about slots, so even if I use the better performing binary, I'd still need the export process working for that purpose.

If I restart Spine I can export without errors, but I'm kind of afraid that it is at the breaking point and some day it won't work regardless of restarting.

So, my question: is there anything I can do to reduce memory usage? Or better said, what consumes memory the most in the export process? Number of images, size, animations, constraints...?

Thanks.

Er... I'm kind of confused now.

I've tried to switch the .json to the binary .skel.bytes file in the skeleton game object prefab in my game, and it turns out that everything is working as before?
Unless something breaks later, I didn't find any problems and it's still extracting the information I need about slots, animations, and such.

So, maybe this is lack of knowledge on my part, and I could have used binary exports all these years, lol.

Just to double-check... the only thing I need to do to switch a skeleton to use binary instead of json, is to change the referenced file here?

If you are using 3.8 or lower, the most you can do is set -Xmx as high as possible. That may only be 1200 or so, depending on what the OS allows. Since it's a 32-bit app, nothing can be done to give Spine more memory. Once you upgrade to 4.0+ Spine is a 64-bit app and can use an amount of memory (it's also much more efficient).

Exporting from the CLI will minimize memory usage. Otherwise memory is used constantly for all kinds of things, like undo and many other systems.

Using binary at runtime should work fine. The API is the same. You'd only JSON if you are actually parsing the JSON yourself or there is a human that wants to read it.

(Upgrade to 4.2! 😜)

    Nate Yeah, 4.x is way more efficient at loading my canvas-sized images and 4.2 has that sweet physics feature. But, as they say, the third is the charm: I'm waiting for off-slot linked meshes. xD
    Nah, seriously, I need to find a big time gap between game updates. I tried before and it didn't work because of the sheer number of constraints I have (400+).

    As for the memory issue itself, I'm using binary now. I didn't even notice you could import skeletons from a binary file and I've been using Spine for 7 years, lol. Sometimes you just need to go to the doctor (the forum) for the ache to disappear.

    Thank you!

      Abelius I'm waiting for off-slot linked meshes

      I know it's not the feature you're requesting, but have you tried Weld yet? It's pretty sweet and basically gives you the same, if not better and more flexible, result that a linked mesh would give! (because this one can work on any size!)
      https://esotericsoftware.com/spine-weights#Weld

        Erika That looks interesting indeed! 4.2 feature?
        Welp, I guess I'll need to make an effort one of these days...

        You can see a couple of quick examples of it being used here:

          Erika Thank you, Erika.
          Btw, something weird may be happening with links, me thinks.
          I've only seen the YT link on the notification email, not here, and an image I linked above has disappeared as well. :-/

          Your post above had a malformed image. I've edited it to work right. Should be this to inline an image:

          ![](https://i.imgur.com/0y6GN1w.png)