Asset validation
Validators are automatic checks that run inside the DCC before an asset is exported. They catch problems — bad names, non-watertight meshes, oversized textures — at the point where they are cheapest to fix. The Unreal Engine plugin additionally validates names on its side.
As an admin you decide which rules run; artists run the checks and see the results. Editing the rule set is admin-gated.
What a validator is
Each rule has:
- an
id— for examplemesh.watertight,naming.pattern,texture.max_resolution; - a
severity— an error blocks the export, a warning is advisory and the artist can continue; - the asset types it applies to;
- optional
parameters.
Where rules come from and how they are scoped
Validators live in the project's naming-conventions document. You can attach a rule at three places, and they cascade downward:
- Global — every asset in the project.
- Asset type — every asset of one type.
- Taxonomy node — any node in the arbitrary-depth tree, applying to that node and everything beneath it.
Deeper levels override matching parameters from shallower ones, so a node can tighten a global rule (for example, a stricter texture limit for hero props). DousenCore resolves the effective rule set for every node ahead of time and bakes it into the compiled conventions; clients simply use the deepest matching set.
Texture size limits are validator rules — texture.max_resolution and texture.resolution_power_of_2 — configured in the Validators tab, not in a separate texture setting.
The validator catalog
Dousen ships a baseline catalog of built-in rules. On startup, each DCC reports the validators it actually has, and the server merges those over the baseline. Any new or custom rule a DCC reports becomes a first-class catalog entry, complete with typed parameter inputs in the portal's rule picker.
| Endpoint | Purpose |
|---|---|
| GET /api/validator-catalog | The merged catalog of available rules and their parameters, used by the portal's rule picker. |
Custom validators
Admins can add their own checks by writing a Python validator plugin and pointing the project at the folder that contains it. Set the validators.extra_paths pipeline setting; each entry may be:
- a Perforce depot path such as
//depot/tools/validators, - a path relative to the source root, or
- an absolute path.
Dousen discovers these plugins automatically and they then appear in the portal picker just like built-ins.
PYTHONclass NoNgonsValidator:
rule_id = "mesh.no_ngons"
severity = "warning"
def validate(self, asset, params):
ngons = [f for f in asset.faces if len(f.vertices) > 4]
if ngons:
return [f"Face {f.index} has {len(f.vertices)} sides"
for f in ngons]
return []
Keep custom validators in Perforce (a //depot/... entry) so every artist gets the same checks the moment they sync — no per-machine setup.
Validation history and project health
Every check an artist runs is logged. Admins review the results in the web portal:
- a validation history of individual runs, and
- a per-project health summary of pass/warn/error trends and top offenders (default 7-day window).
| Endpoint | Purpose |
|---|---|
| POST /api/projects/:id/validators/log | Records the outcome of a validation run (called by the DCC addons). |
Admin vs. artist
- Admins choose which rules run, set severities and parameters, and add custom validators. All editing is admin-gated.
- Artists run the checks at export time and act on the results — fixing errors, reviewing warnings.