Working with big atlases/a lot of skins in Godot

Aasaflein · 24 févr.

I'm working on a mobile game with a lot of customization options. For example, each character can have up to 80 dresses, 40 hairstyles, a variety of jewelry, different skin types, etc. In the game, we want to unlock a certain number of items as the player progresses. For example, at level 1, the player has access to 10 dresses; at level 2, another 10 dresses are unlocked. Additionally, if a player purchases any items from previous levels, we need to ensure they remain "available" for use throughout the game.

The problem I'm facing is that the character models themselves are quite large, and I notice that all the textures are loaded in-game at once, consuming a huge amount of memory. There might be several characters on the screen at the same time as well.
I see that Unity's runtime has a method called GetRepackedSkin, which, if I understand correctly, addresses this issue. However, I couldn't find a similar solution for Godot. I have some thoughts on how to possibly solve this with exporting each item, i.e. each dress, as a separate atlas, but this feels like a wrong approach to solve this.

Is it possible to resolve this issue in Godot with the current state of the runtime? Maybe there's a workaround? I'm willing to invest a reasonable amount of time to solve this, as it's a bit late to switch to Unity at this point, so I'd appreciate any guidance.

Spinebot · 24 févr.

In Godot, managing a large number of skins and textures efficiently can be challenging, especially for mobile games with limited memory. While Godot does not have a direct equivalent to Unity's GetRepackedSkin, you can consider a few strategies to manage memory usage effectively:

Dynamic Loading and Unloading: Implement a system to load only the necessary textures and skins at runtime. You can achieve this by organizing your assets into smaller atlases and loading them as needed. Use Godot's resource management to unload textures that are not currently in use.
Custom Skins: Use the mix-and-match approach to create custom skins at runtime. This allows you to combine only the necessary attachments for a character, reducing the number of textures loaded simultaneously. You can create a new skin programmatically and add only the attachments that are currently needed.
Texture Atlases: Consider splitting your texture atlases into smaller, more manageable pieces. This allows you to load only the parts of the atlas that are needed for the current scene or character customization options.
Level-Based Loading: As players progress through levels, dynamically load and unload assets based on the current level's requirements. This ensures that only the necessary assets are in memory at any given time.
Asset Bundling: Group related assets together and load them as a bundle. This can help in managing memory usage by ensuring that only relevant assets are loaded for a particular scene or character state.

By implementing these strategies, you can manage memory usage more effectively in Godot, even with a large number of customization options.

Jjeedee · 24 févr.

I'd also like to chime in there. I tried last weekend to convert my game to godot which has the same requirements; a lot of skins customizations packed with Spine packer but stored in different atlases (I have 5 customizations slot, each with 100+ customizations and growing).

So far I tried;

Dynamically loading an external atlas (eg. head-01.png) and using regions
Dynamic merging atlases to multipages so I would just get what I need in a single atlas but multiple textures
Loading the atlas, and writing the UVs myself.

But no dice. I guess the next step would be to code a custom multi atlas loader, but I'd like to avoid the C++ path if possible. If anyone has a solution, it would be greatly appreciated, otherwise I'll stick with unity, which I'd rather not.

Misaki · 25 févr.

As Spinebot answered, unfortunately the spine-godot runtime does not have an equivalent to the GetRepackedSkin method provided by the spine-unity runtime. This actually uses Unity functionality, so it may be difficult to provide a similar method in Godot.
The following guide is common to all Spine Runtimes and explains how to create and configure skins at runtime. If you haven't read it yet, please do so: https://esotericsoftware.com/spine-runtime-skins

The following thread is a discussion about the case of a large number of skins in spine-ts, but I think the idea is common and may be helpful:
https://esotericsoftware.com/forum/d/24661-how-to-do-lazy-loading-of-skin-textures-in-webgl

Mario · 25 févr.

There's currently no way to emulate spine-unity's GetRepackedSink() in spine-godot, as that'd require a way to:

Access the pixel data of all involved atlas' pages
Recombine a subset of that pixel data (regions) into a new atlas, doing some form of rectangle packing
Load that new atlas on the fly

You can get the pixel data from the textures in a SpineAtlasResource. However, you'd still need to load all the involved atlases to pick out the regions you need for the customized character. That'd be a loading step due to how much time it takes to do all that work.

You'd have to create a new texture, draw the regions you need from the atlas pages to it (along with packing them in a sensible way to not waste texture space). Then you'd need to construct a new atlas. Currently, there's no way to create a new SpineAtlasResource on the fly, as the API needed to create texture regions is not exposed.

The alternative to creating a full-blown atlas would be to set create and set your own attachments on a SpineSprite (or rather, its internal SpineSkeleton) via SpineSprite::set_attachment. The problem with that is that:

There's currently no way to set an actual attachment instance
Even if we had that method, memory management would be rather hard, as you'd be in charge of ensuring that any custom attachment (consisting of a texture and texture coordinates that describe the region in the texture to be used by the attachment) is freed up when no longer needed.

Long story short: it's currently not possible. I have to think of a way how to expose all this in such a way, that your apps don't blow up due to memory related crashes.

I've added an issue here you can follow
EsotericSoftware/spine-runtimes2767

I'll consult with @Harald on how to best go about this. It will take a while to materialize.

Aasaflein · 25 févr.

Thank you Mario . Any ETA, when this might be expected? To at least get a rough understanding, i.e. 1 / 3 / 6 / 12 months

T.Fly() · 3 mars

I was returning to the forums to see if there was any progress on this. Looking forward to the day this will be possible, for now I'm going with Unity for this purpose.

Misaki · 4 mars

Sorry for the late update on this. Mario has been on medical leave recently and has not been able to answer questions in the forum or work on runtime improvements. I am sure he will work on them in phases when he returns, so we appreciate your patience.