Related Discussions
...

Hi, I've Created an avatar system using spine with 15+ slots with many items you can equippe your avatar with,
it's a multiplayer game with a lot of users which log in and change their equipment every few seconds which causes the avatar to perform a repack of their newly equipped items, every repack with that amount of slots and items freezes the main thread and makes the game really laggy, is there a way to do the repacking part on another thread? maybe using the new job system or something similar? :think:

We already have parallelization of the whole Spine Unity runtime scheduled in the not so distant future. Unfortunately I cannot provide you with an estimate, since high priority issues such as bugs will render any estimate useless.

Parallelization will also not solve the ultimate problem causing hiccups on graphics APIs where texture uploads need to be performed on the main thread (GL, DX).

Are you creating a new atlas everytime the player switches items? If that's the case, a better solution is to pack one big atlas with all items available to the player, and then create a new skin based on the set of items currently equipped. Creating a skin doesn't have any significant performance penalty.

Thank you for the quick response @Harald, i'll be waiting for that.

@badlogic, my app allows users to customize their avatar with thousands of items with 3 directions for each item, so creating a big atlas with all of these items is out of the question, and if what you're saying is true i might have to think of a different solution to this problem

Then I would suggest not baking the atlas every time the user switches equipped items but instead following the Spine Examples/Other Examples/MixAndMatch scene, where the script shows how to either repack the atlas or just assign attachments from different textures without rebaking:

spine-runtimes/MixAndMatch.cs at 3.7

It would then potentially still help to pack as many items as possible into bigger item-atlases to avoid having 15 textures (and draw calls) per character, if you can group them in a reasonable way. You can test its impact on framerate and number of drawcalls via the Unity profiler or simply via the Game window Stats view.

Thank you for the quick response @Harald, i'll be waiting for that.

About waiting for parallelization: @badlogic is right about the texture upload, if 10 characters are switching items at once, there might very likely still be framerate hickups when repacking multiple atlases due to the texture upload. So I would first try not baking the atlas at every character, but instead use shared item-atlases as described above.

If i don't bake the atlas every time the user switches his equipped items i'll have a big amount of draw calls,
and since the player can choose from various items there's no sensible way of grouping items together into an atlas as well

now, about the parallelization, the likelihood of 10 players switching items at once is very low, I predict that 3 players will need to execute the repacking at the same time in the worst case scenario, so maybe parallelization wouldn't be a bad option after all?

The lag you see is because the main thread is stalled by the texture upload. That upload can not be parallelized.

About grouping: any way of grouping will be beneficial, even if you toss them into atlases randomly - 10 atlases will perform better than 150 separate item textures. And even a high amount of drawcalls will perform better than rebaking two atlases in a single frame.