I need to know how horrible is the thing I'm gonna do...

Abelius

Hi there,

I'm starting a new game project, and after reviewing the ways I can export images from Photoshop to Spine (watched the nice video tutorial), I've decided to not downscale and don't trim the layers.

That is, I'm gonna export the huge images in PS at canvas size. Every one of them. :rolleyes:

My question is... the fact I'll have big images, that are actually transparent for the most part, will affect memory usage up to the point of getting crashes?

Of course, the first thing I'll do is to mesh them to a tight size around the actual image (for a civilized atlas size), but I don't know if Spine will still allocate memory for the full-sized images, which could result in very poor performance and CTDs.

So that's my million dollar question.

About my reason to do this... it's really long to explain. Just bear with me and my stupid question. 😉

Thanks!

Nate

Spine needs to load the whole image into GPU memory, even if you use meshes to cut away the transparent space. I can't say if it will be a problem, as it is mostly dependent on your GPU hardware. You could do some tests, eg duplicate a big image many times and see how many of those you can have in Spine.

Abelius

Ah ok. That sounds pretty terrible, indeed. :p

Thank you for your quick response!

Nate

Hard to say how terrible it is. Nearly any modern video card has _4GB of memory and you get one with 24GB. An RGBA image takes up 4 bytes per pixel, so eg 2048x2048 takes up 16MB. 4GB can fit 250 of those (less since you won't be able to use all the GPU memory just for your images, but you get the point).

Abelius

Yup, for normal-sized projects it would be fine, but my previous project contained more than 1000 individual images and my artist uses a huge canvas size.

Also, the reason I wanted to do this is probably me doing things the wrong way, so I'll just trim them and use a generous padding size.

Thank you, Nate!

Nate

Sure, no problem. A few more thoughts:

Spine only loads the images that are visible at the same time, or are visible at any time during the active animation. This means you can have many images, but they won't all be loaded at once. I've seen a project with 19,000 images, though if you have so many I would suggest a runtime solution rather than setting all those up in Spine:
Runtime Skins - Spine Runtimes Guide: Creating attachments

You can use smaller images in Spine than you use at runtime. At runtime the images can be larger or smaller, you just set a scale factor when loading the skeleton data:
Loading Skeleton Data - Spine Runtimes Guide: Scaling

Abelius

Nate wrote
Spine only loads the images that are visible at the same time, or are visible at any time during the active animation. This means you can have many images, but they won't all be loaded at once. I've seen a project with 19,000 images, though if you have so many I would suggest a runtime solution rather than setting all those up in Spine:
Runtime Skins - Spine Runtimes Guide: Creating attachments

I've been working like this for a couple of weeks, exporting several images at canvas size (2600x1080 approx).

I have a 1080 Ti with 11 GB and VRAM shouldn't be a problem, but it's certainly sluggish when loading several images at the same time (enabling a body skin, for example). I've only had a "Some images couldn't be loaded" just once, probably because of some kind of memory leak.

It's a bit worrying though, and I don't know if I should commit to this project as it continues to escalate with more and more images.

Nate wrote
You can use smaller images in Spine than you use at runtime. At runtime the images can be larger or smaller, you just set a scale factor when loading the skeleton data:
Loading Skeleton Data - Spine Runtimes Guide: Scaling

Uhh... I'm not sure I understood the article, but I'm interested. Does it mean I could have set the scale to 0.25 while importing the JSON generated by PhotoShop, work on Spine with much more manageable images, and then exporting to Unity at the ginormous original 100% size with everything working as it should?

If that is the case, then damn me for not having realized until now! 😢

Err... is there some way to downscale my existing project without losing what I've done (meshing and rigging)?

Nate

Abelius wrote
I have a 1080 Ti with 11 GB and VRAM shouldn't be a problem, but it's certainly sluggish when loading several images at the same time (enabling a body skin, for example).

Spine loads the image data using a background thread, but it needs to upload the data to the GPU on the OpenGL thread. While it's doing that, Spine can't render the UI. Spine limits the time spent uploading to the GPU, but the smallest amount of time it can take is the time to upload one image. If your images are very large, then Spine will upload one, render the Spine UI, upload the next one, and repeat until they are all loaded. This can make the Spine UI sluggish. There is little that can be done for this, except to use a faster CPU and GPU.

Abelius wrote
I've only had a "Some images couldn't be loaded" just once, probably because of some kind of memory leak.

If this happens you can check your spine.log for why it failed. Spine should never leak memory.

Abelius wrote
Does it mean I could have set the scale to 0.25 while importing the JSON generated by PhotoShop, work on Spine with much more manageable images, and then exporting to Unity at the ginormous original 100% size with everything working as it should?

Yep, that's what it means!

Abelius wrote
is there some way to downscale my existing project without losing what I've done (meshing and rigging)?

There is: when you use Import Data you can specify a scale (similar to how you can specify a scale when you load the data in Unity):
Import - Spine User Guide: Scale
You'd export to JSON (be sure to check Nonessential!), import the JSON back into Spine while specifying a scale (eg 25%), then save the project. Of course you'll need all your images at 25% size for Spine to use. Note that JSON does not preserve a few noncritical things, such as bone icons (sorry! it's been on the todo list for ages, but more important things keep coming up).

Be wary of where you save the project: if you put it where Spine can find image files, it'll load those. Spine will expect them to be 25% of the size you were using. If they are a different size (eg if they are the 100% size you were using) then it will ask if you want to scale your mesh UVs. You can just say No, but it may be a little confusing and if you say Yes you'll wreck your meshes and have to use undo or import again.

Abelius

Nate wrote
Abelius wrote
I've only had a "Some images couldn't be loaded" just once, probably because of some kind of memory leak.

If this happens you can check your spine.log for why it failed. Spine should never leak memory.

Hi Nate,

My project is growing with dozens (if not hundreds) of those images exported at canvas size, and this issue is getting more frequent.

So, I need to exit Spine and enter again, and it works well for a while, but I'm afraid this will get worse and I can't even work for five minutes straight.

Let me paste you what I've got from the log last time...:

ERROR: Unable to read image file: C:/_HHS/SPINE/Side/./images/Female/Foot_F_Sock_White_Shaded.png
gS: Unable to allocate memory for pixmap: 1144x2602, rgba8888
   at com.badlogic.gdx.graphics.g2d.Gdx2DPixmap.<init>(SourceFile:124)
   at aj.<init>(SourceFile:118)
   at Pg.D(SourceFile:1078)
   at lPt6.D(SourceFile:3070)
   at it.call(SourceFile:64)
   at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
   at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.base/java.lang.Thread.run(Unknown Source)

The thing is, the way I manage attachments could contribute to this problem...

This is what I usually have in each slot. Several meshes pointing at canvas size images. I always leave a "catalog" of meshes outside the skin placeholder, so I can easily make a copy and put it inside with each skin I make.

But I suspect the reason I run out of memory is that Spine must use a lot when I mouse over each of them on the Hierarchy. I could easily pass through 8-10 in just one second, and maybe that's why Spine "overloads".

Also, once this happens and I start getting "error loading images" messages, it doesn't matter if I disable all skins. Not a single image gets loaded after that.

As I mentioned, I have 11 GB of VRAM on my video card, but something tells me this doesn't have anything to do with my VRAM. :rolleyes:

I vaguely remember you mentioned Spine will be able to address memory on a 64-bit address space in the next version (?). Could that fix my issues? Or could I do other things in the meantime?

I guess reducing the number of attachments on the slots (by placing them alone in their skins) would make things better... but I'd really like to keep those "catalogs" of sorts, so I don't need to remember what I have.

Thanks for your time.

Update: I've just made a little additional test.

I've opened Spine fresh and started to mouseover up and down those meshes on the Hierarchy, until the errors started to show up. Much sooner than usual.

I've made a little video illustrating it...:

I can also see on the Task Manager (which wasn't captured, lol) that the used RAM goes up fast, but I have 32 GB and it goes from 14-something to almost 17 GB of use, when I do this.

Erika

Hello Abelius, out of curiosity, did you already try to uncheck limit scanning and see if you still get the error in loading the images? Perhaps the error is caused by something different but I thought it would be worth a try.
Images - Spine User Guide: Images node

I'll leave Nate to address the rest of the post, I just wanted to give my two cents!

Abelius

Hi Erika.

Yes, I did after adding 20 hairstyles with 30 colors each. ^_^

Nate

Welp, good job uncovering a pretty severe problem! Spine loads images as you mouse over because it wants to show the attachment in the viewport. When you pass the mouse over many images, it loads and discards them. This is no bueno for massive images, as it loads too much too fast. We'll have to introduce a delay, as we do with the popup when you have an attachment or image file. There are a few other improvements we can do with the image loading logic, so we'll get on top of that.

This is a big enough problem it warrants a new 3.8 release. 🙁 Unfortunately that means we have to drop working on the curve editor until this is handled. It's not a big amount of work, though changing gears itself has some cost.

HEY EVERYBODY! Abelius is responsible for us not having a curve editor! :fuuu: Let's get him before he can find more bugs!

Abelius

Nate wrote
HEY EVERYBODY! Abelius is responsible for us not having a curve editor! :fuuu: Let's get him before he can find more bugs!

LOL :lol:

RobDK

Why, Abelius? The one thing I've been looking forward to since I heard about it... The one happy coincidence in this crazy year... Why did you have to take it away? WHY?

Abelius

I actually hate myself for finding the strangest issues, because this also delays my own personal wet dream of moving linked meshes out of their master's slot. :rolleyes:

Fabiano

Ehh... artists and their fetish for insanely huge images :facepalm:

Nate

Alright, we've got 3.8 up! There were a number of issues with image loading and it is working much better now. We fixed some memory leaks, too aggressively loading, and other issues. It's unlikely you'll see out of memory errors now!

When loading images, Spine only uses RAM to hold the image while it is being uploaded to the GPU. Spine 3.8 is limited to ₁.1GB of RAM usage, but that is plenty to hold everything Spine needs, a huge amount of Spine project data, and still have enough to load even the largest of images. For example, a 2048x2048 image only needs 16MB RAM during loading. To take it to the extreme, a 16000x8000 image needs 512MB of RAM, but only briefly while it is uploaded to the GPU. The GPU has it's own memory limits and also limits on how large an image can be. I don't recommend using images that are so large, but Spine will load them if the GPU allows it. The point was just to illustrate how much of the 1.1GB RAM that Spine has access to is needed for loading images. Now that we have these fixes, memory should never be a limiting factor.

We lost nearly a week, but now we are back to working on v4.0 and the curve editor. Maybe don't find any more bugs? 😉

Abelius

Nate wrote
Alright, we've got 3.8 up! There were a number of issues with image loading and it is working much better now. We fixed some memory leaks, too aggressively loading, and other issues. It's unlikely you'll see out of memory errors now!

Yup, no amount of mouse hovering is using extra RAM now. 🙂

No more cursor circumnavigation needed, yippee! ^_^

Nate wrote
We lost nearly a week, but now we are back to working on v4.0 and the curve editor. Maybe don't find any more bugs? 😉

Aah... I don't know. I have lots of quarantine time to spend, you know. Can't promise anything. :smirk:

Nate

Joking aside, I'm happy these problems were uncovered. They were pretty severe and it's great to have them fixed!

다음 페이지 »