Overview

ArmorPaint’s project model is coordinated state, not a bitmap: mesh objects provide spatial context; materials and brushes hold different graph logic; layers organize visible contributions; masks, channel targets, UV and object choices, and assets preserve how those contributions apply. Separate PBR channels let rendering, history, and export interpret color, opacity, normal, occlusion, roughness, metallic, and height. Keeping these relationships explicit supports live updates and reopening, but costs GPU memory and reconstruction work, while external assets can break completeness.

Learning outcomes

A material graph defines surface values, a brush graph defines interaction, a mesh object supplies spatial context, and an asset gains meaning through its reference.
Layer types, masks, UV and object choices determine where contributions apply, so similar visible colors can represent different editable states.
Separate PBR channel targets keep color, opacity, normal, occlusion, roughness, metallic, and height available to rendering, history, and export.

Keywords

ArmorPaintProjectLayersMaterialsChannelsAssets

The PBR Project Model: Layers, Materials, and Assets

ArmorPaint’s project model answers a practical question: what exactly must the application remember so a surface can be painted, rendered, previewed, saved, and reopened? This chapter examines the relationships among mesh objects, materials, brushes, layers, masks, channel textures, and external assets. The reader’s goal is to stop seeing a project as a stack of images and start seeing it as a set of linked decisions that the renderer and file system can consume.

A mesh is the visible shape, but it does not by itself explain the appearance. A material describes how surface inputs become PBR outputs. A brush describes how an interaction modifies those inputs. Layers determine which contribution is visible, how it is blended, and which object or UV context receives it. Assets supply images, meshes, environments, fonts, or sounds that those decisions can reference. ArmorPaint keeps these roles distinct because their lifecycles are different, even when one user action crosses all of them.

A project is a coordinated state, not a bitmap

At runtime, ArmorPaint keeps a paintable object set, material slots, brush slots, and an ordered layer structure. Material slots are backed by node canvases. Brush slots are backed by logic canvases. The project also tracks assets and mesh relationships. These are not merely labels attached to pixels. They are the editable sources from which the application can rebuild previews, render a viewport, perform an operation, or write a project file.

The distinction becomes clear with a simple surface decision. “Put a worn dark material on this object” could be represented as a fill material assigned to a layer. “Paint a dark mark here with a soft edge” could be an interactive brush operation that writes into a paint layer. Both may change the visible surface, but they have different meanings. The first says the layer is driven by reusable material logic; the second says the layer contains painted data that can be edited directly. If the project flattened both immediately, it would lose the reason the surface looks that way.

Layers therefore carry more than an image. A layer can be visible or hidden, have opacity and blending behavior, target a particular object, use a UV map or projected coordinates, and participate in a group. A mask can limit the layer’s influence. A fill material can make the layer a live consumer of a material slot. A path or decal-style layer can retain information about how content was placed rather than only retaining the final raster result. The layer is the place where these relationships become an ordered surface contribution.

This is why the project model is a bridge between the editor and the renderer. The editor needs named, selectable entities. The renderer needs textures, masks, transforms, and material outputs. The file lifecycle needs enough information to reconstruct both. One model can serve all three, but only if the relationships remain explicit.

Published by DeepMox

FAQ

What does ArmorPaint store in a PBR project besides pixels?

ArmorPaint stores mesh objects, material and brush graphs, layers, masks, channel textures, and asset relationships alongside pixel data, so the surface can be edited and reconstructed.

How are PBR channels represented in ArmorPaint layers?

ArmorPaint keeps color and opacity, normal, and packed occlusion, roughness, metallic, and height targets as coordinated layer data that later stages can interpret.

Why can two ArmorPaint layers with the same visible color behave differently?

They can encode different relationships: painted pixels, a fill material, a mask, an object restriction, or projected coordinates, each of which changes later editing or application.

Previous10 minArmorPaint Across GPUs and Platforms

Next9 minArmorPaint’s Intent-to-Pixels Model

ArmorPaint’s PBR Project Model

The PBR Project Model: Layers, Materials, and Assets

A project is a coordinated state, not a bitmap

FAQ