Yes, sheet got real.
Exactly, there are many advantages of this approach:
- No additional software,
- Any image type Blender can handle (including those that might be introduced in future),
- Cross platform,
- Rendering animation directly to spritesheet,
And all that within familiar environment of Blender's Image Viewer.
There is one result of this approach that might be undesirable:
- All images must be loaded to Blender. It means they will be loaded as datablocks and accessible from within the Image Viewer. They are treated as an "empty users" - they won't be saved with the .blend file (unless of course you mark them to be saved as "fake users" or actually use them somewhere).
You can - anything that produces rendered image inside Blender can be used to render animation directly to spritesheet. In any other case you can still use image files to create a spritesheet.
It might happen if you mix 8-bit/channel images with 10, 12, 16, 32-bit/channel images. This is current limitation to how Blender handles 8-bit images. There is working solution to the issue, but I decided to not include it (as a marginal case and couple downsides that come with it). It boils down to gamma curve color transformation and I'm not sure if this is a feature or a subject to future Blender API changes.
In any case - if you find your mixed sprites shifted in color - just convert images to similar bit-per-channel format before appending to the spritesheet.
Just make sure you use render output format that has alpha channel even if you don't save any images yourself. The format you pick will be used to transport images to spritesheet.
Well, in any case it is advised to save render to image files even if you render out directly to spritesheet, however all frames are stored independently in Blender's temporary folder (see Blender's User Preferences -> File -> Temp). You can simply use images stored there.
Whatever you save it to be - spritesheet is a native Blender image, just hit F3, pick your format and save.
There is an option to resize images on load to fit the reference image (first loaded image). Simply put: if you have reference image of size 64x64 and one or more images of different sizes - they will be resized to 64x64 to match the template and appended to spritesheet.
Tile size will be calculated from first loaded image, which is treated as a reference for all pending images - if other images fit the size of reference image, they will be loaded, if not - see next question.
Spritesheet is grid-based (columns by rows) with constant tile size per sprite. It means that if you have for example four images of size 64x64, spritesheet will calculate its size to fit all of them in the best manner - in this case it would take shape of size 2x2 sprites (128x128 pixel size). Of course this is just starting point - you can change the number of columns and rows, append more images etc.
Anything Blender can handle - another advantage of using Blender's native functionality. If you can load an image to Blender - you can make a spritesheet out of it.
All you need is Blender and this addon. It uses only Blender's native functions for image processing.