sorry, i'm the author of the named packer, but it's not working. because the packer changes the order of the sprites and doesn't retain information about how that order is changed, i had to go in and add fields to a lot of intermediate data types, which really messes with the original architecture but works for my purposes. i basically attached the file name to every intermediate data type. you can look at my quick and dirty changes here.

i didn't want to open a pull request yet, since, like i said, it's pretty dirty and pokes some holes in the original architecture. i just wanted to get some thoughts on how to change this approach so it could work.

First, thanks for publishing sheep! It was heartening to see other people working on asset pipeline tooling for games in Rust.

In a tool my team is working on, we need to pack images into square power-of-two textures for some devices, preferring to waste a little space to get a square image instead of a perfectly packed non-square image.

When using Sheep's Max Rects packer with five 128x128 textures and a max size of 1024x1024, it produces a 128x640 texture like this:

We'd prefer that it instead produce a 512x512 square texture with wasted space. On some platforms, would have to expand a 128x640 texture into a 1024x1024 texture, which is more wasteful!

We've found some other tools that mention the problem of PO2 textures with maxrects, but I'm not familiar enough with packing algorithms to know if it's feasible to enforce exactly.

Currently, AmethystNamedFormat takes extra options in the form Vec<String>. This is suboptimal since it requires moving the whole container and cloning it if it needs to be reused. Instead it could be &[String], or even &[S] with AmethystNamedFormat<S> where S: Deref<Target=str>.

I'm happy to write up a PR for this if people think it's a good idea.

When finding an anchor corresponding to a sprite in pack(), program iterates over all anchors for each sprite. I assume that it's for maintaining sprite order (but they could be still in different sheets, right? so why does it matter if they are sorted?). O(n^2) can be reduced to O(n) with a hashmap of anchors, but maybe I'm missing some context why it was done the way it is.

Atm arguments order doesn't match the output sprites order, so changing assets or adding new ones breaks all sprite ids.

Not much else to say. Here's a result from packing a font signed distance field:

I've tested this with what's on https://crates.io, and what's currently in the repo.

error: cannot find derive macro Serialize in this scope
--> sheep/src/format/named.rs:8:35
|
8 | #[derive(Clone, Debug, PartialEq, Serialize)]

I think it's an important feature is to keep a hash of the input data and options somewhere in the output folder in order to do nothing in case nothing changed since the last time the packer ran so you can call sheep painlessly on your game startup.

The README says to run the CLI like this:

sheep pack --options max_width=1024 max_height=1024 sprites/*.png

I tried it and it did not work. Adding the options after works:

sheep pack sprites/*.png --options max_width=1024 max_height=1024

I think the options might get interpreted as files?

Issue

When I specify the input files using globbing, sheep-cli crashes with

thread 'main' panicked at ' Failed to open image: IOError(Os { code: 123, kind: Other, message: "The filename, directory name, or volume label syntax is incorrect." })

I looked into it and found out that this is due to Windows not expanding input arguments using globbing.

Possible Fix

Use glob crate to expand inputs with globbing.

It just says:

Copyright [yyyy] [name of copyright owner]

As mentioned in #12, it would be great to have some sort of image compression/optimization for the output, comparable to pngquant. For rust, interesting options for this would include oxipng and mtpng.

We should think about whether or not it makes sense to add this functionality to the library itself, since this is probably something that - when people integrate the library into their own asset pipeline - would be replaced by existing asset processing infrastructure.
Having this option available in the CLI definitely sounds like a good idea to me, though.

using the default CLI packer, i couldn't pack all my assets (just as a test). turns out it was failing a binary search because the Sprite Anchors weren't sorted. however, fixing that bug revealed another bug where the sprites were packed on top of another. example

https://www.codeandweb.com/texturepacker
has a plethora of features that'd be useful

• pngquant compressor export option
• trim transparent borders
• detecting identical sprites and aliasing them in the ron file

texturepacker also has a custom exporter to template output files, so someone could try to make one for a .ron file. Only have 30 days to use a good amount of the features though so glad sheep is in the making.

0.15 now requires a List(()) to surround the ron file. Example: https://github.com/amethyst/amethyst-starter-2d/pull/14/files#diff-ee91fa974052bd6353c9077e79d522eb

From the changelog for 0.14:

Changed SpriteSheetFormat::import_simple to allow importing grid based SpriteSheets (#2023)
Migration Note: Rons need to wrap their content in either Grid() or List()

Error:

[ERROR][amethyst_assets::storage] "renderer::SpriteSheet": Asset "textures/spritesheet.ron" (handle id: Handle { id: 0 }) could not be loaded: Failed to load asset with name "textures/spritesheet.ron"
[ERROR][amethyst_assets::progress] Error loading handle 0, renderer::SpriteSheet, with name textures/spritesheet.ron: Failed to load asset with name "textures/spritesheet.ron"
caused by: Failed to load asset with name "textures/spritesheet.ron"
Error { inner: Inner { source: Some(Error { inner: Inner { source: Some(Error { inner: Inner { source: None, backtrace: None, error: LoadSpritesheetError(Parser(ExpectedIdentifier, Position { col: 1, line: 1 })) } }), backtrace: None, error: Format("SPRITE_SHEET") } }), backtrace: None, error: Asset("textures/spritesheet.ron") } }
caused by: Format "SPRITE_SHEET" could not load asset
Error { inner: Inner { source: Some(Error { inner: Inner { source: None, backtrace: None, error: LoadSpritesheetError(Parser(ExpectedIdentifier, Position { col: 1, line: 1 })) } }), backtrace: None, error: Format("SPRITE_SHEET") } }
caused by: Failed to parse SpriteSheet
Error { inner: Inner { source: None, backtrace: None, error: LoadSpritesheetError(Parser(ExpectedIdentifier, Position { col: 1, line: 1 })) } }

$ sheep --version
sheep 0.3.0

My texture atlas looks like this in some cases

Probably it's due to I'm using too big textures(I will write here when I resize them).

I've read about skyline heuristics given in 2011 and 2016 works and they both work by trying to achieve as low height as possible given a width of a spritesheet.

1. I'm not sure how to adopt this to output multiple spritesheets, since their approach relies heavily on being able to shuffle the input. One possible approach is trying to fit it into one spritesheet, then if it fails, splitting the input randomly into two parts and trying to fit it into two spritesheets and so on. I'm not sure this is an optimal approach and would like to hear your thoughts.

2. I'm not sure how to choose the width of a spritesheet, I don't really like maxrects approach of giving it a default value since in it will just produce a long horizontal stripe of sprites and that doesn't feel optimal (maybe it's really efficient or doesn't make a difference at all, I don't know). So I propose to make some kind of algorithm on top of skyline (and maybe maxrects too) that tries to determine optimal width and height. Again, I'd like to hear your thoughts.

in texturepacker(codeandweb), duplicate sprites are not duplicated in the resulting image but only the data file(ron, json, etc).