Repeating Sprite In Atlas

[nindim]

Hi,

Is there any functionality I haven't found to create a repeating sprite while also using a texture atlas?

Making the sprite double the width would work in the same way as having the texture co-ords go from 0-2 on the X-axis and having the texture set to repeat mode.

I think the only way this could be achieved is by creating multiple quads with individual vertices and UVs and texture mapping from 0-1 for each quad, or 0 to something less than 1 if the size wasn't an exact multiple (an option to have the Uvs all stretch/squash a little to mantain the full sprite on each quad even though the aspect ratio isn't quite right would be nice as well. I recently did this for the edge mesh on a terrain editor and it worked very well.

So, does this already exist in 2D Toolkit? If not, I think it would make a great new feature.

Thanks,

Niall

[unikronsoftware]

Isn't that what the tiled sprite does?

[nindim]

Hi,

Yes, I somehow forgot this existed even though I have used it before in my project...   

I have now started using it on a sprite that has a collider specified in the SpriteCollection, unfortunately the collider does not generate in the scene instance, I was expecting it to generate colliders as though I had just placed many of the normal tk2dSprites next to each other.

I am using this for items like railings that act as one way platforms. I had intended to use a single polygon for the collision with the normal facing upwards.

The option to Create a box collider does not seem to do what the manual suggests:

"Create Box Collider - If ticked, a tight fitting box collider will be created around this sprite. You can adjust the collider depth on the collider itself."

When ticking this box, the collider that is being created for my object also includes the transparency around the object, I had expected it to only include the bounds of pixels with an alpha greater than zero.

The box collider not being tight fitting could be  a more general bug, selecting Box Trimmed on the sprite in the sprite collection doesn't actually seem to trim the transparent area away at all for normal sprites.

Let me know if you need more information.

Thanks,

Niall

[unikronsoftware]

When ticking this box, the collider that is being created for my object also includes the transparency around the object, I had expected it to only include the bounds of pixels with an alpha greater than zero.
This is expected behaviour, it doesn't know about the non-zero alpha at that point. If your sprite has already been trimmed it will only generate a box around the geometry there.

The reason you can't use poly colliders is pretty straightforward, we don't clip the geometry at runtime - you'd need to clip arbitrary geometry at runtime to simulate placing multiple sprites next to one another and that is not going to be fast. Secondly, you can tile many many sprites in one go quite easily adding large numbers of polys to the list, it'll have to optimize the generated geometry to run well. If you need this behaviour, I recommend turning off colliders entirely and add it manually / in your own code, it'll be easier and quicker than a generic solution could ever be.

[nindim]

Regarding the restriction on tiled sprites, that's a shame. My use case is only in editor so the speed wouldn't really matter to me. I understand your predicament though. For simple shapes like boxes I can create a script that matches the tiled sprite's geometry bounds with an inset value to ignore the alpha,hopefully I don't get asked to tile anything that requires a more complicated collision polygon.

The trimmed box collider matching the trimmed sprite in the atlas makes sense, I am using linked SpriteColelctions (for NormalMaps) which don't support trimming so the box colider includes my alpha.

It would be great if linked SpriteCollections would use trimming identical to the master collection. For normal maps this would be perfect given that the diffuse and normal maps will have the same bounds. This would potentially save lots of texture space. Not sure how difficult this would be to achieve though, is the master collection's trimming information available to the linked collection at build time?

[unikronsoftware]

Code: [Select]

It would be great if linked SpriteCollections would use trimming identical to the master collection. For normal maps this would be perfect given that the diffuse and normal maps will have the same bounds. This would potentially save lots of texture space. Not sure how difficult this would be to achieve though, is the master collection's trimming information available to the linked collection at build time?
No it isn't, its not really feasible in 32 bit unity - building a 4k atlas usually means its just at the edge of running out of memory and crashing. Some of these things are terribly inefficient in unity

[nindim]

Given that you're talking about memory constraints, I guess you calculate the trimming just in time as you build the sprite collection and its never saved out to the SC prefab?

I was thinking the trim information would be available to simply be referenced when the linked collection was to be built. Saved per sprite in the collection or something... Actually, given that when you instantiate a sprite it includes the empty space outside the render mesh that was trimmed away, this information must exist somewhere?

As an aside, I tend to limit myself to 2048 anyway, 4096 textures aren't supported on all my target platforms at this point.

[unikronsoftware]

Given that you're talking about memory constraints, I guess you calculate the trimming just in time as you build the sprite collection and its never saved out to the SC prefab?

Yes, the cost associated with this is in loading textures and working out all this just in time.

I was thinking the trim information would be available to simply be referenced when the linked collection was to be built. Saved per sprite in the collection or something... Actually, given that when you instantiate a sprite it includes the empty space outside the render mesh that was trimmed away, this information must exist somewhere?

There is bounds information that is stored, but that doesn't say anything about where it came from.

As an aside, I tend to limit myself to 2048 anyway, 4096 textures aren't supported on all my target platforms at this point.

4k atlases are very widely used from what I've seen...

The problem is the underlying architecture doesn't know anything about linked atlases. The ideal way to implement this is to do it in the core, letting the atlas builder know about all linked sprites as it trims and build the atlases truly in parallel. Unfortunately that is a huge, very high risk (in terms of breaking existing functionality) job that isn't justified at this time.

[Trigve]

I'm sorry replying to the old thread, but I think it is better to comment it here than starting a new thread.

I would also really like to have the options to trim the sprites and use the trim "template" in the linked collections.

Could you describe the problems when creating the 4K atlases in more detail? Because I don't get why there should be so high memory usage.

Anyway, is there at least some options to implement this in tk2d? I've done exactly this in another sprite atlas generator and it wasn't very hard and was working good.

I imagine it, like it was describe above, that is when the atlas is generated, the trim information would be saved. Then when linked atlas is being built, the trim information would be passed there and only blind trimming would be done without any computations. I could try to do it myself, but I want to know if it is theoretically possible to not to waste time.

Thank You

[unikronsoftware]

Unity's texture management is not particularly nice. It basically uses a ton of memory and you don't get much control over when its freed, etc. Granted its not as big a problem now that we have 64 bit editors, but it still is a pain. If 4k atlases work for you, go ahead and use em.

The trimming linked collections IS possible, but no information of that sort is shared between collections. You could hack it to support it I suppose - you'd have to store the trim regions and propagate it between the collections. It doable, but is a lot of work though, and if the atlasing system was implemented with this in mind it would have been a lot easier.