Overview

ArmorPaint extends one project model through three surfaces—native importers, script plugins, and project scripts—and through alternate consumers such as path tracing and baking. Importers translate external data into project assets or meshes; scripts participate in UI, update, deletion, or project behavior; path tracing builds flattened inputs, acceleration structures, and accumulated frames; baking computes maps and copies results into paint targets. Reuse avoids a second authoring model, but extensions inherit lifecycle, trust, platform, resource, and compatibility conditions, and the repository does not establish a general script sandbox or universal format support.

Learning outcomes

Native importers, script plugins, and project scripts are distinct extension surfaces with different ownership, lifecycle, and trust relationships.
Path tracing reuses project meaning but builds its own flattened inputs, acceleration structures, sampling state, and accumulation.
Baking rejoins the project when its computed result is copied into a paint target, where layers, history, materials, and export can use it.

Keywords

ArmorPaintExtensionsPluginsScriptingBakingRenderers

Extending the Pipeline and Changing the Renderer

ArmorPaint’s file boundary exposes a natural extension question: if new importers, scripts, or renderers consume the same project state, how can they add capability without creating a second project model? This chapter compares native importer extensions, script hooks, path-traced rendering, and baking. The practical goal is to identify what each mechanism reuses, what new contract it adds, and which platform or resource limits should temper expectations.

The common thread is reuse. Extensions attach to assets, objects, materials, context, or update callbacks that already exist. Alternative renderers consume layers, meshes, environments, and generated material behavior that the raster editor already uses. That reuse is powerful, but it also means each extension inherits the lifecycle and boundaries of the core application.

Three extension surfaces, three responsibilities

A compiled plugin is closest to the asset boundary. The retained plugin code registers texture importers, mesh importers, mesh processing, and UV unwrapping. When ArmorPaint encounters an extension it does not handle through a built-in path, it can enable a plugin and ask that plugin to return data in a form the project understands. The plugin’s responsibility is to translate an external representation into an asset, mesh, or processing result; it does not own the whole editor lifecycle.

A script plugin is different. ArmorPaint loads a plugin script through the embedded Minic interpreter, stores its execution context, and lets the script register UI, update, and deletion callbacks. The core calls update callbacks from its update cycle, UI callbacks from the plugin tab, and cleanup callbacks when the plugin is stopped. The script therefore participates in the application lifecycle rather than merely returning a parsed file.

Project scripts form a third surface. They can access selected project, context, object, material, stage, timer, and update functionality. Their purpose is to automate or customize a project’s behavior using the same state the editor uses. A script can change a stage, find an object or material, schedule work, or participate in painting-related operations. It is not the same as a compiled importer or a persistent UI plugin: it is attached to project behavior and its assumptions travel with that project or workflow.

The distinction is useful because “plugin support” is too broad a phrase to guide a decision. If the problem is reading an external mesh, a compiled importer boundary is relevant. If the problem is adding a recurring UI action, script callbacks may be the better fit. If the problem is automating a particular scene or project, project scripting can operate closer to the project model. Each surface has a different owner, lifecycle, and trust relationship.

Published by DeepMox

FAQ

Which ArmorPaint extension fits an external file, UI action, or project automation?

A native importer fits external file translation, a script plugin fits recurring UI or update callbacks, and a project script fits automation tied to project state.

How does ArmorPaint path tracing reuse the project model?

It reuses layers, materials, mesh transforms, environment data, and live-layer concepts, then builds flattened inputs, acceleration structures, and accumulated frames for ray-traced rendering.

Where does an ArmorPaint bake result go?

A bake result is copied into a paint target, after which layers, materials, history, masks, and export can treat it as ordinary project data.

Previous10 minArmorPaint Project Files and Exports

Next11 minArmorPaint Architecture: Leverage and Costs

ArmorPaint Extensions and Alternate Renderers

Extending the Pipeline and Changing the Renderer

Three extension surfaces, three responsibilities

FAQ