Por que o Studio recusa o seu acessório: as seis categorias de validação UGC

A validação do Studio recusa o seu acessório e devolve uma mensagem. Você lê, não entende direito, volta para o programa de modelagem, mexe em alguma coisa, exporta de novo, tenta de novo. Três tentativas depois, ainda não passou — e a essa altura já não dá para dizer com certeza o que foi mudado.

Esse ciclo tem uma causa específica: a validação UGC não é uma checagem. São seis categorias, olhando coisas diferentes do mesmo arquivo, e cada uma se conserta num lugar diferente. Saber em qual delas o erro caiu é a diferença entre consertar em minutos e reexportar no escuro.

O problema

Começando pelo que o sistema é: a validação UGC é o mecanismo técnico que confere se o asset de avatar cumpre as especificações da plataforma antes de você poder subir e publicar. O objetivo declarado é garantir que corpo, cosmético, roupa e acessório se comportem de forma consistente na plataforma.

Essa frase explica o rigor. O seu acessório vai ser usado em cima de milhões de corpos diferentes, com escalas diferentes, animações diferentes e roupas em camadas por cima e por baixo. A validação não está avaliando se o item é bonito — está conferindo se ele continua funcionando em situações que você nunca testou.

Ela roda em dois momentos: ao tentar subir asset de avatar pelo Studio, e ao chamar as APIs do AvatarCreationService para criação dentro da experiência. Passando, segue-se o envio pagando a taxa de upload.

E há uma coisa que quase ninguém aproveita: asset que não vai para o Marketplace — os de uso interno no jogo — não precisa passar pela validação. Mesmo assim, a documentação recomenda usá-la: ela continua útil para depurar corpo e acessório próprios. É um verificador de malha, gaiola e skinning de graça, e roda sem compromisso nenhum de publicar.

Passo a passo

O caminho útil não é "tentar de novo". É localizar a categoria e consertar no lugar certo. As seis, com o que cada uma olha:

1. Schema — a árvore do objeto. Confere se tipos filhos, tags e atributos estão configurados corretamente, e se o asset inclui algum script banido.

Falha aqui quase nunca é problema de modelagem. É montagem no Studio, e se conserta no Studio — em minutos. Se o erro cita hierarquia, filho ou atributo, não abra o programa de modelagem.

2. Geometria da malha. Esta é a mais larga. Olha orçamento de triângulos, tamanho da caixa delimitadora e limite total de área de superfície. Olha também se o asset está centrado na origem e se não é fino demais em algum eixo. E exige que a malha seja estanque, sem N-gons, sem cor de vértice e sem triângulo de área zero.

Falha aqui é conserto no programa de modelagem, e reimportar. Vale conhecer os três itens que mais pegam gente boa: o N-gon, que é qualquer face com mais de quatro lados e que costuma sobrar de uma operação booleana; o triângulo de área zero, invisível na tela e presente em quase toda malha que passou por muita edição; e a cor de vértice, que alguns programas gravam por padrão sem avisar.

3. Textura e materiais. Confere resolução máxima e mapas UV válidos, valida textura PBR para objetos SurfaceAppearance, e recusa cor de vértice inválida.

4. Rigging e skinning. Esta categoria tem uma regra de exclusão mútua que merece decorar: corpo e acessório em camadas precisam incluir dado de skinning; acessório rígido não pode incluir. E a contagem de pesos de skin precisa bater com a contagem de vértices.

5. Gaiolas e attachments. Todas as partes do corpo precisam ter gaiola para a validação de corpo inteiro. A malha da gaiola precisa acompanhar de perto a malha de renderização, e a malha de renderização precisa ficar dentro da gaiola externa. Do lado dos attachments: todo attachment precisa ter o nome correto do ponto de encaixe dele.

6. Cabeça dinâmica. Só vale para cabeça, e é a mais exigente: pelo menos 17 poses FACS, projeção dos pontos de referência na malha, e detecção de animação facial — os pontos precisam se mover no piscar, na abertura da boca e nas expressões feliz e triste.

Há ainda a camada de segurança e moderação, que confere autoria do asset, nomes de classe banidos e antifraude de atributo por proxy.

Vale notar como essas seis se distribuem no trabalho. Duas delas — Schema e segurança — são sobre o que foi montado no Studio. Três — geometria, textura e skinning — são sobre o que saiu do programa de modelagem. E a de gaiolas e attachments fica no meio: a gaiola vem da modelagem, o attachment costuma vir da montagem.

Essa divisão é a razão de percorrer a lista inteira antes do primeiro envio, em vez de deixar a mensagem de erro guiar o caminho. Cada ida e volta ao programa de modelagem custa uma reexportação e uma reimportação; descobrir três problemas de modelagem de uma vez custa uma só.

Artefato

O documento abaixo é a lista das seis categorias em formato de conferência, com uma anotação em cada uma dizendo onde se conserta a falha daquele tipo.

É essa anotação que economiza tempo. A pergunta "Studio ou programa de modelagem?" responde metade do problema antes de qualquer ajuste, e é a pergunta que ninguém faz quando está olhando uma mensagem de erro vermelha.

No fim dele estão os dois erros que a documentação descreve com conserto passo a passo, com o texto original de cada um — porque procurar a mensagem literal é mais rápido que procurar a descrição dela.

Erro comum

O erro de skinning é o mais frequente, e ele acontece por omissão, não por ação.

A regra é de exclusão mútua: acessório rígido não pode incluir dado de skinning. Só que ninguém adiciona skinning de propósito num acessório rígido. O que acontece é outra coisa: o item é modelado numa cena que já tinha armadura — porque você estava testando o encaixe no personagem, ou porque reaproveitou um arquivo — e na exportação o dado de skinning viaja junto, sem ninguém pedir. A malha está certa, a textura está certa, e a validação recusa por uma coisa que você nem sabia que estava ali.

O segundo erro clássico tem mensagem própria: todos os MeshPart precisam ter o mesmo valor no AvatarPartScaleType. Ele dispara quando dois ou mais MeshPart do mesmo envio têm valores diferentes — um com um tipo de escala, outro com outro. A correção é garantir que todo MeshPart do asset tenha um filho AvatarPartScaleType idêntico.

O motivo de existir vale entender, porque ele explica por que a exigência é tão rígida: é o AvatarPartScaleType que diz ao sistema qual caixa de tamanho aplicar àquela peça. Num asset de várias partes, valores discordantes deixariam o sistema sem saber qual regra usar para o conjunto. Isso costuma acontecer quando uma peça foi copiada de outro projeto: ela chega com o valor do projeto antigo, e o resto do corpo continua com o novo.

Há um terceiro, mais bobo e por isso mais irritante: o peso da animação. O erro dispara quando um NumberValue chamado Weight dentro da hierarquia da animação está com valor zero ou menor. A correção é pôr um número positivo, tipicamente 1.0. Faz sentido — peso zero deixaria a animação sem efeito nenhum, o que não é um item vendável.

O padrão por trás dos três é o mesmo, e vale nomear: nenhum deles é erro de modelagem. Os três são dado que entrou no arquivo sem intenção, vindo de outra cena, de outro projeto ou de um padrão do exportador. Por isso reexportar "com mais cuidado" não resolve — o que resolve é abrir a árvore no Studio e olhar o que está lá.

Próximo passo

Com a categoria identificada, o recurso mais subaproveitado da validação são as ferramentas de visualização: a documentação diz que elas dão guias visuais específicos do asset sobre como consertar ou melhorar. Gaiola e malha são problemas espaciais, e problema espacial se resolve olhando, não lendo — ver a malha de renderização furando a gaiola externa responde em um segundo o que uma mensagem de erro leva três tentativas para sugerir.

O passo seguinte é preventivo: rode a validação em asset que não vai ser publicado. Ela não cobra nada para rodar, e um corpo ou acessório de uso interno que passa na validação UGC é um asset que você sabe que está estanque, centrado, com skinning coerente e attachments nomeados. Isso vale como controle de qualidade mesmo para quem nunca vai vender nada.

E cada categoria tem a sua página de especificação — corpo, cabeça dinâmica, maquiagem, acessório rígido, acessório em camadas. Ler a do tipo que você produz uma vez, inteira, custa menos que a terceira reexportação no escuro.

AS SEIS CATEGORIAS DA VALIDACAO UGC — use para localizar o erro antes de
reexportar. Conferido na documentacao oficial em 23/09/2026.

1) SCHEMA — a arvore do objeto
   [ ] tipos filhos, tags e atributos configurados corretamente
   [ ] nenhum script banido dentro do asset
   -> falha aqui = problema de MONTAGEM no Studio. Nao reexporte.

2) GEOMETRIA DA MALHA
   [ ] dentro do orcamento de triangulos do tipo
   [ ] caixa delimitadora dentro do tamanho permitido
   [ ] limite total de area de superficie respeitado
   [ ] centrado na origem
   [ ] nao fino demais em nenhum eixo
   [ ] estanque (watertight)
   [ ] sem N-gons
   [ ] sem cor de vertice
   [ ] sem triangulo de area zero
   -> falha aqui = conserto no programa de modelagem, e reimportar.

3) TEXTURA / MATERIAIS
   [ ] resolucao dentro do maximo
   [ ] mapas UV validos
   [ ] textura PBR valida, se houver SurfaceAppearance
   [ ] nenhuma cor de vertice invalida

4) RIGGING / SKINNING — a regra aqui e de EXCLUSAO MUTUA
   [ ] corpo e acessorio EM CAMADAS: skinning e OBRIGATORIO
   [ ] acessorio RIGIDO: skinning e PROIBIDO
   [ ] contagem de pesos de skin == contagem de vertices
   -> o erro classico: exportar rigido a partir de uma cena riggada.
      O skinning viaja junto sem ninguem pedir.

5) GAIOLAS INTERNA E EXTERNA
   [ ] todas as partes do corpo tem gaiola (validacao de corpo inteiro)
   [ ] malha da gaiola acompanha de perto a malha de renderizacao
   [ ] malha de renderizacao esta DENTRO da gaiola externa
   [ ] UVs da gaiola batem com os modelos oficiais

   ATTACHMENTS
   [ ] todo attachment com o nome correto do ponto de encaixe
   [ ] posicao e orientacao conferidas

6) CABECA DINAMICA — so para cabeca
   [ ] pelo menos 17 poses FACS
   [ ] projecao dos pontos de referencia na malha da cabeca
   [ ] os pontos SE MOVEM no piscar, na abertura da boca e nas
       expressoes feliz e triste

   SEGURANCA / MODERACAO
   [ ] autoria do asset
   [ ] nenhum nome de classe banido
   [ ] antifraude de atributo por proxy

DOIS ERROS COM CONSERTO CONHECIDO:

  "Animation has a Weight value that is not greater than 0"
     -> NumberValue chamado Weight na hierarquia da animacao esta em zero
        ou negativo. Ponha um numero positivo, tipicamente 1.0.

  "All MeshParts must have the same value in their AvatarPartScaleType"
     -> dois ou mais MeshPart do mesmo envio com valores diferentes.
        Todo MeshPart precisa do MESMO filho AvatarPartScaleType.