Highly configurable texture packer.
Packing many random images with random size
into one single image
The TXPK has a very large and complex command line interface to configure many properties. I don't advise using it, but if you want to, here is a more detailed version how the CLI can be used.
The easiest way to use the TXPK is to let it generate a project file. This can be done via the command line:
>txpk.exe -g
This will generate a default .txpk
project file which is nothing more than a .json
file and looks like this:
{
"recursiveFiles" : false,
"inputDirectory" : "",
"inputRegex" : ".+((.png)|(.jpg)|(.jpeg))$",
"scriptDirectory" : "",
"outputImageDirectory" : "",
"outputDataDirectory" : "",
"outputName" : "txpk_export",
"outputImageFormat" : "png",
"packingAlgorithm" : "Default",
"dataExportAlgorithms" : [
"Default"
],
"keyConversionAlgorithm" : "Default",
"allowRotation" : false,
"sizeConstraint" : 0,
"constraintType" : 0,
"clearColor" : "0",
"trimImages" : false,
"replaceSameTextures" : false
}
The project file has the same properties as the CLI. But is easier to use.
You can use the CLI to load the project: >txpk.exe -p"path/to/project.txpk"
The first CLI argument is implemented as a positional argument for the project.
This allows you to just write: >txpk.exe "path/to/project.txpk"
.
Or you can just drop the project file onto the txpk.exe
file.
recursiveFiles
: whether the images should be searched recursively in the input directory or not.inputDirectory
: the directory where to search the images.inputRegex
: the regular expression to filter you images. You could actually allow every file (even non image files). The TXPK will report errors while loading.scriptDirectory
: the directory where the TXPK will look for any Lua script files.outputImageDirectory
: the directory where to put the packed resulting image.outputDataDirectory
: the directory where to put any data file which are generated by data export algorithms.outputName
: the name all data files will have.outputImageFormat
: the format in which the resulting packed image will be saved as. Currently only.png
,.jpg
/.jpeg
are supported.packingAlgorithm
: the algorithm to pack the input textures with. You can use the CLI to learn more about which packing algorithms are supported:>txpk.exe -h
. In the current version there are only two different packersSameSize
andBlackspawn
(named after and inspired by jimscott).Default
is theBlackspawn
packer. The detailed explanation for each packing algorithm can be found here.dataExportAlgorithms
: none or more algorithms which can export data related to the packing process.Default
exporter is theJson
exporter, which exports the positions and sizes of the textures. Detailed explanation of any exporter can be found here.keyConversionAlgorithm
: algorithm which converts the path/name of the texture to a key.Default
is theFileWithoutExt
converter which returns only the file name without extension. Detailed explanation of any key converter can be found here.allowRotation
: whether the packing algorithm is allowed to rotate images or not. Visualized here.sizeConstraint
: constrains the size of either width or height of the packed image.constraintType
:None=0
,Width=1
,Height=2
. ThesizeConstraint
will be ignored if the type isNone
.clearColor
: the color to clear the resulting image with. Default is 0 (transparent black) which could also be written as00000000
or0x00000000
. This number should represent a hexadecimal number.ff0000ff
would clear the packed image with red.trimImages
: if this option is enabled, any excess transparency will be cut at the texture borders. Visualized here.replaceSameTextures
: this option removes every redundant image. This will be done after trimming the textures and can result in a smaller packed texture. Let's say you have an animation of a ball jumping up and down. There are probably some frames where the ball is slightly below the ball one frame earlier. After trimming they are mostly all on the same level, so it's the same texture, so they will all be replaced with one. An example can be found here.
The ox
is the offset in x direction. This is a result of the source texture being trimmed on the left side. Same with the oy
being the offset in y direction. The sw
(source width) and sh
(source height) are there so you can do stuff like moving the origin of the source texture to the center which would be impossible without knowing how large the texture was before.
This data is hold by any texture. The texture still has the current x
, y
, width
and height
. These are the four you need to crop the image. The data can be exported by any exporter and for example the JsonExporter does exactly that.
This gif
shows exactly whats happening when an image gets rotated. It gets rotated by 90° counter clockwise. If you wanted to crop and load the texture you had to rotate it back 90° clockwise. If not changed, the rotation point is by default in the upper left corner. So when importing the texture you have to rotate it and have to adjust the position because the rotation point is different. You can look at the example for more insight.
Please have a look at the example.
The LuaExporter is able to load lua scripts so you can define custom exporters. More about the small scripting API can be found here and an example implementation can be found here. If you have created a valid lua script file you can add the file name without extension as an exporter in your project file. See the example for more insights.
Ok let's assume you have these 64x64 images with a lot of unnecessary transparency:
And you just want them to be packed in that order without trimming, rotating, replacing or whatever. You can use the following project file:
{
"recursiveFiles": false,
"inputDirectory": "",
"inputRegex": ".+(.png)$",
"scriptDirectory": "",
"outputImageDirectory": "",
"outputDataDirectory": "",
"outputName": "sgb",
"outputImageFormat": "png",
"packingAlgorithm": "SameSize",
"dataExportAlgorithms": [ ],
"keyConversionAlgorithm": "",
"allowRotation": false,
"sizeConstraint": 0,
"constraintType": 0,
"clearColor": "0",
"trimImages": false,
"replaceSameTextures": false
}
Notice how inputDirectory
and outputImageDirectory
are not set. This can only work if the project file is in the same directory.
Also notice the SameSize
packing algorithm.
This project outputs a sgb.png
in the same directory which looks like this:
- Catch2 used for unit testing.
- dirent used for cross platform directory access.
- stb_image used for reading and writing images.
- json used for reading json files.
- Lua used for the Lua API.
This project uses CMake to generate platform and compiler-specific build files. Also note that this project uses C++14
features
such as auto
and lambdas
and therefore requires a C++14
compliant compiler in order to build successfully.
- Clone the repository (and submodules)
git clone --recurse-submodules -j8 https://github.com/Seng3694/TXPK
- Generate the build files
With Visual Studio 2017 you could for example use "Visual Studio 15" or "Visual Studio 15 Win64" generators.
mkdir bin cd bin cmake -G "Your Generator" ../TXPK
- Build the files
cmake --build . --config Release
Alternatively if you have python installed, you could just execute the build.py
file in the root directory.
If you want to build the tests you can pass cmake
the -DBUILD_TXPK_TESTS=ON
argument.
If you want to build the example which is dependant on SFML 2.5 you need to pass cmake
the -DBUILD_TXPK_EXAMPLE=ON
and -DSFML_DIR=PATH/TO/SFML
.
Example for building everything:
cmake -G "Your Generator" -DBUILD_TXPK_TESTS=ON -DBUILD_TXPK_EXAMPLE=ON -DSFML_DIR="C:/Program Files/SFML/lib/cmake/SFML" ../TXPK
This software is licensed under the MIT License. See LICENSE for more information.