Check Your Work
You do not have to memorise the conventions, and nobody expects you to. Three tools check your work
and name the exact rule you broke, with the fix.
Run them before you commit. That is the whole discipline.
While you model: the Blender add-on
The Asset Rules panel in the N-sidebar checks names and pivots while the file is still open, which
is the cheapest possible moment to find out.
Set the collection's kind first: prop, wall, floor, ceiling. A collection only gets checked once
it says which it is, because the pivot rule is different for each. Guessing "prop" for everything
would flag every wall in a kit file on the first run, which is how a check gets switched off and
never switched back on.
Which Class? is the studio's decision ladder. Open it with the ? on the Asset Class panel header,
or press F3 and type it. It asks thirteen mechanical questions, read down, stop at the first yes. Type plinth,
verge, trapdoor or shutter into it and it jumps straight to the class that owns the word,
with the near miss it must not be confused with.
→ Asset Rules (Generated) > The class ladder
Every rule id in the list is a button. Click MSH015 and you get the rule itself: what it means,
what it costs (error, warning or info), what it is currently set to on this machine, and the
paragraph out of the rules file saying why anybody decided that. None of it is written down in the
add-on; it is read out of the rules, so it cannot drift away from what the check enforces.
The ? on the Asset Rules panel header opens the same thing as a searchable Rule Book. That is every
rule the studio checks, without needing a finding in front of you first. It is in Blender's own
Help menu as well, which is where you were going to look.
MSH018 ("Named Plinth, which the class ladder makes a trim rather than a wall") has a
Set Class button beside it, and a collection that has not said what it is offers the same
thing from its name. Nothing is ever applied on its own: a button that has to be pressed is not
a guess.
Before you commit: Workspace Check
A standalone app that reads the whole project workspace: the folder holding Unity, the raw and
exported assets, and everything around them. Nothing else sees above the Unity project.
Drop a folder on it or pick one. You get the structure as a tree beside the issue list, grouped by
rule. Present, required-but-missing, optional-and-missing, and not-in-the-rules folders each look different. Clicking anything opens it in Explorer.
What it checks, from one read of the disk:
WSP001–003 |
folder structure: missing, unexpected, and loose files where only folders belong |
WSP004 |
manual _V2 files with no unsuffixed active copy beside them |
WSP005–006 |
assets filed where their own name says they do not belong, and names that say nothing about where they belong |
NAM* |
asset file names, against the same grammar Blender and Unity use |
LEX002 |
words the vocabulary has replaced, like Wood on a texture, Cobble, Bricks |
VCS003 |
assets without their .meta, and .meta files whose asset is gone |
WSP005 is the interesting one: a legal name, a legal folder, and the pair still wrong.
SM_Prop_Furniture_Table_01.blend sitting in Meshes/Kit is nobody's typo and nothing else catches
it. It works because the model categories are the folder names. Prop the token and Prop the
folder are one string, so there is no table in between to drift.
It only ever writes one thing, and only when you press the button: empty folders the rules say
should exist. Nothing is renamed, moved or deleted. Those need a person looking at the contents, and
anything under a Unity project needs Unity to be the one doing it.
Every rule carries what it means, why it exists, and the steps that clear it. Filter by path, rule or
severity; group by rule, folder or severity; save the report as Markdown, JSON or CSV. ? lists the
shortcuts.
→ Workspace Check to install it
For authored data: the Asset Editor
Run Tests in the Bubbly Asset Editor toolbar catches the common problems in seconds. Worth
doing before handing anything to a translator or a build.
When a rule is wrong
Severity decides what happens. error blocks export and import. warning reports. info is
advisory.
Most rules are warnings today, including every naming and workspace rule. They harden to errors once
the existing backlog is cleared, so a warning now is a build failure later. The exception is
meshes: six of those are already errors and will stop an export outright.
→ Modular 3D Assets > What blocks an export
A new rule always lands as a warning. That is what stops the system becoming the thing everyone
works around: a rule can be added on Monday, show the real backlog on Tuesday, and block later.
You have three options when a check fires:
-
Fix it. Almost always right, almost always two minutes.
-
Add it to
exceptions.jsonwhen the asset genuinely needs to differ. This suppresses the
warning and stops the importer rewriting the file. Exceptions expire loudly rather than
silently, so this is a real option and not a way of hiding.All three tools obey it now. The Blender add-on read that file for a year and never looked
at it, so a signed-off asset was clean in Workspace Check, clean on import and red in Blender.
It matches on the path Unity sees (Assets/Games/<Game>/Meshes/….fbx) and it says how many
findings it took out of the list, so nothing goes quiet without saying so. -
Change the rule. If the rule is wrong, it is wrong for everyone. Raise it. Several of our
conventions exist because someone new said "this doesn't make sense" and was right.
What is not an option is renaming a thing to shut a checker up when you know the name is worse. The
checker is downstream of a real decision, and beating it does not make the decision.