SpriteCollections is our in house sprite management system for Unity. We developed it for our game as the other options didn’t provide what we wanted. It offers an alternative workflow to SpriteManager2, and concentrates on different aspects of sprite management.
Features
WYSIWYG editing in the viewport. Place your sprites where you need them. They draw correctly in the viewport, and use the atlased sprites.
Full control over sprite atlasing. You decide the textures which go into an atlas.
Fully transparent operation. Once you have set up your atlas, any change to the texture will automatically rebuild the atlas and update the scene. Your game ALWAYS runs with the atlas. This even works while the game is running.
Set up anchor points on each sprite so you can pack your sprites as tightly as possible. We use Inkscape to export PNG, these are always tightly packed, so arbitrary anchor points is a must for animation.
Uses dynamic batching, and has a scale parameter on the sprite so you can scale without breaking batching.
Supports premultiplied alpha, and supports mixing additive and alpha blended sprites simultaneously without breaking batching. The processing is automatic, so you don’t need to premultiply the data yourself.
Tesselation. Large sprites can be diced, and empty bits will be automatically discarded.
There is also support for custom meshes, and though it works, we aren’t intending on supporting this any further unless there is demand. Basically, you can build a 3d mesh, and the system will use that as the sprite and shift the UVs as necessary.
Intelligent padding to avoid seams and ugly edge artefacts. You can override the padding method for different situations. Eg. For stretching a sky, you can select Extend padding.
Almost all operations are cached at build time, so there is almost no overhead at runtime.
Works well on iOS.
There is rudimentary animated sprite support (AnimatedSprite behaviour which plays a looped set of sprites), but we mainly use the Unity animation editor to animate sprite frames, colours and scale.
Pictures
“In game” shot showing tesselated objects, and the atlas. That image on the right is 1024x512. One draw call, 6 batched objects. We can be lazy and draw large objects with huge holes in between, and our system will remove the unnecessary bits.
Some of the source assets and the destination atlas. Once set up, the atlas (re)generation is automatic. Save your source image and switch back to Unity, and everything is updated, as it should be
Atlas set up panel. Anchor can be one of preset 8 corners or center, or a custom value. This shows as a flashing dot in the preview image to help line it up. The dice parameters let you chose how large the default tesselation is… the effect of these settings can be seen in the first screenshot. The sky in the first screenshot is scaled up 10x and there are no artefacts on the edges as the padding is set up correctly in the editor.
Sprite behaviour inspector.
This little side project has been really helpful to us, and we thought it might help other people achieve their visions as well. We are thinking of releasing it in the asset store for $50, if there is any demand for it. Feel free to ask any questions, and any comments are most welcome.
It can render pixel perfect, if the scales are set up correctly. It is currently slightly akward to set that up (as it is dependent on camera) but rest be assured it will be sorted out before release.
You can specify scales on 2 levels, on the actual atlas entry and on the sprite instance. For example, the sky above is scaled up 10x in the atlas entry.
Absolutely. As far as Unity is concerned, it is drawing a custom mesh, so anything goes here. We create a default material depending on whether premultiplied alpha is selected, but you can change that, or even have multiple materials. The built in shaders support vertex colours for tinting and fading out individual sprites. Premultiplied alpha is supported transparently, so if you use that in your shaders, you will need to tick the box.
Sorry, I don’t know what that means. Could you please explain?
If this is to do with Hiero Font Editor, I believe our font system could be modified to work with it with minimal changes, as HFE spits out bmfont .txt files. We use bmfont xml for our font system, and though the font system could source textures from the large atlas, we don’t do that at the moment. Kerning is currently disabled, but we are thinking of having that in as an option per BMTextMesh.
2 draw calls, one for the background and another for the text.
I will look into this sometime soon. It is entirely possible that we can switch to the bmfont text format, which is widely supported by Hiero and also Glyph Designer which both work on mac. We do development on a Windows machine and a Mac so it wouldn’t be a problem for us to test it. However, by design, we aren’t intending on supporting multiple texture pages for text, as it seems like a massive waste of draw calls. I hope to have an answer for you by Monday.
Sorted.
I cope with both text and xml parsing now, so it works correctly with fonts generated through hiero
I am dedicating a few hours a week to improve the toolset further. Next on my list is “drawing” collision bounds from within the interface. Will post again when that is done.
I will keep a very close eye on this one. So far I’ve been unhappy with current implementations and so on. Spritemanager (the free one)'s thread did several tests to see if transforming was faster with gameobjects attached than transforming all verts manually and all that jazz - hows yours peform in similar tests? (my target platform is ios).
Any chance to see what kind of commands and workflow in scripting there would be? Prime’s system is a bit convoluted and difficult to set up.
I haven’t tested if transforming all verts manually is quicker. I don’t generally create THAT many sprites. We do, however, have a separate particle system, which uses the SpriteCollection directly, for large(ish) quantities of particles, without any dynamic allocation. That is entirely pre transformed data, updated every frame. I haven’t got around to benchmarking either, but in our game, this is not a bottleneck at all.
Our primary target is iOS as well, hence the obsession with reducing draw calls.
As far as workflow goes, I believe it is really simple. I will PM a video demonstrating this, but as it is crude and unfinished work, I won’t be releasing it to the public just yet.
What is really lacking is animation, and I have a good idea on what we are going to do with that. However, as we don’t need more than a simple looped animation for our current game, its not particularly high priority for us. For the odd case where we need more than looped animation, we simply use the Unity animation editor to sequence things. This does get rather tedious, so I definitely plan to improve animation workflow in the future.
We can’t really justify spending an immense amount of time improving this, as there hasn’t been a great deal of interest so far. We still plan on releasing it however, as it will just be a by product of building our game.
Well, release that video to the public
Nothing to lose. I find it always important to show some moving pictures, especially when it’s about tools that improve workflow and whatnot. Much better to see and understand in a video than in some screenshots.
Especially the font part is something I haven’t understood entirely.
I find it awesome that all these sprite tools come up as of late - guess you just need to showcase some more to stand out from the crowd
I’d be very interested to get at least a PM with the video !
Disclaimer: These videos are from a work in progress. There are still loads of quirky bits Also, I captured these live and haven’t been sped up at all. So you’ll see my mouse hovering over things while I think of what to do next!
Font workflow video. In addition to BMFont, Hiero files work too. There is reason to the mad number 0.00325, it sets 1:1 pixel ratio to the ortho camera. Obviously that will be sorted out
One cool thing which I don’t show in the video is, once the SpriteCollection is set up, updating any source file will automatically update the SpriteCollection, and update in the scene as well. So effectively, Sprites work like you were dealing with normal Unity textures. No manual rebuild stages, etc.
I will be changing the Anchor set up to be a bit more user friendly at some point. This serves me sufficiently for now.
Also, due to the small window size, I find it slightly hard to pick things in there. It is no different to picking normal Unity meshes with this system.
Wow, the biggest thing of what makes this different from SM2 for me is the auto atlas building, which is something SM2 is annoyingly missing. Thing is, I’ve invested so much time and money into SM2 that I have to use for now
