Laigter: automatic sprite lighting maps on Linux, Windows, and macOS

Laigter's sprite lighting problem

Laigter targets the preparation of 2D sprites for dynamic lighting in games. Sprites are often visually complete before a renderer needs normal, parallax, specular, or occlusion information for lighting. Hand-authoring each supporting texture adds work and can make lighting responses inconsistent across similarly drawn assets. Laigter addresses that gap by generating the maps automatically, then previewing how the selected effect appears in a game-like context.

The project is primarily for 2D game artists, technical artists, and developers who control both source artwork and the game shader that consumes generated textures. Its four supported map types matter because a renderer may interpret height, surface angle, reflectivity, or light occlusion from separate images. The README does not document supported input formats, export naming rules, batch processing, command-line rendering, or integration with a particular engine. Those omissions make the tool easier to understand at a high level, but less useful for evaluating an automated asset pipeline.

Laigter also presents itself as a visual workbench rather than a background service. The repository is a C++ project built through the Qt `laigter.pro` file, and the interface includes preview capability. That points toward an artist selecting or adjusting an effect interactively. The README does not state whether settings can be saved as reusable presets or whether multiple sprites can be processed without opening each one. A studio should not infer either capability from the screenshots.

Laigter's Qt and OpenGL application structure

Based on the repository layout, Laigter separates its interface and application code into `gui/`, its implementation into `src/`, and bundled resources into directories and resource files such as `shaders/`, `styles/`, `images/`, and `translations/`. The root includes `main.cpp`, `main_window.cpp`, `main_window.h`, and `main_window.ui`. This is a desktop application assembled through `laigter.pro`, with shaders and translations registered through `shaders.qrc` and `translations.qrc`.

The README confirms that the preview depends on an OpenGL-capable environment and lists OpenGL development libraries as a Linux prerequisite. It does not expose the underlying algorithm used to derive each map from the input sprite. Consequently, details such as blur radius, height sampling, edge handling, channel packing, and export color depth cannot be confirmed from the README. The supported description is functional: Laigter accepts a sprite-oriented workflow, generates several lighting-related map types, and previews their appearance.

The separate `thirdparty/` directory indicates bundled third-party components, but the README does not identify them or explain their versions. That matters for both upgrades and release engineering. Likewise, the C++ and Qt source does not prove compatibility with Qt 6. The documented requirement is Qt 5.14 or above, while the Windows instructions specifically describe a Qt 5.14 and MinGW setup.

Building Laigter from the Linux master branch

The README presents two acquisition routes: a prepared download from itch.io or the GitHub Releases page, and compilation from the repository. For an initial source build on Debian or Ubuntu, install the packages named by the project. The command installs Qt 5 and OpenGL development support, although distribution repositories may no longer provide every package in the documented form.

sudo apt install qt5-default qt5-qmake libgl1-mesa-dev

After installing the prerequisites, clone `master` and enter its directory:

git clone https://github.com/azagaya/laigter
cd laigter

Create an out-of-source build directory, generate Makefiles with `qmake`, and compile in parallel using the processor count exposed by `nproc`:

mkdir build
cd build
qmake ../
make -j$(nproc)

The README does not give the resulting executable path or a command-line invocation. Qt Creator offers another documented path: open `laigter.pro`, then build or debug it. For a first real use, start the built application, load a suitable sprite through the graphical interface, generate one of the documented map types, inspect the effect preview, and export the result. Laigter is documented as detecting the computer language automatically among its listed translations.

For Fedora, the documented package command is:

sudo dnf install qt5-devel mesa-libGL-devel

On Arch Linux or Manjaro, it is:

sudo pacman -Sy qt5-base

The Arch command refreshes the package database and does not explicitly include OpenGL development packages. Teams should therefore treat the README as an authoritative but incomplete platform recipe rather than assume every dependency is covered.

Windows and macOS build constraints for Laigter

The Windows instructions require Qt Creator and a MinGW toolchain. The README specifically recommends the online Qt installer, Qt 5.14.0 with MinGW 7.3.0, and either the 64-bit or 32-bit MinGW toolchain rather than MSVC. Only one architecture should be present in the system path, according to the documentation. The same clone command used on Linux retrieves the project:

git clone https://github.com/azagaya/laigter

After cloning, open the project in Qt Creator and run it. The README provides no command-line compilation recipe for Windows. It does provide a `windeployqt` example for assembling a deployment directory from a specific Qt 5.14 MinGW build path. That path is tied to an existing local build and must be adjusted to the directory produced on the reader's system.

For macOS, the README says installation is similar to Linux and recommends the Qt online installer. It repeats the same repository clone command, but its macOS section does not include the later build or dependency commands. The exact macOS prerequisites, compiler choice, generated executable location, and deployment process are therefore not documented and should not be inferred from the Linux instructions.

Prepared binaries may avoid source-build friction because the project provides downloads through itch.io and GitHub Releases. The README does not state which operating systems or architectures those downloads cover, nor does it publish checksums. A reproducible build would therefore need separate verification on the intended platform.

Generated maps versus artist-controlled textures

Laigter's practical alternative is a manual texture-painting workflow in an image editor or a custom in-engine shader system. The distinction is control. A conventional pipeline lets an artist choose exact height fields, painted highlights, occlusion shapes, and channel assignments for each texture. Laigter instead derives several lighting maps from a sprite and provides a preview of the resulting effect. That can reduce repetitive preparation when source sprites share a compatible visual structure.

The wrong choice is not obvious for every asset. A character portrait, interface icon, or highly stylized tile may depend on precise painted surface information. Automatic generation can also turn weak or ambiguous source height cues into a lighting map that follows the wrong shapes. The README does not describe manual map import, map painting, masking controls, resolution limits, or per-layer settings, so it cannot be confirmed whether Laigter supports a hybrid workflow.

A custom shader is a different alternative because it performs no intermediate map export. It can calculate lighting directly from sprite channels or procedural values at render time. Laigter creates reusable texture assets and lets the artist inspect the result before entering the engine. The choice therefore depends on pipeline shape: use Laigter for prepared texture maps, or keep calculation inside a shader when effects need per-frame control that exported maps cannot represent.

Laigter release activity and GPL upgrade cost

The repository is not archived, and its last push was on 2026-10-05. Recent tagged releases include `v1.14.0` on 2026-08-07, `v1.13.1` on 2025-12-16, and `v1.13.0` on 2025-11-12. Those dates show recent repository activity and release work. The README does not provide a changelog, migration guide, supported Qt matrix, or release policy, so upgrade scope cannot be predicted from the version numbers alone.

Laigter is identified under the GPL-3.0 license. Projects that distribute Laigter binaries or incorporate its source must review the actual `LICENSE` and determine which source, notice, and distribution obligations apply to their distribution model. The README does not provide legal guidance or explain how obligations differ between an unmodified binary and a modified or linked work.

For teams, the clearest upgrade cost is build validation. Laigter is centered on Qt 5.14 and a qmake project file, while the README includes older distribution commands and a fixed MinGW example. A change to Qt version, compiler, OpenGL driver, or bundled dependency could affect local builds. The repository has recent activity, but the absence of documented compatibility targets means adoption should be tied to a verified local build and a chosen release rather than the `master` branch.

Editorial conclusion

Adopt Laigter when a game project needs generated lighting maps and previewable sprite effects, especially if its Qt 5 build fits the team toolchain. Do not assume it replaces an artist-authored texture pipeline or that its source build remains compatible with current Qt distributions. Before adoption, verify GPL-3.0 distribution requirements, reproduce the build on the target operating system, and check generated maps against the engine's texture expectations.

Frequently asked questions

Official sources

1. azagaya/laigter on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases