Asset validation

Updated October 2026

Describes how validators check assets in the DCC before export, how project admins configure the rules, and what each built-in rule checks.

Validators catch problems before the file reaches Perforce or Unreal, such as a name that breaks the convention, a mesh that isn’t watertight, or a vertex skinned to too many bones. The Unreal plugin also checks asset names on import.

Enable and test a rule (project admin)

1. Sign in to the web portal as an Admin. Click Projects, select your project, and click Validators.
2. In the tree, select Global, an asset type such as Static Mesh, or a taxonomy node. Each rule is tagged inherited, overridden here or added here, and an inherited rule also shows the node it comes from.
3. To add a rule, choose it from + add rule…. The validator reference shows which DCCs and asset types it covers. Use the toggle to turn the rule on or off, set the severity to error (blocks publishing) or warning (advisory), and enter its parameters. Editing an inherited rule creates an override at this node. To undo a change, click Reset on an overridden rule or Remove on a rule added here.
4. The editor saves each change as you make it, so there is no Save button. To check a change, select another node and then select this one again.
5. In the DCC, collect one valid and one invalid test instance for that node. The DCC caches conventions for up to five minutes, so wait or relaunch it, then click Validate.
6. Check that the invalid instance shows the message you expect and, for an error, can’t be published. Check that the valid instance still passes.

If the project’s conventions are a Lua script, the tree is read-only. Change the rules in the script instead. See Authoring in Lua.

Resolve a validation failure (artist)

1. Check only the instances you want to publish, and click Validate.
2. Expand the failing rule to see the affected instance and its message. If the result lists objects, click Select Invalid to select them in the scene.
3. If the rule has a Repair button, save your work and click it. Otherwise, fix the source by hand.
4. After you change the scene’s structure, click Reset to collect again, then validate again. Before you publish, make sure no blocking error or destination conflict remains.
5. If a project rule seems wrong, send the project admin the rule name, the message, the asset type and tags, and an example.

In Blender’s Dousen panel, the buttons are Run Validation, Fix and Publish Checked Instances. See the worked example.

Validator fields

Every validator, built-in or custom, is a Python class with these fields and a validate() method that performs the check:

The check returns whether it passed, a message such as "Exceeds limit of 50,000 tris", the affected objects, and an optional fix function. See Writing a custom validator.

Where rules come from and how they are scoped

Validators are stored in the project’s naming-conventions document. You can attach a rule at three levels, and each applies to everything below it. For the entry format, see Validator entries.

1. Global applies to every asset in the project.
2. Asset type applies to every asset of one type.
3. Taxonomy node applies to one node in the taxonomy tree, at any depth, and everything beneath it.

A deeper level overrides matching parameters from a shallower one, so a node can set a stricter texture limit for hero props than the global rule does. DousenCore stores each node’s effective rules in the compiled conventions, and a DCC uses the rules of the deepest matching node.

The validator catalog

The catalog is the list of rules that the portal’s rule picker offers. It has two layers:

1. A compiled baseline built into DousenCore, with naming, mesh, UV, scene, material, rig, animation, texture, HDA and VAT rules. It’s the fallback when a tenant hasn’t reported anything.
2. A layer reported by the DCC addons. On startup, each addon (Blender, Maya, 3ds Max, Houdini, Substance Painter and Substance Designer) sends DousenCore the list of validator classes it has registered, including custom plugins from validators.extra_paths. Core accepts the report only from an Admin session, so an addon started by any other user skips it.

DousenCore merges the two layers for each tenant. A rule that appears only in the report is added to the catalog, with typed parameter fields in the rule picker. For a rule in both layers, Core keeps the baseline’s name, category, default severity and default state, and uses the report only to fill in parameters and asset types that the baseline leaves empty. When a DCC can’t reach the compiled conventions, it falls back to the validator catalog if DousenCore still serves it, and otherwise to the default rules built into the addon.

Validator reference

The built-in rules, by category. Default shows the default severity and whether the rule is on, and Parameters shows the baseline defaults. The Nanite, NonNanite and host-specific rules take their defaults from the addons, and the rest from DousenCore’s baseline catalog.

Naming

Every DCC reports these rules, which check names against the project’s compiled conventions. In Substance Painter, Substance Designer and Houdini, they check texture set, graph and HDA names. In those three, naming.convention checks only the prefix (Designer uses the material prefix, default M_, on graph names), and naming.no_special_chars doesn’t allow -. Houdini also allows . and :.

Mesh: general hygiene

These geometry checks apply to every pipeline. The triangle limit is a general upper bound. The Nanite + Lumen — Static preset raises it to 2,000,000, and Nanite + Lumen — Foliage turns it off. Both rely on nonnanite.max_triangles for meshes without Nanite.

Nanite: dynamic pipeline

For meshes that use Nanite and Lumen. Nanite needs no authored LODs, but open edges, flipped normals, floating geometry and sliver triangles cause visible problems. These rules run only when the asset’s materials allow Nanite (see the Nanite gate). uvs.min_coverage belongs to this category even though its ID starts with uvs..

NonNanite: traditional pipeline

These rules run instead of the Nanite rules when the asset’s materials don’t allow Nanite. They cover a traditional mesh with authored LODs and a baked lightmap.

UVs

Scene

Materials

Max materials (max_materials) is an upper bound, and it defaults to 3 in Blender and Maya if unset. A project that still sets the older expected_count parameter keeps the exact-match behavior: each mesh must have exactly that many materials.

Rig

Animation

Textures

Houdini: HDA and VAT

Host-specific rules

Some addons have checks of their own that aren’t in the baseline. They report themselves to the catalog on startup like a custom plugin, together with the DCCs that implement them. The rule picker lists these rules for every node and adds the hosts to the name, for example (blender only). The rule’s detail shows hosts: followed by the DCCs. Only a host that implements the rule runs it, and a DCC that doesn’t implement it skips the rule without a warning. If no Desktop has reported hosts yet, the catalog has none to show, and a DCC without a validator for the rule shows the warning described in DCC coverage.

Only Designer’s two resolution rules (graph.resolution_power_of_2 and its texture.resolution_power_of_2 alias) declare parameters, so the Textures rule can show Max resolution (px) and Require square output fields that only Designer uses. The other host-specific rules have no input fields in the portal.

3ds Max

Substance Designer

DCC coverage

Blender, Maya and 3ds Max cover mesh authoring, and the other DCCs cover their own asset types. Every DCC reports the Naming rules.

3ds Max uses the same rule IDs as Blender and Maya for Naming, Mesh hygiene, Nanite and NonNanite, and also for scene.transforms_applied, uvs.min_coverage, uvs.no_overlap_lightmap and materials.no_missing_slots. In the categories marked ✓*, it covers the rest with its own host-specific rules. For example, it checks the frame rate with scene.frame_rate instead of anim.fps_match, and it has no rig.bone_count rule.

If a project turns on a rule that no DCC has a validator for, or before Desktop has reported which DCCs implement it, a DCC without a validator shows this warning: "No validator plugin found for rule 'rule id' on host 'host' — rule was skipped, not run."

The Nanite / NonNanite gate

Only one of the Nanite and NonNanite categories runs for each asset. Dousen picks it from the mesh’s material assignments in the project’s material catalog:

• If every assigned material resolves to a catalog entry and allows Nanite, the Nanite rules run.
• If every assigned material resolves and any of them doesn’t allow Nanite, the NonNanite rules run.
• If the mesh has no assignment, or any assignment doesn’t resolve to a catalog entry, the Nanite rules run, so existing scenes keep running the checks they always ran.

When Unreal imports a static mesh with a material assignment, it sets the mesh’s NaniteSettings.bEnabled from the same material lookup, so in the common case the export checks match the mesh’s Nanite setting. An unresolved assignment, or a geometry profile with nanite: false, can make them differ. For the import rules, see How the import sets Nanite.

Writing a custom validator

To add your own checks, write a Python validator plugin and add its folder to the validators.extra_paths pipeline setting. Each entry can be:

• a Perforce depot path, such as //depot/tools/validators,
• a path relative to the source root (DOUSEN_SOURCE_ROOT), or
• an absolute path.

For local testing, you can also set DOUSEN_VALIDATOR_PATHS to absolute folders, separated by your platform’s path separator.

A validator subclasses ValidatorPlugin, sets the same fields as the built-in rules, and implements validate(), so it gets the same kind of catalog entry, with typed parameter inputs in the rule picker. Register it with the @register_plugin decorator. Import everything from dousen.validators:

validate(self, context, params) must return a 4-tuple:

1. passed (bool): True if the check passed. validate() only reports pass or fail. The rule’s severity decides whether a failure blocks export (error) or is advisory (warning).
2. message (str): the explanation shown next to a failed result. Use "" when the check passes.
3. affected_objects (list[str]): the names of the objects or faces that failed, so the panel can point at them. Use [] when the check passes.
4. fix_fn (Callable | None): an optional function, with no arguments, that fixes the problem. Return it to make the panel show a Repair button (Fix in Blender) that runs it and then validates again. Return None when there’s no safe automatic fix.

Import DCC modules inside validate() and the fix function. Dousen imports your class in every host, but a host’s API (bpy, bmesh, pymxs, Maya cmds) exists only in the hosts you list in hosts. The first argument is the host’s context: bpy.context in Blender, and a dictionary in the other hosts. params holds the admin-configured parameters for this asset, so read your keys from it with defaults.

PYTHON — a Blender custom validator, with an auto-fixfrom dousen.validators import ValidatorPlugin, CheckResult, register_plugin


@register_plugin
class NoNgonsValidator(ValidatorPlugin):
    rule_id     = "mesh.no_ngons_custom"   # unique, dotted, namespaced
    name        = "No ngon faces"          # shown in the picker + results list
    category    = "Mesh"                   # groups it in the picker
    hosts       = ["blender"]              # which DCCs load it; ["any"] = all
    severity    = "warning"                # default fail level; a convention may override
    enabled     = True                     # on out of the box
    asset_types = ["static_mesh"]          # [] = any type
    params      = [
        {"key": "max_sides", "type": "int", "default": 4, "label": "Max sides"},
    ]

    def validate(self, bpy_context, params) -> CheckResult:
        import bmesh  # DCC import stays inside validate()

        limit = int(params.get("max_sides", 4))
        offenders = []
        for obj in bpy_context.scene.objects:
            if obj.type != "MESH":
                continue
            bm = bmesh.new()
            bm.from_mesh(obj.data)
            ngons = sum(1 for f in bm.faces if len(f.verts) > limit)
            bm.free()
            if ngons:
                offenders.append(f"{obj.name} ({ngons} ngons)")

        if offenders:
            # An auto-fix: triangulate the offending meshes on demand.
            def _fix():
                import bmesh
                for obj in bpy_context.scene.objects:
                    if obj.type != "MESH":
                        continue
                    bm = bmesh.new()
                    bm.from_mesh(obj.data)
                    bmesh.ops.triangulate(bm, faces=bm.faces)
                    bm.to_mesh(obj.data)
                    bm.free()

            return False, f"{len(offenders)} mesh(es) contain ngons", offenders, _fix

        return True, "", [], None   # passed: empty message, no offenders, no fix

Sharing one check across several DCCs

Many rules use the same logic in every DCC and differ only in how they read the scene. The built-in validators split such rules into two classes, and yours can too:

• A DCC-independent base class holds the metadata and implements validate() once: the comparison, the list of offenders, and the 4-tuple. It leaves one data method abstract.
• A subclass for each DCC sets hosts and overrides only the data method, which returns raw measurements.

This is why mesh.poly_count appears for Blender, Maya and 3ds Max in the coverage table.

PYTHON — the base owns validate(); it calls an abstract hookclass BasePolyCountValidator(ValidatorPlugin):
    rule_id     = "mesh.poly_count"        # metadata lives on the base
    name        = "Polygon count within project limit"
    category    = "Mesh"
    severity    = "error"
    asset_types = ["static_mesh", "skeletal_mesh"]

    def get_mesh_tri_counts(self, context, params):
        """DCC-specific hook — subclass returns [(name, tri_count), ...]."""
        raise NotImplementedError

    def validate(self, context, params) -> CheckResult:
        max_tris = int(params.get("max_tris", 50000))
        offenders = []
        for name, tris in self.get_mesh_tri_counts(context, params):   # ← calls the hook
            if tris > max_tris:
                offenders.append(f"{name} ({tris:,} tris)")
        if offenders:
            return False, f"Exceeds limit of {max_tris:,} tris", offenders, None
        return True, "", [], None          # ← the 4-tuple is assembled here, once

PYTHON — the Maya subclass overrides only the data hook@register_plugin
class MayaPolyCountValidator(BasePolyCountValidator):
    hosts = ["maya"]                       # the only metadata it adds

    def get_mesh_tri_counts(self, context, params):
        import maya.cmds as cmds           # host import stays inside the hook
        return [
            (t, cmds.polyEvaluate(t, triangle=True))
            for t in _mesh_transforms()
        ]                                  # returns raw data — NOT the 4-tuple

The Maya subclass doesn’t override validate(), so the runner calls BasePolyCountValidator.validate(). That method gets the raw counts from Maya’s get_mesh_tri_counts(), applies the max_tris comparison, and returns the tuple.

Each base class defines the data method that its check needs:

For a check that runs in one host, subclass ValidatorPlugin directly and return the 4-tuple. If the same decision must run in two or more DCCs, use a base class with an abstract data method and a subclass for each host, so the hosts can’t drift apart.

Validation history and project health

The DCC addons record each validation run in DousenCore, under the email address of the signed-in user. Each instance you validate in the Publish tab logs its own run. DousenCore also stores runs that a studio tool posts to POST /api/projects/:id/validators/log. The portal shows the runs in three places:

• Validation history lists the runs for the project, with the user, status and time. Click All, Pass, Warn or Error to filter by status. The list is paginated.
• The per-asset history shows the 100 most recent rule results for one asset. To open it, click an asset’s name on the Assets tab.
• The Health tab summarizes pass, warning and error trends and the top validator failures. The default period is seven days. The API accepts a different period, such as 24h.

Admins and artists

• Admins choose which rules run, set severities and parameters, and add custom validators. Editing rules in the Validators tab, or through the separate override document at PUT /api/projects/:id/validators (which wins over the tree for every node that has the rule), requires the Admin role, and other users get a 403. The whole portal console, including validation history and the health dashboard, is Admin-only. See Roles on a studio instance.
• Artists run the checks in the DCC at export time, fix errors, and review warnings. They can’t change which rules apply or their parameters.

Worked example: an asset fails a validator

This example uses Blender’s Dousen panel. Maya, 3ds Max, Substance Painter and Substance Designer work the same way with the Validate and Publish buttons on the Qt Publish tab. Houdini uses its Dousen: Validate shelf tool.

1. Run the validators.

   In the Dousen panel, check the instances you want to publish, open the Validation panel, and click Run Validation. The panel lists the rules by category, and you can expand a failing rule to see its message and affected objects. Say naming.convention fails as an error because a name doesn’t start with the project’s prefix. The status bar shows "Dousen validation: 1 error(s), 2 warning(s)".

2. Fix the error.

   If the rule has a Fix button, click it. Dousen applies the fix and runs the validation again. Otherwise, rename the object yourself and click Run Validation again.

3. Try to publish with an error.

   The Publish Checked Instances button in the Validation panel is disabled. If you click the button in the main Dousen panel instead, Blender shows "Fix validation errors before publishing", and nothing is exported or published.

4. Publish with only warnings.

   Warnings don’t block publishing, but you have to confirm them. When only warnings remain (say, a nonnanite.max_triangles warning), Publish Checked Instances opens a dialog with the option Publish despite validation warnings. Turn it on to publish anyway, or cancel and fix the warnings first. If you publish without the option, Blender shows "Review validation warnings before publishing". On the Qt Publish tab, a dialog asks "N warning(s) found. Publish anyway?" instead.