DCC addons

Updated July 2026

Dousen lives inside the tools you already use. Each supported application gets a Dousen panel, dock, or shelf that lets you publish work, run pre-export validation, set up assets from your project's naming conventions, and see Perforce file status — all without leaving the app. Six DCCs are covered here: Blender, Maya, 3ds Max, Substance Painter, Substance Designer, and Houdini. Unreal Engine is a seventh, first-class bridge participant with its own page — see Unreal Engine.

What each addon can do

Four of the six — Maya, 3ds Max, Substance Painter, and Substance Designer — are literally built on the same shared PySide6 base class (DousenPanelBase), which is why their Validate and Perforce tabs look and behave identically; only the extra tabs each DCC bolts on differ. Blender uses native bpy panels instead of Qt, and Houdini has no dock at all — it's shelf tools only.

* Blender, Maya, and 3ds Max have no dedicated "Send to Unreal" button — send_to_unreal() exists as a Python function for studio scripts to call, but the panel's actual path to Unreal is Export & Notify: it publishes the same mesh.export/animation.export event, which FAssetSyncManager polls and imports automatically. Substance Painter, Substance Designer, and Houdini expose an explicit button/shelf tool because their export flow doesn't otherwise map to a single mesh file the way a DCC-native scene save does.

Installing and enabling the addons

To get the in-app panel, you only need to:

1. Open Settings → DCC Apps and confirm the executable path for each application. Installed DCCs are auto-discovered, so this is usually already filled in.
2. Launch the application from DousenDesktop's launcher. The Dousen panel, shelf, or menu appears inside it.

On Windows, the installer bundles the addons, so nothing extra is downloaded.

How the addons talk to Dousen

DousenDesktop runs a small local relay (the bridge) on your own machine at 127.0.0.1 port 8766. Addons publish events to the bridge and poll it for incoming events about twice a second. This is the channel that lets one application hand work to another — for example, sending a mesh from Maya to Substance Painter.

Bridge event types

Almost everything the addons do maps to one of six event types:

Each running application announces itself to the bridge when it starts (register) and withdraws when it closes (deregister). That presence handshake is separate from the events above — it's how features like Send to Unreal know which DCCs are currently open, and how a DCC's shelf only shows Send to Painter when Substance Painter is actually registered.

Studio tools can join the bridge exactly like the built-in addons — the full protocol, payload shapes, and a Python example are on the Bridge API page.

Per-task context

When you select a task in DousenDesktop, the active Jira key and changelist are pushed to every running DCC as a task.context event. From then on, everything you publish is tagged with the right task and linked to the right Perforce changelist — you don't have to label exports by hand.

When DousenDesktop launches a DCC while a task is selected, the same context is also passed to the application as environment variables, so the addon picks it up immediately on startup.

Auto-tagging on export (preview)

After a mesh export lands on the bridge, DousenDesktop can run a local, CPU-only computer-vision pass over it — geometry heuristics (poly tier, whether it has UVs, whether it's skinned) plus an optional bundled classifier that guesses an object class and style hint. This runs in DousenDesktop itself, not inside the DCC, so it applies the same way regardless of which addon published the mesh. A review dialog lets you accept or edit the suggested tags before they're stamped on the source asset record. This feature is still rolling out (DOU-219 epic) — treat any auto-tag as a suggestion, not a fact, until it's had more studio mileage.

Blender

The Blender addon adds a Dousen tab to the View3D sidebar (N-panel), built from native bpy panels rather than Qt. The top-level panel holds the always-visible actions; three collapsible sub-panels hold the rest.

Convention tags persist as a JSON scene ID property (dousen_convention_tags) and are stamped as custom properties on every mesh, armature, and empty object before FBX export, which Unreal's importer reads as FBX user-defined properties.

Maya

Maya gets two Dousen surfaces that both auto-load from userSetup.py: a Dousen shelf of native cmds buttons, and a dockable PySide6 panel that opens automatically on startup (and can be reopened from the shelf). Both drive the same underlying export/validation/P4 functions, so they never disagree — the shelf's Validate and Asset buttons are just lighter-weight windows for the same flows the dock's tabs offer.

FBX export goes through MEL's FBXExport* commands with project presets from export_presets.maya applied first (file version, smoothing groups, tangents, triangulation), and FBXExportShowUI forced off so a profile with FBX autoload disabled can't hang the export on Maya's native "load plugin?" prompt. Convention tags persist as one fileInfo entry per tag — Maya's fileInfo mangles quoted strings, so a JSON blob isn't used — and are separately stamped as string attributes on mesh transforms before export. The materials picker persists as a base64-encoded JSON blob in fileInfo (base64 because the assignment is nested, not the flat shape tags get away with).

3ds Max

Like Maya, 3ds Max gets both a native menu/toolbar with lightweight dialogs and a dockable PySide6 panel (via qtmax) built on the same DousenPanelBase family — four macroscripts under the "Dousen" category, auto-registered from a script in Max's scripts/startup/ folder.

Convention tags are stored as a custom file property (rt.fileProperties), and separately appended to every exported node's user-property buffer as dousen_<key>=<value> lines — 3ds Max collapses all of a node's user-defined properties into a single FBX tag (UDP3DSMAX), so the addon writes one block of lines rather than discrete FBX properties the way Blender/Maya do. The dock's Materials tab persists its catalog assignment as JSON in its own file property, same shared picker as the other DCCs.

Substance Painter

The Substance Painter addon is a DousenPanelBase PySide6 dock, auto-loaded from a thin shim in SUBSTANCE_PAINTER_PLUGINS_PATH/startup that bootstraps sys.path and delegates to the real addon package. It shares Validate and Perforce tabs with Maya/3ds Max/Designer, plus its own Export and Tools tabs.

A mesh.export event targeted at Painter (target_app == "substance_painter") either rebakes the currently open project's mesh or creates a new project from it, so a Maya/3ds Max/Houdini artist can hand geometry straight to texturing over the bridge. Convention tags and the materials assignment both live in Painter's own project metadata store (substance_painter.project.Metadata("Dousen")) — tags for validation scoping only, since Painter never produces an FBX to stamp them into.

Substance Designer

The Substance Designer addon is also a DousenPanelBase PySide6 dock, auto-loaded via SD_PLUGINS_PATH's initializeSDPlugin()/uninitializeSDPlugin() hooks. It has Validate, Perforce, Materials, and Export tabs.

A mesh.export event targeted at Designer is stashed (the received path is stored for the artist to reference from the current baking graph) rather than automatically wired into any node. Designer has no native scene metadata store, so both convention tags and the materials assignment are persisted as JSON sidecar files next to the .sbs package — <package>.dousen-tags.json and <package>.dousen-material.json — rather than embedded in the package itself.

Houdini

The Houdini addon is shelf-tool based, with no dock at all — auto-loaded from a 456.py script on HOUDINI_PATH, which Houdini runs on every .hip load; the addon's own initialize() is idempotent (an internal flag skips re-init on repeat loads). All eleven tools live on one Dousen shelf tab.

Houdini has no reliable FBX user-property embedding path, so convention tags are stored on the /obj node's user data (dousen_convention_tags) purely for validation scoping. There's no Set Up Asset UI for Houdini yet, so an untagged scene falls back to inferring its asset type from the saved file path.

Materials & Nanite gating

All six addons expose the same catalog-driven materials picker, backed by one shared, UI-toolkit-agnostic module (dousen.addons._material_picker) that turns the project's material catalog into combo-box choices, declared texture slots/params, and a guessed texture-slot auto-fill. Maya, 3ds Max, and Substance Designer share a literal Qt widget (MaterialPickerWidget) for the UI; Blender, Substance Painter, and Houdini build their own widget around the same primitives. Whichever material a mesh slot / texture set resolves to, its allow Nanite flag is what the Nanite/NonNanite validator category split reads from — see the Nanite / NonNanite gate and how Unreal applies the same flag on import.

Perforce operations inside each DCC

Every addon runs the same shared _p4_ops module underneath — async lock polling, a pre-export lock check, and checkout/sync/revert/add wrappers around p4 (P4Python with a CLI fallback). Button wording differs slightly between the native dialogs (Maya's shelf window, 3ds Max's WinForms dialog) and the shared DousenPanelBase Perforce tab, but they call the exact same functions:

A pre-export lock check also runs automatically as part of every validated export — if a file the export needs to write is locked by someone else, the export is refused before anything happens. Full command reference, stream detection, and changelist association live on the Perforce page.

Validation before export

Blender, Maya, 3ds Max, Substance Painter, and Substance Designer all run the exact same gated flow — one shared engine underneath, not five reimplementations:

• Errors block the export until they're fixed.
• Warnings prompt you to continue or cancel.
• Dousen also checks that the source file isn't locked by someone else in Perforce (see Perforce operations above).
• The active rule set is resolved from your project's compiled naming conventions for the asset's specific type and taxonomy path — an untagged asset only runs the universal (naming) checks, not the full type-specific catalog.
• When an asset has a materials-picker assignment (see Materials & Nanite gating above), its Nanite flag decides whether the Nanite or NonNanite validator category applies — an asset with no assignment yet runs the Nanite-safe set, matching the checks every scene has always run.

Once the checks pass, the asset is published to the bridge and tagged with your active task.

For the full rule reference, how admins configure it, and a worked troubleshooting example, see the Asset validation page.