It paints PBR texture sets directly on a 3D mesh
ArmorPaint is built around the job that general image editors handle poorly: painting several physically based material channels while seeing the result on the model. Its brushes can affect base color, normal, occlusion, roughness, metallic, height, and opacity. Layers, masks, material nodes, decals, clone and blur tools, color ID selection, and a 2D texture view keep that work inside one project. An artist can save the mesh, materials, brushes, layers, and packed assets in an .arm file.
The import path is wide enough for a working asset pipeline. The manual lists OBJ, FBX, Blend, STL, glTF, and GLB meshes, plus common raster formats, PSD, SVG, TIFF, HDR, and uncompressed EXR images. OBJ files can be split into UDIM tiles, and the mesh panel can recalculate normals, unwrap UVs, apply displacement, or run basic decimate, smooth, subdivide, and bevel modifiers. This is practical repair work, although it does not turn ArmorPaint into a full modeling package.
Export presets write engine-specific channel packs
Texture export supports 8-bit PNG or JPEG and 16-bit or 32-bit EXR. The included presets can write separate PBR maps or pack channels for Unreal, Unity, and Minecraft. Custom JSON presets let a technical artist assign source data to individual RGBA channels. That matters when a studio has its own shader convention, because channel packing can live with the painting project instead of in a separate conversion script. Meshes can leave as OBJ or GLB after UV or geometry edits.
Baking is part of the material graph. ArmorPaint documents ambient occlusion, curvature, lightmaps, bent normals, thickness, normal, height, position, material ID, object ID, and several other bake modes. Some require a ray-tracing GPU. The path-traced viewport also requires supported DirectX or Vulkan ray tracing, Metal on Apple silicon, or an M1-class iOS device. The manual says that renderer favors speed over correctness, a useful warning for anyone treating the viewport as a final reference.
What happened when we ran it
We did not run ArmorPaint at commit 0a125e5. Our sandbox had 3 CPUs and 8 GB of RAM, but the lab harness has no supported C ecosystem and the repository supplies no Dockerfile. That leaves us without an honest install result, build result, test count, dependency audit, or runtime observation. A screenshot or successful release tag would not fill that gap, so this review does not imply hands-on painting or export validation.
The missing run is especially relevant because the README calls the Git checkout developer-focused and potentially unstable. Building on Debian or Ubuntu calls for Clang plus development packages for Vulkan, GTK 3, OpenSSL, X11 input, XRandR, Xcursor, and ALSA. Windows uses Visual Studio with Clang tools; macOS and iOS use Xcode. Android needs Android Studio. The repository includes its own make tooling, yet the compiler and system libraries remain your responsibility.
GPU memory decides which local neural nodes are practical
ArmorPaint processes its neural nodes on the user's machine, and downloaded models can work without an internet connection afterward. The manual lists text-to-image, image editing, image-to-PBR conversion, upscaling, image-to-mesh, and a console model. Their stated memory needs range from 1 GB to 16 GB, while the general recommendation is at least 6 GB of video memory. Hunyuan3D is listed as Windows-only. Local processing is appealing for private assets, but each workstation still needs enough memory for the chosen model.
Those neural tools sit beside ordinary material nodes rather than replacing the painting workflow. Artists can wire generated output into materials, continue painting, and export through the same presets. The main release notes say ArmorLab was merged into ArmorPaint, which explains why generation and painting now share one application. Studios should still review the license and behavior of each downloaded model. The project license covers ArmorPaint's source, not every model or asset a user obtains.
The source is permissive, while official binaries fund development
The repository uses the zlib/libpng license, permitting commercial use, modification, and redistribution while requiring altered source to be marked and the notice retained. The distribution model is unusual but clear: source is available to build, and packaged binaries are paid to fund the work. Developers can compile from Git; artists who want to unpack and run can buy the Windows, Linux, or macOS build. Experimental iOS and Android packages are also documented.
Plugins use a minimal interpreted C variant and can add controls or import and export formats. The manager can create a starter plugin, import .c or .zip packages, and expose scripts inside the application. Live-link plugins for Unreal, Unity, and Blender are described as in development, so they should not be treated as finished integration guarantees. Test the round trip with the engine version and asset conventions used by your team.
Version 1.0 is active, but several workflows still show rough edges
GitHub recorded a push on September 9, 2026, six days after release 26.09 was published as version 1.0. The repository had 4,272 stars and 99 open issues and pull requests when fetched. New reports and patches were still moving on September 10, including a locale-script working-directory bug and its proposed fix. That combination points to active maintenance, though the combined GitHub count is not a count of confirmed bugs.
The open reports are concrete enough to shape a trial. Issue 2111 says 1 px grid snapping accumulates an offset in the 2D view. Issue 2052 reports a Blender project import crash on Linux, while issue 2031 describes OBJ import and painting failures on iOS. Different platforms and versions are involved, so these reports do not prove a universal defect. They do identify the exact tests to run before moving a production asset library into ArmorPaint.