Messages

1

Support / Region on texture that sprite is extracted from.

« on: January 13, 2014, 10:40:36 am »

Hi!

I'm trying to write a shader based on normal sprite shader, but with addition of another texture to use its alpha to cut out the sprite.
I think it would be quite easy if we know where on texture has the sprite been extracted from. Using a simple math formula in shader, we can calculate uvs on alpha texture using uvs on main texture. But I have 2 questions :

a) Do all sprites have a rectangular extract region on atlas? If not, is there any easy way to get some equivalent?
b) How can I get that region in my sprite class? Since I don't want to keep a reference to collectionData in sprite just to pass its region to the shader.

2

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 26, 2013, 04:45:02 pm »

I got it to work! I found Texture2D.PackTextures that packs all textures in one texture and returns their regions as Rect[]. (It uses a different convention for its Rects compared to what SpriteCollectionData.CreateFromTexture uses but its easy to convert it. Just convert coords from bottom-left based to top-left based and multiply rect variables by texture size.)

Just one problem remains. How can I make my collection to have colliders for its sprites?

3

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 26, 2013, 01:51:57 pm »

I checked the UVs but they were floats so I thought they can't be it. So I suppose I have to multiply the UV numbers to atlas size right?
Also how can I get the right texture when I'm using multiple atlases?

4

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 26, 2013, 01:16:10 pm »

Awesome!

Just one question! How can I find a sprite's corresponding atlas (I'm using multiple atlases) and corresponding area on atlas?

5

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 26, 2013, 10:38:07 am »

By the way something just hit me!
Can I edit an existing collection's atlas textures and expect it to show new atlases properly?
Since all of my sprites are cards with same shape and dimension. So if I replace a single card in the atlas with another and then apply it, its place shouldn't be affected at all.

6

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 26, 2013, 10:28:24 am »

I'll try that! Thanks a lot!

7

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 26, 2013, 09:43:52 am »

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?

8

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 11, 2013, 12:59:22 pm »

Awesome!

9

Support / Re: [Solved] Runtime sprite generation from texture, Behaviour and Performance

« on: September 11, 2013, 08:46:50 am »

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.

10

Support / Re: Runtime sprite generation from texture, Behaviour and Performance

« on: September 10, 2013, 07:28:31 am »

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 !!! 

11

Support / Re: Runtime sprite generation from texture, Behaviour and Performance

« on: September 07, 2013, 10:01:06 am »

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.

12

Support / Re: Runtime sprite generation from texture, Behaviour and Performance

« on: September 07, 2013, 07:40:15 am »

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.

13

Support / Re: Runtime sprite generation from texture, Behaviour and Performance

« on: September 05, 2013, 07:50:33 pm »

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.

14

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

« on: September 05, 2013, 05:23:44 pm »

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?