• Unity

  • Need a bit of insight regarding high number of attachments

    engleski

Hello there everyone. 🙂

Need a bit of help over here, we're working on a 2D fashion game, the game is supposed to have a lot of different clothes for the player to pick from (1500+).

The way the clothes are being made is that the main character has a "Master" Spine project where you got the character model with slots and different skin tones, and all clothes on the same project, as attachments. Inside the game we turn on/off each attachment depending on the clothing items being worn.

The problem with this approach we're now seeing are 2:
1) File size is gonna be ridiculously huge when we hit 1500 clothing items, there's no apparent way to split all the clothes in chunks that can be downloaded as needed.
2) Every time we make an update with a new batch of clothes, all the items will have to be redownloaded

I realize those 2 issues are deeply ingrained in the way we're authoring the assets and using it ingame, but is there a different way to tackle these requirements with Spine? We could maybe do multiple overlayed skeletons, but then we wouldn't be able to mix and match clothes from different batches, I assume.

So, any tips/insights on what we could do?

Related Discussions
...

Assuming 1500 attachments were all meshes, the .spine file size is 160 KB. The binary data file size is 1.4 MB and compressed with deflate it is 57 KB. The in-memory size of the SkeletonData is 10MB. All these sizes would be a bit larger as you add more animations. While probably more than many Spine projects, these sizes aren't really ridiculous or unmanageable. The image data may be, but that is something you can handle separately from Spine (update incrementally or on demand, etc).

BTW, to get those numbers I used the raptor example project and duplicated an arm 20 times, then duplicated that slot a few times, then duplicated the parent bone until the Metrics view said > 1500 attachments. I exported to binary, wrote some code to load the SkeletonData and ran it, noting the total memory usage before and after the data was loaded.

As for your options, you could use conventions when creating your art which allow you to dynamically create attachments without needing to specify every attachment in your Spine project. See here for more info:
Runtime Skins - Spine Runtimes Guide: Creating attachments

Hey Nate, thanks for the reply. 🙂

What I mentioned about size has nothing to do with the Spine internals, it is exactly about the image data you mentioned. Currently all the attachment files for every cloth item are on the Spine Project, and when we export those to Unity, it generates about 8 2048x2048 image files, and currently we have only 1/10 of the final clothes ready.

In the ideal world I would like to have the core of the model (base skin layer + default clothes) being exported from spine, and have all the rest of the clothing items externally, preferably bundled in "Sets" for easier loading, and in a way that all these clothes can be mix and matched even between sets.

Since I'm kinda new to Spine I'm not sure how to do that, or if it's even possible. From your links and scavenging the forum so far I saw that I can create an attachment during runtime, with a Unity Sprite. That's a good way forward already, but then we hit another issue: Our images are authored in a higher resolution and downscaled via spine when exporting the skeleton to Unity. That works well for the "All-clothes together" model, but in order to have the clothing parts inside unity for runtime loading, we would have to generate all the textures in the correct size, right?

While Spine can provide a texture atlas, you can also manage your images however you like. Maybe you want to download images as needed, if you have so many they can't be bundled with the app, or whatever other reason. Regarding the image scale, you'll have to provide the images at the size you want, of course. It will likely be most efficient for you to determine what images you need (possibly for multiple skeletons), then generate an atlas at runtime with just those images. If you use individual textures instead of an atlas, you'll have many batch flushes. However, it may make sense to build it that way at first, then generate an atlas later, once your app is further along.

In the future, attached skeletons could be helpful here - they can create one child skeleton for Shirts 0-100, another for Pants 0-100.

Another one for Shirts 101-200. etc.

Oh I see, so it's possible to add images after loading the skeleton? I always assumed you had to load it all together at once.

That's really helpful guys. I think I can take this knowledge and build a proof of concept of sorts to test it out. Thanks a lot!

AttachmentLoader creates and populates attachments with what is needed for rendering. AtlasAttachmentLoader uses a texture atlas, but you are free to implement your own AttachmentLoader. You could simply not load any images, then later when you know what attachments a skeleton has been configured with, configure only the attachments you need with texture atlas region information. See how AtlasAttachmentLoader code for how to do that.

Hey!

If you're using Unity, we've had a solution called Mix and Match for a while now.
The unitypackage comes with a sample scene called "Mix and Match" and a sample MonoBehaviour called "MixAndMatch.cs"

It has sample API calls that you would use on an equip system that makes it so that you don't need to add all your skin/attachment variants/equips/customizations into your Spine Project/skeleton data or need to pack them in Spine Texture Packer at all.
You only need to import them in Unity as Sprites and as long as they are of a standard or predictable size and shape, you can add the base shapes and sizes in the Spine project, and then just reskin them at runtime in Unity by taking data from UnityEngine.Sprites.

Keep in mind that this solution does work best if you put all the base versions of your customizable items in Skin Placeholders. If you were already doing that, then all is good!