• Bugs

  • Java Heap space when trying to export big texture

    anglais
Related Discussions
...

Hi,

We're working on a 4K resolution project and have a background that we're trying to move that is more than 4K in size.
we could set the maximum page size of the packed texture to 8192x8192 but if we try to pack it it will say java heap space issue.
is there a way around this? aside from breaking our huge amount of >4k textures in to smaller textures?

Regards,
John

Typically the GPU is the limiting factor for very large images, but if you are seeing something about Java heap size then Spine's memory is exhausted. What OS are you using?

7 jours plus tard

Hi Nate,

Thanks for replying. if it's an hardware constrain then we could easily get better hardware for the exporting part. but we just can't get over the issue. maybe you guys might know something about giving Spine some more memory to work with.

We're using Win 10 64 bit.

Hi,

We noticed that this only happens when checking the bleed option in the packer instead of PMA. we also tried to reduce maximum asset size to 4098 (by reducing the size of some images). but the issue still occurs so it might be more of a bug?

Regards,
John

  • Nate

  • Message #5
  • Ce post est en anglais

On Windows Spine uses a maximum of 1024MB (1GB) of memory by default, which is plenty for most users. You can specify -Xmx1200m when starting Spine, eg:

Spine.exe -Xmx1200m

How much the OS allows Spine to use varies, often 1100-1200MB. You might be able to squeeze up to 1250MB. The memory limitation occurs because for maximum compatibility Spine is 32-bit, though these days that is not so important. In the future we'll move Spine to 64-bit, after which it will be able to use any amount of memory. There are some significant hurdles to doing that though, so given our other plans it's not something we can do in the near future.

The Bleed setting allocates a number of buffers equal to the image size. For large images this would indeed use a lot of memory. We'll look into making this more efficient! Note that using PMA is better: 1) at runtime blending is slightly incorrect when not using PMA, and 2) at runtime when rendering with PMA you can switch between additive and non-additive blending without flushing the batch.

To be sure, you have the Limit memory setting checked?

We have made Spine's texture packer available as free open source in libgdx:
https://github.com/libgdx/libgdx/tree/master/extensions/gdx-tools/src/com/badlogic/gdx/tools/texturepacker
The documentation for the libgdx version is here:
https://github.com/libgdx/libgdx/wiki/Texture-packer
See the part about the nightly build if you just want to get the JAR to run the tool. Running it separately from Spine likely uses less memory, plus you can use 64-bit Java and give Java as much memory as you want. If you run it from a Java class, you can have it run incrementally (it won't pack if the output files are newer than the input files).

The Spine texture packer differs from libgdx only in that Spine's packer can know about a Spine project in order to handle packing meshes with whitespace stripping. If packing meshes with whitespace stripping is important for you, I'm afraid the libgdx packer is not an option. Also in the near future Spine's packer will be able to tightly pack polygons while the libgdx packer cannot.

Edit: I've improved Bleed to use less memory in 3.7.92. :nerd:

Thank you very much for the help!

We might wait for 3.92 to come out and give it a test first, before trying anything else! 🙂

Will report back on how everything goes.

The if i remember correctly the main reason that we opt to used straight now VS PMA is for us to be able to scale down our images easily and create different sizes of textures programatically. (can't figure out how to do it with PMA) we haven't really run into any rendering issues so far except for when trying to use slot blend modes. which is simple to solve we just opt to not use it 🙂

9 mois plus tard
Nate a écrit

On Windows Spine uses a maximum of 1024MB (1GB) of memory by default, which is plenty for most users. You can specify -Xmx1200m when starting Spine, eg:

Spine.exe -Xmx1200m

I'm suffering the same issue, how do you increase the memory on macOS specifically? If I run it on Spine.app/Contents/MacOS/Spine -Xmx1200m I get "ERROR: Unrecognized command line parameter "X": -Xmx1200m"

Fixed it using

export _JAVA_OPTIONS='-Xmx6144m'

It would be very helpful if there was a more appropriate 2020 default to memory size or if it was configurable in settings.