- Düzenlendi
Question about skin character constructor in Spine
Hello! I’m creating game and have some problems with spine animation.
I have a character constructor in the constructor of 6 cells. There are 10 elements for each cell. Example: cells are letters (A, B, C, D, E, F), the elements are figures (1,2,3,4,5,6,7,8,9,10). There may be different variants: A1, B2, C3, D3, E6, F1 or A1, B1, C1, D1, E, F1 or A6, B6, C1, D1, E1, F6 and so on! That is, thanks to a small number of elements (60 pieces are 10 elements for each cell), I get a huge variety. My task - to implement through Spine the connection of different groups of 6 elements.
It’s worth noting that it’s about creating characters, which means each set of 6 cells is a unique character. Animation spines in the characters will be typical. I use the Professional version of Spine.
What options and tools can you offer to implement this correctly through Spine? The easiest option is to make an atlas with all 60 elements and take the necessary ones from the atlas, but it does not suit me, since I’m making a game for mobile devices and such a large atlas can heavily load the phone and the game will lag.
Ofcourse I use Spine and engine is Cocos-2dx!
Thank you forward for your answer and help!
Your first problem is the atlas. The size of the atlas image (mostly) doesn't affect performance. The main limitation is that some devices won't load atlas images that are too large. 2048x0248 is a pretty safe size. If you can fit all the images in a single 2048x0248 image, then your life is much, much simpler. If you can't, you can use multiple atlas pages which will require more draw calls. This can be acceptable as long as the total number of draw calls doesn't cause poor performance. Since you want to mix and match atlas regions, it probably isn't possible to organize the regions so a single atlas page has everything you need for rendering one skeleton, making the worst case for the number of draw calls 1 per region. The last and most complex option is to have individual images in the game and to pack at runtime an atlas containing only the images you currently need for rendering, ensuring they all fit on a single atlas page and therefore require only a single draw call.
Once you get past that, the Spine Runtimes API allows you to configure a skeleton with any attachment you want.
14 gün sonra
Hello and thank you for your answer!
As I say before, the game is for mobile devices and it must work well, without lagging.
We can't fit all images in one atlas, unfortunately.
But, in the wors case we will have to load 6 atlases. Is it problem for mobile devices or not? Is 6 atlases in separate scene of the game big number or not?
And 3-rd advice!
Nate yazdıThe last and most complex option is to have individual images in the game and to pack at runtime an atlas containing only the images you currently need for rendering, ensuring they all fit on a single atlas page and therefore require only a single draw call.
Once you get past that, the Spine Runtimes API allows you to configure a skeleton with any attachment you want.
Could you explain this point a bit better? What pluses and minuses of this method?
Thank you forward!
BoeC yazdıBut, in the wors case we will have to load 6 atlases. Is it problem for mobile devices or not? Is 6 atlases in separate scene of the game big number or not?
It depends on the mobile device of course, but 6 atlas pages is likely fine. Keep in mind 4096 x 4096 is 16M+ pixels * 4 bytes each for uncompressed RGBA = that one texture will take 64MB of GPU memory.
BoeC yazdıCould you explain this point a bit better? What pluses and minuses of this method?
The only downside is it is complicated to implement. You need to determine what images you'll need, including any image swaps. This might include considering what equipment a character has equipped, what enemies are on the current level, etc. Then you need to pack images at runtime. Bin packing is NP hard, so you are just looking for something that is good and fast enough.