[Solved] Runtime sprite generation from texture, Behaviour and Performance

[siroosec]

Hi!
I recently started using 2D Toolkit, and before anything else, I must say it's awesome! Thanks a lot! 

Currently I'm working on a card game, and I came across few issues.
The game is intended for retina iPad has 400 cards. So lots of 2048x2048 atlases will be used for them, and I'm almost certain current devices can't handle that easily and that's just our cards! Since we will have 40 cards in scene which can be of any combination, many atlases may be loaded in ram and vram only for 1 or 2 cards so huge amount of memory will be wasted that just isn't acceptable.

We initially thought we have to use planes for them and load card texture with Resources.Load(). But then we saw tk2dSpriteCollectionData.CreateFromTexture and tk2dBaseSprite.CreateFromTexture< T >. So here are my questions.

1. Is there any way to use 2D Toolkit's atlas generation in runtime? And will it have same performance as collections created in editor?
I think we could salvage the code used in editor atlas generator but that would be a last resort. It's kind of over the edge even as a last resort.
(If yes, I also like to know can I make it async or do it partially in coroutines so I can have a loading screen?)

2. If no, does a sprite have any overhead? I mean which one has better performance? A sprite created by tk2dBaseSprite.CreateFromTexture< T > or simple plane?
(Since we are going to have 40 cards and each one has a separate texture.)

3. If sprite is still better, is using tk2dBaseSprite.CreateFromTexture< T > code to create a method that replaces current sprite component with a new one instead of creating a new GameObject ok? Or it may cause problems?

[jmcguirk]

We happen to also be building a mobile card game using Tk2D

Trying to lump card textures together into a tk2d sprite collection likely isn't the best option (as you've noted) - you'd be loading in the atlas for mostly a single card.

We've gone down the route of an atlas-per card - which ups your draw calls since you won't be able to effectively batch them - but if we're talking about 40 draw extra calls for 40 cards, its probably fine unless you're targetting ancient hardware

It's probably wise to do the atlas generation offline rather than trying to do a .CreateFromTexture at runtime.

[siroosec]

Thanks for the reply!

I don't know why it didn't even come to my mind but it looks like a brilliant idea! Just if card sizes are close to a greater power of 2, very little memory would be wasted and I think its definitely better than  tk2dBaseSprite.CreateFromTexture< T > and simple plane. You used your atlases in one collection right?

But then again I think creating a collection from texture would be a better solution. You can do it in a short load screen (err... I'm still not sure if I can do it async but I think in worst case scenario I can draw 2-3 cards per frame on a texture in a coroutine using Texture2D.SetPixels) and then use tk2dSpriteCollectionData.CreateFromTexture to batch them in a single collection and atlas.

But as I said, it kind of looks like a last resort.

[unikronsoftware]

If you're going to do that, try to avoid SetPixels... its ridiculously slow and synchronous You can get the same result using Render targets - it will be quite a bit faster.  You can pre-allocate your render textures, create a sprite collection from it with the sprites chopped up appropriately. On game load, simply draw into and fill up the pre-allocated slots.

[siroosec]

Yes, that looks even better. I think I'll go with that. Thanks a lot!

But it would be awesome if 2D Toolkit managed the atlas generation in itself one day. Or since render texture needs Unity pro, something like an add-on for 2D Toolkit that could manage it. I think many users can use such thing to significantly improve their performance.

[unikronsoftware]

Yea but thats the point - doing it at runtime without render textures, any alternative method would be very very slow...

[siroosec]

I know. I mean some code in goodies or in another package (since render texture needs pro and 2D Toolkit is supposed to work with free) that handles this issue using render texture. The reason I'm asking this is because I think 2D Toolkit's atlas generation algorithms have matured and you can create a more optimized atlas comparing to some one who doesn't know how atlas generation works.

[mitralone]

Just thinking out loud without seeing your cards. Would it be not possible to generate cards on the fly if certain parts of the cards are shared? If it was regular playing cards, I think just putting the four symbols, the images for the Jack Queen and King would suffice to generate all 52 cards. Oh and a suitable font for numbers.

Sounds interesting to hear how you guys will solve this. 400 cards in a game though, I am curious.

[siroosec]

Unfortunately I don't think we can. Our cards are football cards, and we plan to have about 16 teams. So each card should have a different player's picture, and we have 5 levels of each card. What we currently are trying to do is to bake as much data as we can in a simple PNG (picture, name, team and country), and generate data that can change (Power, level and ability text) with tk2dTextMesh at runtime.

So the main problem is still managing atlases and collections of the baked PNGs. I'm currently going with render texture and it looks fine. (I've simply done some test and it's not fully implemented so I can't say for sure.) But still I can't get rid of the feeling that I'm treading on a dark path !!! 

[unikronsoftware]

I'm pretty sure RTs will work fine in your case. I've wanted to implement this as a core feature more than once, but most of our customers don't have Unity Pro so that makes it a very niche feature.

[siroosec]

I agree. We've got pro license just recently too.
But if I may suggest, it would be awesome if you could implement this functionality in an extra package that can be imported on top of 2D Toolkit. (Maybe make a card for it in road map?  )
Anyway Render Texture and  tk2dSpriteCollectionData.CreateFromTexture worked for me in this case. I'm marking it as solved.

[unikronsoftware]

Added a card to the trello!

[siroosec]

Awesome!

[siroosec]

I just faced another issue which made me return to this topic.
I need to have 3 or 4 atlases in the collection since a lot of mobile devices wont allow textures bigger than 2048x2048.
How can I create a collection with multiple atlases at runtime?

[unikronsoftware]

You can't out of the box, it wasn't an anticipated use case - you can modify CreateFromTexture to deal with it though - basically, you'll have to pass multiple textures, create multiple materials, etc but otherwise straightforward.