Why Studio rejects your accessory: the six UGC validation categories

Studio validation rejects your accessory and returns a message. You read it, do not quite understand it, go back to the modelling program, change something, export again, try again. Three attempts later it still has not passed — and by then you can no longer say with certainty what was changed.

That cycle has a specific cause: UGC validation is not one check. It is six categories, looking at different things in the same file, and each one is fixed in a different place. Knowing which of them the error fell into is the difference between fixing it in minutes and re-exporting in the dark.

The problem

Starting with what the system is: UGC validation is the technical mechanism that checks whether an avatar asset meets the platform specifications before you can upload and publish it. The declared goal is to ensure bodies, cosmetics, clothing and accessories behave consistently on the platform.

That sentence explains the strictness. Your accessory is going to be used on top of millions of different bodies, at different scales, with different animations and layered clothing above and below. Validation is not assessing whether the item is beautiful — it is checking whether it keeps working in situations you never tested.

It runs at two moments: when you try to upload an avatar asset through Studio, and when you call the AvatarCreationService APIs for in-experience creation. On passing, submission follows, paying the upload fee.

And there is something almost nobody takes advantage of: an asset that is not going to the Marketplace — the ones for internal use in your game — does not have to pass validation. Even so, the documentation recommends using it: it remains useful for debugging your own bodies and accessories. It is a free mesh, cage and skinning checker, and it runs with no commitment to publish at all.

Step by step

The useful route is not "try again". It is locating the category and fixing it in the right place. All six, with what each one looks at:

1. Schema — the object tree. It checks whether child types, tags and attributes are configured correctly, and whether the asset includes any banned script.

A failure here is almost never a modelling problem. It is assembly in Studio, and it is fixed in Studio — in minutes. If the error mentions hierarchy, a child or an attribute, do not open the modelling program.

2. Mesh geometry. This is the widest one. It looks at the triangle budget, the bounding box size and the total surface area limit. It also looks at whether the asset is centred on the origin and whether it is too thin on any axis. And it requires the mesh to be watertight, with no N-gons, no vertex colour and no zero-area triangles.

A failure here is a fix in the modelling program, and reimport. It is worth knowing the three items that catch good people most: the N-gon, which is any face with more than four sides and usually left over from a boolean operation; the zero-area triangle, invisible on screen and present in almost any mesh that has been heavily edited; and vertex colour, which some programs write by default without saying so.

3. Texture and materials. It checks the maximum resolution and valid UV maps, validates the PBR texture for SurfaceAppearance objects, and rejects invalid vertex colour.

4. Rigging and skinning. This category has a mutual exclusion rule worth memorising: bodies and layered accessories have to include skinning data; rigid accessories cannot. And the skin weight count has to match the vertex count.

5. Cages and attachments. Every body part has to have a cage for full-body validation. The cage mesh has to follow the render mesh closely, and the render mesh has to sit inside the outer cage. On the attachment side: every attachment has to carry the correct name of its attachment point.

6. Dynamic head. Heads only, and the most demanding: at least 17 FACS poses, projection of the reference points onto the mesh, and facial animation detection — the points have to move on the blink, on the mouth opening and on the happy and sad expressions.

There is also the security and moderation layer, which checks asset authorship, banned class names and proxy attribute anti-fraud.

It is worth noticing how those six distribute across the work. Two of them — Schema and security — are about what was assembled in Studio. Three — geometry, texture and skinning — are about what came out of the modelling program. And cages and attachments sits in the middle: the cage comes from modelling, the attachment usually from assembly.

That division is the reason to walk the whole list before the first submission, instead of letting the error message guide the route. Every round trip to the modelling program costs a re-export and a reimport; finding three modelling problems at once costs one.

The artifact

The document below is the list of the six categories in checklist form, with a note on each saying where a failure of that type is fixed.

It is that note that saves time. The question "Studio or modelling program?" answers half the problem before any adjustment, and it is the question nobody asks while staring at a red error message.

At the end of it are the two errors the documentation describes with a step-by-step fix, with each one's original text — because searching for the literal message is quicker than searching for a description of it.

Common mistakes

The skinning error is the most frequent, and it happens by omission, not by action.

The rule is mutual exclusion: a rigid accessory cannot include skinning data. Except nobody adds skinning to a rigid accessory on purpose. What happens is something else: the item is modelled in a scene that already had an armature — because you were testing the fit on the character, or because you reused a file — and on export the skinning data travels along, without anyone asking. The mesh is right, the texture is right, and validation rejects it for something you did not know was there.

The second classic error has a message of its own: all MeshParts have to have the same value in their AvatarPartScaleType. It fires when two or more MeshParts in the same submission have different values — one with one scale type, another with another. The fix is making sure every MeshPart in the asset has an identical AvatarPartScaleType child.

The reason it exists is worth understanding, because it explains why the requirement is so strict: it is the AvatarPartScaleType that tells the system which size box to apply to that piece. In a multi-part asset, disagreeing values would leave the system unsure which rule to use for the whole. This usually happens when a piece was copied from another project: it arrives with the old project's value, and the rest of the body keeps the new one.

There is a third, sillier and for that reason more irritating: the animation weight. The error fires when a NumberValue called Weight inside the animation hierarchy is at zero or below. The fix is setting a positive number, typically 1.0. It makes sense — a weight of zero would leave the animation with no effect at all, which is not a sellable item.

The pattern behind all three is the same, and it is worth naming: none of them is a modelling error. All three are data that entered the file unintentionally, coming from another scene, another project or an exporter default. That is why re-exporting "more carefully" does not fix it — what fixes it is opening the tree in Studio and looking at what is there.

Next step

With the category identified, the most underused resource in validation is the visualisation tools: the documentation says they give asset-specific visual guides on how to fix or improve. Cages and meshes are spatial problems, and a spatial problem is solved by looking, not reading — seeing the render mesh poking through the outer cage answers in a second what an error message takes three attempts to suggest.

The next step is preventive: run validation on assets that are not going to be published. It costs nothing to run, and an internal-use body or accessory that passes UGC validation is an asset you know is watertight, centred, with coherent skinning and named attachments. That counts as quality control even for someone who is never going to sell anything.

And each category has its own specification page — body, dynamic head, makeup, rigid accessory, layered accessory. Reading the one for the type you produce once, in full, costs less than the third re-export in the dark.

THE SIX UGC VALIDATION CATEGORIES — use this to locate the error before
re-exporting. Checked against the official documentation on 23/09/2026.

1) SCHEMA — the object tree
   [ ] child types, tags and attributes configured correctly
   [ ] no banned script inside the asset
   -> a failure here = an ASSEMBLY problem in Studio. Do not re-export.

2) MESH GEOMETRY
   [ ] within the triangle budget for the type
   [ ] bounding box within the allowed size
   [ ] total surface area limit respected
   [ ] centred on the origin
   [ ] not too thin on any axis
   [ ] watertight
   [ ] no N-gons
   [ ] no vertex colour
   [ ] no zero-area triangles
   -> a failure here = a fix in the modelling program, and reimport.

3) TEXTURE / MATERIALS
   [ ] resolution within the maximum
   [ ] valid UV maps
   [ ] valid PBR texture, if there is a SurfaceAppearance
   [ ] no invalid vertex colour

4) RIGGING / SKINNING — the rule here is MUTUAL EXCLUSION
   [ ] body and LAYERED accessory: skinning is MANDATORY
   [ ] RIGID accessory: skinning is FORBIDDEN
   [ ] skin weight count == vertex count
   -> the classic error: exporting a rigid item from a rigged scene.
      The skinning travels along without anyone asking.

5) INNER AND OUTER CAGES
   [ ] every body part has a cage (full-body validation)
   [ ] the cage mesh closely follows the render mesh
   [ ] the render mesh is INSIDE the outer cage
   [ ] the cage UVs match the official templates

   ATTACHMENTS
   [ ] every attachment carries the correct attachment point name
   [ ] position and orientation checked

6) DYNAMIC HEAD — heads only
   [ ] at least 17 FACS poses
   [ ] projection of the reference points onto the head mesh
   [ ] the points MOVE on the blink, on the mouth opening and on the
       happy and sad expressions

   SECURITY / MODERATION
   [ ] asset authorship
   [ ] no banned class names
   [ ] proxy attribute anti-fraud

TWO ERRORS WITH A KNOWN FIX:

  "Animation has a Weight value that is not greater than 0"
     -> a NumberValue called Weight in the animation hierarchy is at zero
        or negative. Set a positive number, typically 1.0.

  "All MeshParts must have the same value in their AvatarPartScaleType"
     -> two or more MeshParts in the same submission with different values.
        Every MeshPart needs the SAME AvatarPartScaleType child.