Foxbrow Texture Pipeline
I built a Substance Painter plugin that exports Foxbrow clothing colorways through labeled buttons and a consistent Second Life texture preset.
The problem
The manual process was simple, repetitive, and easy to get wrong.
For each Foxbrow garment colorway I made a material visible, opened Painter’s export dialog, set the channels and folder, exported, then renamed the files. Six colorways per release meant repeating those steps six times.
The goal was a docked Painter panel: choose a folder once, select a visible color, click that color’s button, and get correctly named files for Second Life.
The process
Each attempt exposed a different part of the real constraint.
- SCOPE
Map the manual workflow
I documented the route from OBJ import and mesh-map baking to material selection and export so the plugin had a clear boundary.
- WRONG APP
Prototype in Substance Designer
A first Python build targeted Designer. The export work actually lived in Painter, which uses a different API. I kept this as future Designer-side work.
- WRONG FORMAT
Try JavaScript and QML
A loose JavaScript file never appeared as a Painter plugin. A QML package registered but did not give me the docked panel I needed.
- BASELINE
Get a minimal Python package to load
Early Python versions failed silently. A package with
__init__.py,plugin.json, and explicit entry points loaded and became the known-good foundation. - API LIMIT
Narrow full automation to per-color export
Painter 9 in this setup did not expose the layer visibility API needed to cycle all six colors. I kept layer switching manual and built a reliable button for each color.
The solution
A small Painter plugin and a repeatable SL Legacy export preset.
The working foxbrow_single plugin docks in Painter, accepts an export folder, and offers Blue, Green, Grey, Orange, Red, and White buttons. I make the matching layer visible and click its button to export the current diffuse map as a consistently named file, such as foxbrow_red_Diffuse.png.
Normal and Specular maps are the same across these colorways, so I export them once per mesh. Painter-specific imports live inside the export action; an unavailable API can then show a readable click-time error instead of preventing the panel from loading.
The outcome
Working plugin, with a clearly defined automation limit.
Painter loads and docks the plugin; I can select a folder and export a visible colorway with one labeled button. The confirmed package structure and export preset can be adapted to later garments. This removes repeated dialog setup and renaming, while the artist still chooses which layer is visible.
Evidence to add: a real screen capture, installation steps, sample output, and a measured manual-versus-plugin comparison.
What I learned
Start from a working baseline and test against the actual application.
The most useful shift was verifying a minimal plugin before adding features. That separated package-loading problems from API limits and let each subsequent build answer one question at a time. Next I can test whether a newer Painter version supports layer switching and add a separate PBR export preset; neither is part of the current release.