How to optimize a Spine Char with MANY large attachments?

kbm

Hey there,

we are developing a game that uses Spine extensively, most of all for the main Character on screen:
The char consists of lots of bones and slots (obviously) but most of all, MANY possible attachments for each body part.
In Unity, we only ever load one attachment each, of course, but every 1-2 minutes the game dynamically changes a lot of the attachments.. for example every 1-2 minutes we re-roll the look of the character and use "head-2" instead of "head-1" or "arm-23" instead of "arm-12"..

What I'm fearing now is that having this many quite large (up to _600px height/width) attachments is negatively impacting the performance..we are now planning to add many more varieties to the character and I want to optimize this as much as possible.

Does Spine/Unity even load currently unused attachments for slots into the graphic memory or am I wrong in this understanding?

Does anyone have any experience in regards to this?

Oh, I forgot to mention: we are NOT using "Skins" for this, only different attachments that we switch around via script "SetAttachment()"..skins were way too buggy with many other things such as submesh renderers and caused too many problems..

Pharan

All attachment objects are loaded into memory when the json/binary is parsed.
The attachment objects themselves aren't that big. They're just a bunch of floats and a reference to the UnityEngine.Material they need.

Loading textures is probably what you'd worry about. You should be aware that Spine (like most systems) uses atlases to improve draw call batching, so each attachment's texture isn't loaded individually but as part of an atlas.
Each 1024x1024 atlas texture is roughly _5MB of VRAM (graphics memory). Each texture doesn't take long to load into graphics memory but enough of them can add up.

So what you want to control is texture loading.

What about Skins was buggy?

This topic may be interesting: Equips, Customization and Mix and Match
Mentioned as part of this system and future functionality is the work-in-progress attachment utility functions and runtime packing. This allows you to map individual textures to newly created or duplicated attachments, and repack the backing textures into a new atlas when you need to at runtime.
It currently works, but we have no ETA on when it will be officially done (cleaned up API, samples, etc).

kbm

Thank you so much, Pharan.
Regarding the perceived "bugginess" of skins: I never got skins to work in the way I wanted to, which is basically the "mix and match" system you conceived 1 month ago in the thread you linked to..soo.. I just put them in my brain as "buggy", I guess, because they were of very little use to me, yet.

This all really helps!

Since we're quite far into our project and our current attachment-switching mix-and-match system is usable, yet not optimized at all..I'm not sure how stable and reliable the mix-and-match system from the other thread is, yet.
The only advantage I see of trying this out now would be performance and I can't really project how much memory usage this will save in the end (if it saves anything at all?)

As of now the probable amount of textures we will use for the main character in the game is five 2048x1024 px textures..the game is intended to run on mainstream PCs and MACs.. not sure if this is way too much or not..

Another question: Would it be an okay solution to just switch out the entire SkeletonData asset at runtime, right before the character re-rolls its look?

Pharan

On Windows and Mac computers, you should have no problem. Even the lowest low-end graphics have about 1GB or 2GB of VRAM.
Compare that to _10MB of VRAM consumed per 2048x1024 texture.
If you can't hit the numbers you want, you really have to lower your texture resolutions but I highly doubt that will be a problem unless your enviro/set piece assets and everything else are actually humongous and take up more memory. You should see your actual numbers before jumping to conclusions about what needs optimizing. It could be nothing.

Re-switching out the SkeletonData. I guess you could. Set the skeletonDataAsset field and call Initialize(true).
You could just as well instantiate a new Spine GameObject and there wouldn't be much of a difference.