PXLqc · Scene QC for Maya

01

Overview

Every studio has a convention, and every studio spends time policing it by hand. A supervisor opens a scene, finds a mesh named wrong, a control parented into the wrong group, a pivot left at the origin, and sends it back. That round trip costs a day, and it happens again on the next asset.

PXLqc does that pass in a few seconds, and then does the boring half of the fixing for you. It runs in three phases: analyse the scene against a convention, show you a template of what the structure should look like, and fix what can be fixed safely.

02

Your convention, not mine

This is the part that decides whether the tool is useful to anyone but its author. The rules are not hard-coded. A convention is a portable JSON file describing what your names, suffixes, hierarchy and roles should be, and the tool validates against whatever you load.

A convention describes four things:

• Naming and suffixes, which suffix belongs to which kind of node, matched through a type lineage so an abstract "light" matches whatever Maya actually created.
• The hierarchy, declared as a generative tree, so the same description both validates a scene and builds the missing groups.
• Classification, which names or types mean which role, matched on token boundaries so ctrl in the middle of a word does not accidentally make something a control.
• Which rules can auto-fix, per rule, so anything you consider risky stays a manual decision.

03

Requirements

• Autodesk Maya 2025 (PySide6, already bundled, nothing to install)
• A convention JSON, or the bundled default to start from

The rule engine itself imports no DCC at all, which is asserted by a test rather than assumed. That is deliberate: the Unreal half will share the same engine, and the fastest way to make that impossible is to let Maya leak into it.

04

Availability

The Maya half analyses and fixes today. What is still moving is the part that matters most for anyone else: making it comfortable to describe your own naming convention without hand-writing JSON. That work is next, and it is the gate on a wider release.

If you run a convention you would want this to enforce, that is exactly the input worth having. Write to info@blackmamba3d.com.

Who made this, and who owns it

PXLqc was created and is released by Cristian Spagnuolo, and is his property, published under PXLmentor as part of PXLtools. Copyright © 2026 Cristian Spagnuolo. All rights reserved.

05

Using Scene QC

Four gated sections, top to bottom. Work the orange one and the next opens.

Detect the asset first

Step one of the asset section is Detect from scene, and it runs by itself when the convention loads. It reads the top node, the hierarchy already built under it (a scion_geo_grp names the asset scion) and the convention's known asset names, with a tolerant match on spelling, then fills the type and the name. A name that is only close to a known asset is offered as did you mean and filled only when you confirm it. You type only when nothing in the scene says what the asset is, and the tool tells you why. A stray camera or light beside the asset root no longer stops it.

Three fields have to carry a value before the asset is confirmed, and they are numbered in the order you fill them: 1 Asset type, 2 Asset name and 3 Publish stage. The stage is read from the file name when it carries one (CHR_scion_mdl_v001 says mdl); when the name says nothing, you pick it. Set Asset stays off while any of the three is empty, and the line under it names exactly which one, Pick the publish stage (3) to continue, rather than leaving you with a greyed button. Press Set Asset to confirm; nothing is analysed yet.

Reset, beside Set Asset, forgets this asset in this scene: the three fields, the analysis, the plan, the results, and this scene's entry in qc_session.json. It asks first, other scenes' entries stay, and the ignore list qc_ignore.json is never touched. The stage is then read again from the file name, because the name is what is true about the file, not what the tool remembered.

Analyse the types you choose

Tick the types to check, Scene, Geometry, UVs, Shading, each with its rule count, then press Analyse selected types or Analyse all types. Geometry is ticked by default. Scene is the type for the scene-wide rules: units, timeline, layers, namespaces and references, unknown or unused nodes, cameras, lights, sets and script nodes. Which rule belongs to which type is written in the convention, so a studio can move them. A rule that belongs to another publish stage than your file (a modelling rule on a rig) is shown as information, never as a failure, and is never fixed there. Rigging is not offered yet: the rig side of the convention is still being settled, so the tool does not pretend to check it. Results are clickable: select a finding and it selects the offending node in Maya, so you are never hunting for what it means.

Right after the first analysis, if the asset's hierarchy is missing or incomplete, the tool asks No proper hierarchy found. Build it now? Yes builds it behind the usual preview; Not now leaves the Build Hierarchy button waiting in WHAT TO DO. The build options, whether Fix All also applies left/right guesses and freezes, and whether the build creates the optional groups, sit in the asset section so they are set before the question is asked.

06

Fixing what it finds

Three granularities, because "fix everything" is not always what you want:

1. Fix one. A single finding.
2. Fix all in a rule. Every instance of one problem.
3. Fix All. Everything the convention marks safe to apply automatically.

There is also Build Hierarchy, which creates the groups a part-built asset is missing, from the same tree the convention uses to validate.

Between them, fixing can create the declared hierarchy, rename meshes and groups to the convention, and reparent geometry and controls into the group their role belongs to. It also puts the asset's pivot at the centre of its base and moves the asset to the world origin, imports references and merges their namespaces into the scene, and replaces a wrong type suffix with the right one.

A modelling scene is a neutral foundation

Everything a modeller leaves in the file is inherited by look-dev, rigging and layout. So a modelling pass also checks that the scene carries none of it: no display, render or animation layers, no keys, expressions or constraints, no construction history, no extra cameras, lights or image planes, no object sets, containers or script nodes, and a timeline set to your convention's modelling range (1 to 100 unless it says otherwise). Each of these is its own rule with its own fix, so you can keep one on purpose without keeping the rest.

Geometry must carry only the default shader. The fix puts the whole object back on the default shading group, per-face assignments included, and the preview names every shader it replaces.

Scene health runs last: the fix uses Maya's own Optimize Scene Size steps to remove unused nodes and materials, then removes unknown nodes and the plugin requirements they left behind. Maya's default nodes, such as lambert1, are kept. The layer, history, shader and cleanup fixes delete things, so they are marked destructive and show as such in the preview.

Ignoring a finding for one asset

Sometimes a finding is a deliberate choice. Every finding row carries a visible Fix and Ignore button, and every rule row carries Fix all and Ignore rule, so a rule such as the polygon-density outlier can be looked at once and switched off for this asset from then on. Right-click offers the same two options, Ignore on this node for this asset and Ignore this rule for this asset, with an optional reason. Ignored findings move to a grey Ignored group at the bottom of the results, where Un-ignore brings them back, and Fix All never touches them. The list is saved as qc_ignore.json beside the scene, and its path is shown under the results, so a supervisor can read it. Save the scene first: an unsaved scene has nowhere to keep the list.

Where you left off

Scene QC remembers its session in qc_session.json, beside qc_ignore.json next to the scene (in the Maya prefs folder while the scene is unsaved, moved beside the scene on the first save). It keeps the asset, the publish stage, the build options, which types were analysed and when, each type's results, and the fixes applied. It belongs to that scene: a session found beside a different file is refused, and the stage in the file name always wins. When the remembered stage agrees with the file name the restore is silent; only a stage that contradicts the name, or a file whose name carries no stage, asks you to confirm. Reopening the tool or the scene restores the asset step without detecting again and shows the last results marked from last session with their time; only the types you re-analyse are refreshed. If the scene changed since the results were recorded they are flagged as possibly stale. A session file that cannot be read is named in the window and never overwritten.

07

Project QC for Unreal

PXLqc is designed as the same two-DCC shape as TurnTable: Scene QC inside Maya and Project QC inside Unreal, sharing one rule engine and one convention file, so a project is checked the same way on both sides of the pipeline.

08

Troubleshooting