SpriteAtlas custom packer

Hi there,

I would really like to see custom atlas packer support in this feature set. It will come the time where the default packer is not equipped for special needs or optimizations.
A field/dropdown in the SpriteAtlas inspector could reference the used sprite packer. It is essential that a custom packer can be selected per atlas. The packer has to receive as much information as possible.

The current system offers custom packers through the UnityEditor.Sprites.IPackerPolicy but in my opinion it is very limited. You could not define custom packing modes, only use the two defined in UnityEngine.SpritePackingMode.

Two workflows that can emerge from a custom packer:

  • We wanted to have blurred background and foreground textures in our game. A blur shader was too much overhead because we are targeting mobile. We could of course just blurred the source texture and throw it on the atlas. But the workflow is not good because it is destructive and modifies the source texture information. So we integrated our blur in the atlas process. When a texture is about to be written onto an atlas we blur it and throw the blurred texture onto the atlas. Now we have unmodified source textures but static blurred textures in our game. The artists also could just tweak the blur values and rebuild the atlas to see the result. For this process to work the custom packer must know the Pixels of a texture and also must be able to modify the space the texture needs on the atlas.
  • We also wanted our bitmap fonts to be build within Unity. For the Asian languages we packed each glyph in a separate color channel. Of course you can do this with tools like BMFont but it would be nice to have the hole thing in one nice environment called Unity ;).

Thank you for listening.

Best regards,


1 Like

Interesting, i'd like to hear more ideas...

For #1, we could be doing some sort of post process.

But we need more use cases to justify opening up for actually letting users write algorithm to move data around. We have some features coming up in the near future where managed access to native memory will be much easier therefore more APIs will be exposed with that. But it's always a very carefully considered kind of thing. I would also like to see more demand for this.

Thanks for sharing though.. much appreciated.

I have a use-case for post-processing the atlas after it's created. I use a custom shader for my sprites so that I can do palette swapping, but it requires me to modify the textures. It would be convenient if I could just do it when the atlas is created so that I can leave my source textures alone.

So I don't actually need a custom packer... I just want to to modify the atlas texture after it's created.

Agreed on the post processing, we had some special sauce compression (basically packed the alpha channel, so could DXT1 instead of DXT5).

We had the same thing as mentioned above to packed blurred versions of textures. Some API support would be good but you can do it already currently I think by just caching those blurred versions to the project folder and then packing them

Other feature request is to allow packing at a different resolution than import resolution. We encourage artists to paint assets large enough for anything but have a system to determine the exact resolution we need textures at.

Very cool, let us explore this.

This is coming in Preview3 under the Atlas Variant feature. Basically, you tell a variant atlas to get the list of sprites from a master atlas and then you can tweak its parameters (resolution, filters, mipmaps etc).

It's not just packing the atlas at a different resolution though! We determine the best size to pack each sprite (by analysing the max screen size a sprite is actually used at). Determining the best size is game specific but it definitely isn't always the size at import.

Anyway these features sound great already! Will take a look at the post process once that's there. Thanks!

This is coming in Preview3 under the Atlas Variant feature. Basically, you tell a variant atlas to get the list of sprites from a master atlas and then you can tweak its parameters (resolution, filters, mipmaps etc).

This sounds interesting. I feels like inheritance for different atlas files.

For #1, we could be doing some sort of post process.

Don't overlook that the blurring of the sprites will enlarge the sprites so they need more space on the atlas. This cannot be achieved with a post process process on the finished atlas texture. Some Sprites would overlap when being blurred. This of course depends what kind of padding and blur values are used. The packer needs a way to adjust the sprites dimensions that are fed to the atlas calculation.

Another use case are meshed sprites in skeleton bone based 2D animation. We are heavily using Spine (http://esotericsoftware.com/). In Spine you can define a custom mesh for a sprite . The vertices can then be assigned to bones for ease of bone based 2D animation. The thing is that vertices can be created outside of the texture rect. So If I pack my textures on an atlas without being able to modify the space needed for this texture the vertices could be outside of the atlas texture or inside a neighbor sprite on the atlas. I can provided screenshots if this is not clear.

We can do it too, since Preview 1.

Our packer uses the vertices instead of the alpha values to determine which pixels to include in the packing.

So combining both, if you make a big fat triangle (using the sprite mesh editor) over a tiny circle image, you will get a lot of free space which you can use to blur (if/when we provide the post process hook).

We are working on this. Still at least a few previews away from being able to show anything. But we ARE working on this. For real.

Thank you for your answers :). I will continue to come up with useful workflows including custom atlas packing.

Is this in roadmap?
My current game uses a lot of big sprites and this was generating meshes with a lot of triangles and large transparency areas.
I made a script to split the sprite texture into multiple small boxes of 256 pixels or less.
When I generate an atlas for multiple sprites it organizes the small boxes and have a better texture usage.
It's good but my expectation was that the boxes that had alpha of 100% at the whole box were grouped in a pure RBG page and the corners that had alpha change were in a RGBA page.
It did not happened.
The Sprite Atlas always try to mix filled boxes with corners or refuses to fill the hole image leaving perfectly fittable places for a RGB box empty to keep the page as a RGBA texture.
If I could write a custom Sprite Packer would be nice.