From Intent to Pixels: The First Working Mental Model

ArmorPaint can now be viewed as three connected layers of responsibility: the project model gives an edit meaning, the runtime loop decides when that meaning changes, and the platform/render layer turns it into a frame. This checkpoint connects those ideas through one surface-edit scenario. The useful result is not a recap of earlier definitions; it is a way to decide which representation should change, which owner should trigger it, and why the same edit cannot be reduced to one bitmap.

Imagine a user selecting one mesh object and assigning a worn material to a visible layer. The user’s intent is simple, but ArmorPaint must preserve several facts: which object receives the layer, which material graph supplies its values, which PBR channels are active, how the layer blends with neighboring layers, and which camera and viewport should display the result. The edit becomes useful only when those facts survive the transitions from editor state to runtime state and from runtime state to GPU-visible state.

One edit crosses several owners

The first owner is the project model. It gives the edit durable meaning: a material slot holds a node canvas, a layer refers to that material, the layer carries channel targets and visibility/blending properties, and an object or UV context determines where the result belongs. The project model does not yet decide when to redraw or which graphics API to call. It answers a more basic question: what has the user actually asked the application to preserve?

The second owner is the runtime context and update loop. It knows which material, layer, object, tool, and viewport are active. When the material or layer changes, the update path can mark the affected derived state and schedule work at a safe frame boundary. The runtime does not replace the project meaning; it turns a change in meaning into an ordered set of work. That distinction prevents a UI event from directly mutating every GPU resource in an uncontrolled order.

The third owner is the render path. It consumes the active project and context, selects the appropriate targets, and produces the visible surface. The raster path may first establish geometric information, then evaluate channels and lighting. A forward or deferred choice changes the route through those operations, but not the user’s underlying request to apply the material to the object. The render path is where project meaning becomes an image for the current camera.

The fourth owner is the platform layer. It receives shared requests for textures, pipelines, shaders, buffers, and presentation, then translates them into the target API’s resources and synchronization rules. The platform layer does not decide that the material means “worn” or that the layer belongs to a particular object. It makes the render work legal and executable on the selected target.